我一直在使用此处列出的git分支策略http://nvie.com/posts/a-successful-git-branching-model/
到目前为止，它一直对我很有效。
我经常发现自己要问的问题是在处理功能分支时，我最终需要实现与整个项目相关的代码。处理这些情况的最佳方法是什么？
a）检查主开发分支，提交更改并将功能分支重新设置为develop。
b）在功能分支上进行更改，然后合并回开发，以便其他功能分支可以访问该代码。
c）为公共代码创建一个新分支，并将其合并到Develop以及需要使用它的任何功能分支。
这是另一个问题。您多久将一个功能分支合并回主开发分支？您是否等到功能完全完成然后合并并删除它？或者，在它稳定的任何时候，你会在它的整个生命周期中合并回几次？
答案 0 :(得分：4)
我喜欢选项a /，但实际情况是，当您在提交后进行提交时，您只会意识到其中一些实际上是常见的代码。\ / p>
当feature分支上发生这种情况时（通常尚未推送和共享），我更喜欢做interactive rebase，首先重新排序公共代码的提交，然后对于那些第一次提交（快进合并），将master分支合并到feature分支。
从那里开始，我可以将master任何其他分支机构转移到必须从这些新的共同特征中受益的分支。
合并一个功能分支只有在该功能分支的状态必须对其他人可见时才有意义（因为您希望在保持master分支私有的情况下推送feature。
如果剩下的开发：
feature分支master和feature分支之间等待的时间越长，合并就越困难），然后我更喜欢稍后合并feature分支。