用于特征分支和公共代码的Git分支策略

Question

我一直在使用这里概述的git分支策略http://nvie.com/posts/a-successful-git-branching-model/

到目前为止,它一直很适合我.

我经常发现自己要问的问题是在处理功能分支时,我最终需要实现与整个项目相关的代码.处理这些情况的最佳方法是什么？

a)检查主开发分支,提交更改并重新设置开发的功能分支.

b)在功能分支上进行更改,然后合并回开发,以便其他功能分支可以访问该代码.

c)为公共代码创建一个新分支,并将其合并到Develop以及需要使用它的任何功能分支中.

这是另一个问题.您多久将一个功能分支合并回主开发分支？您是否等到功能完全完成然后合并并删除它？或者,如果它稳定的话,你会在整个生命周期中多次合并开发吗？

Answer 1

我喜欢选项 a/，但现实是，当您在提交后进行提交时，您只会意识到其中一些实际上是过程中的公共代码。

当这种情况发生在一个feature分支上时（通常还没有被推送并共享），我更喜欢做一个interactive rebase，首先重新排序公共代码的提交，然后将分支合并master到feature第 n 个提交的分支（快速） - 前向合并）。
从那里，我可以重新定位到master必须从这些新的通用功能中受益的任何其他分支。

仅当该功能分支的状态必须对其他人可见时，合并回功能分支才有意义（因为您希望master在保持feature分支对您的存储库私有的同时进行推送）。
如果剩下的发展：

• 无需分支中的任何部分即可feature继续
• 可以在不修改某些常见文件集的情况下继续进行（这意味着您在分支之间等待的时间越长，合并就越master困难feature）

，那么我更喜欢feature稍后合并分支。