用于功能分支和通用代码的 Git 分支策略
我一直在使用此处概述的 git 分支策略 http://nvie.com /posts/a-successful-git-branching-model/
到目前为止，它对我来说效果非常好。
我经常问自己的问题是，在开发功能分支时，我最终需要实现与整个项目相关的代码。处理这些情况的最佳方法是什么？
a) 检查主开发分支，提交更改并重新建立开发分支的功能基础。
b) 在功能分支上进行更改，然后合并回开发中，以便其他功能分支可以访问该代码。
c) 为公共代码创建一个新分支，并将其合并到 Develop 以及需要使用它的任何功能分支中。
这是另一个问题。您多久将一个功能分支合并回主开发分支？您是否会等到该功能完全完成后再合并并删除它？或者，在其生命周期内，只要它稳定，您是否会多次合并回开发中？
I've been using the git branching strategy outlined here http://nvie.com/posts/a-successful-git-branching-model/
So far its been working really well for me.
The question I often find my self asking is while working on a feature branch I'll end up needing to implement code that is relevant to the entire project. What is the best way to handle these situations?
a) Check out the main development branch, commit the change and rebase the feature branch off of develop.
b) Make the change on the feature branch, then merge back into develop so that other feature branches can have access to that code.
c) Create a new branch for the common code and merge that into Develop as well as any feature branches that need to use it.
Here's another question. How often do you merge a feature branch back into the main development branch? Do you wait until the feature is completely done then merge it and delete it? Or do you merge back into develop several times throughout its lifetime any time that it's stable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我喜欢选项 a/，但现实是，当您在提交后进行提交时，您只会在该过程的后期才意识到其中一些实际上是常见代码。
当这种情况发生在
feature分支（通常尚未推送并共享）上时，我更喜欢进行交互式变基，对公共代码的提交重新排序首先，然后将 n 个首次提交的master分支合并到feature分支（快进合并）。从那里，我可以将任何其他必须从这些新的通用功能中受益的分支重新定位到 master 上。
仅当该功能分支的状态必须对其他人可见时，合并回功能分支才有意义（因为您希望推送
master同时保持feature分支对您的存储库私有） .如果开发的其余部分：
feature分支中的任何部分feature之间等待的时间越长，合并就越困难code>master 和feature分支），那么我更喜欢稍后合并
feature分支。I like option a/, but the reality is, when you are doing commits after commits, you only realize that some of them are actually common code much later in the process.
When that happens on a
featurebranch (that usually hasn't been pushed yet and shared with), I prefer doing aninteractive rebase, re-ordering the commits for common code first, and then merging themasterbranch to thefeaturebranch for those n first commits (fast-forward merge).From there, I can rebase onto
masterany other branch that have to benefit from those new common features.Merging back a feature branch only makes sense if the state of that feature branch must be visible for others (because you want to push
masterwhile keepingfeaturebranch private to your repo).If the rest of the development:
featurebranchmasterandfeaturebranches), then I prefer merging
featurebranch later.