特性分支和公共(public)代码的 Git 分支策略

Question

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

到目前为止，它对我来说非常有效。

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

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

b) 在功能分支上进行更改，然后 merge 回开发，以便其他功能分支可以访问该代码。

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

还有一个问题。您多久将一个功能分支 merge 回主开发分支？您是否等到该功能完全完成然后 merge 并删除它？或者您是否在其稳定的任何时候在其整个生命周期中多次 merge 回开发？

Answer 1

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

当这种情况发生在 feature 分支(通常还没有被推送和共享)时，我更喜欢做一个 interactive rebase，重新排序提交首先用于公共(public)代码，然后将 master 分支 merge 到 feature 分支以用于第 n 个提交(快进 merge )。
从那里，我可以 rebase 到 master 必须受益于这些新的通用功能的任何其他分支。

仅当该功能分支的状态必须对其他人可见时， merge 回该功能分支才有意义(因为您希望推送 master 同时保持 feature 分支私有(private)你的 repo )。
如果剩下的开发:

• 可以在不需要feature 分支中的任何部分的情况下继续
• 可以在不修改一些通用文件集的情况下继续进行(这意味着您在 master 和 feature 分支之间等待的时间越长， merge 就越困难)

，那么我更愿意稍后 merge feature 分支。