我一直在使用此处概述的 git 分支策略http://nvie.com/posts/a-successful-git-branching-model/
到目前为止，它对我来说效果很好。
我经常发现自己问的问题是，在处理功能分支时，我最终需要实现与整个项目相关的代码。处理这些情况的最佳方法是什么？
a) 检查主开发分支，提交更改并将特性分支从开发中变基。
b) 在功能分支上进行更改，然后合并回开发，以便其他功能分支可以访问该代码。
c) 为公共代码创建一个新分支并将其合并到开发以及需要使用它的任何功能分支中。
这是另一个问题。您多久将功能分支合并回主开发分支？您是否要等到功能完全完成然后合并并删除它？还是在其稳定的任何时候，您是否在其生命周期中多次合并回开发？
我喜欢选项 a/，但实际情况是，当您在提交后进行提交时，您只会意识到其中一些实际上是在此过程中很晚的常见代码。
当这种情况发生在一个feature分支上（通常还没有被推送和共享）时，我更喜欢先做一个interactive rebase，重新排序公共代码的提交，然后将master分支合并到feature那些第 n 个提交的分支（快速-向前合并）。
从那里，我可以重新定位到master必须从这些新的通用特性中受益的任何其他分支。
只有当该功能分支的状态必须对其他人可见时，合并回一个功能分支才有意义（因为您希望在推送的master同时保持feature分支对您的存储库私有）。
如果剩下的开发：
feature分支中的任何部分即可继续进行master可以在不修改某些常见文件集的情况下继续进行（这意味着您在和feature分支之间等待的时间越长，合并就越困难），那么我更喜欢稍后合并feature分支。