假设我有一个像这样非常简单的分支情况，其中有一个dev分支和一个生产分支，它们在过去的某个时刻有一个共同的祖先称为常见:
现在，是时候开发一项新功能了。我们希望该功能今天在开发中投入使用，并在一个月后生产中投入使用。简单的做法是将功能从common中分支出来，然后在我们想要时将其 merge 到dev和生产中:
但这一次，我不想这样做。我不想这样做，因为开发和生产自常见以来都发生了很大的变化，这真的很痛苦在common基础上开发此功能。
我真正想做的，是从树中稍后的点开发它，就像这样，只是为了我自己的幸福，这样dev的所有新更新都可以当我制作该功能时出现:
现在，这当然可以将该功能 merge 到dev中，但是当我将此功能 merge 到生产中时，它将带来一大堆东西来自dev，我真的不想要。
一种解决方案是 merge 开发和生产。但我真的不想这样做。我需要开发上的东西，而不是生产上的东西，可能需要很长时间。
当然，只要该功能不会与dev或生产内部发生冲突的任何内容混淆，我想要的东西在逻辑上就可能实现。但事实并非如此。它将与两者兼容，并且自 common 以来我对 dev 所做的更改甚至与该功能无关。我只是希望他们在我制作这个功能时就在那里。而且我不想每次想要测试任何内容时都必须将功能 merge 到 dev 中。
最佳答案
It's going' to be compatible with both, and the changes I made to
devsince common are not even related to thefeature
这意味着您可以从 dev 开始，然后，当您想要将 feature merge 到 prod 中时，您rebase 功能位于产品之上。
这样，您只需在 prod 之上进行功能提交，即可 merge 功能(快进 merge )
关于git - merge 功能分支而不从共同祖先一直分支？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26690789/