的特性分支和

Question

我一直在使用Git的分支策略的通用代码的Git分支stategy这里列出http://nvie.com/posts/a-successful-git-branching-model/

到目前为止，其一直对我很好。

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

a）签出主要开发分支，提交更改并将开发的功能分支重新绑定。

b）在功能分支上进行更改，然后合并到开发中，以便其他功能分支可以访问该代码。

c）为通用代码创建一个新分支，并将其合并到Develop中以及需要使用它的任何功能分支中。

这是另一个问题。你多久将一次功能分支合并回主开发分支？你是否等到功能全部完成，然后合并并删除它？或者，在任何时候稳定的时候，你是否会重新开发几次？

Answer 1

我喜欢选项/，但实际情况是，当你提交后做的提交，你只知道有些人实际上是在这个过程中共同代码要晚得多。

当在feature分支出现这种情况（通常还没有被推动而随着共享），我更喜欢做一个interactive rebase，重新排序的通用代码的提交，然后再合并master跳转到feature为这n个第一次提交（快进合并）分支。
从那里，我可以重新登录master任何其他必须受益于这些新的共同功能的分支。

如果该功能分支的状态必须对其他分支可见（因为要在推送master的同时将feature分支保留为您的回购专用分支），则合并回功能分支才有意义。
如果开发的其余部分：

• 可以在不需要的东西是在feature分支
• ，而无需修改一些常见的文件集（这将意味着更难合并可以进行任何部分进行的时间越长您在master和feature分支之间等待）

，那么我宁愿稍后合并feature分支。