gitworkflows - 究竟如何毕业分支?
我有一个 git 分支模型,非常类似于 gitworkflows http 中描述的模型://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html 和这里http://members.cox.net/junkio/git/MaintNotes.html
我有对于如何准确地毕业分支以及如何处理修复仅在两个不同分支交互时发生的错误的提交存在一些疑问。
具体来说,我有以下分支:
生产:与我们的生产服务器中部署的完全相同
修补程序:从“生产”的提示分叉',我在其中修复错误,然后将“生产”快进到它(并重新部署)
几个功能分支:每个新功能都是隔离创建的
测试:我合并每个足够成熟的功能分支< /p>
all:我合并每个功能,无论它有多新或未经测试
我合并功能分支按 F1 和 F2 的顺序进入“测试”。事实证明它们不能很好地结合在一起,所以我提交修复 C1 和 C2(直接进入“测试”);后来我合并了第三个分支 F3 并继续提交修复由于这些分支交互不佳而发生的错误(如果我在一个特定功能中发现错误,我会在它自己的分支中修复它,然后重新合并)。我后来只想毕业F2,因为F1和F3还没有准备好(或者因为客户一时兴起),所以我将该分支直接合并到“生产”中。
接下来该怎么办?
如何处理“测试”中涉及 F2 与 F1 或 F3(如 C1 和 C2)交互的错误修复?我是否将它们挑选到相应的尚未毕业的分支中?这不是太多的手动工作吗?
“测试”怎么样?我是否要丢弃它并从“生产”的新技巧重新构建它?如果是这样,如何避免丢失尚未进入“生产”的分支的错误修复?再次挑选樱桃?有没有一种方法可以更新“测试”而不需要重置/变基?
将 F1 和 F3 的合并恢复到“测试”中,一旦我只有 F2,将“测试”合并到生产中会更好吗?请注意,此模型还要求我恢复与我要恢复的分支相关的错误修复。
I have a git branching model pretty much like the one described in gitworkflows http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html and here http://members.cox.net/junkio/git/MaintNotes.html
I have some doubts about how exactly to graduate a branch and what to do with commits that fix bugs that only happen when 2 different branches interact.
Specifically, I have these branches:
production: exactly the same as what's deployed in our production server
hotfixes: forked from the tip of 'production', where I fix bugs and later fast-forward 'production' to it (and re-deploy)
several feature branches: every new feature is created in isolation
test: where I merge every feature branch that's mature enough
all: where I merge every feature, no matter how new or untested it is
Say I merge feature branches F1 and F2 in that order into 'test'. It turns out that they don't play nice together, so I commit fixes C1 and C2 (directly into 'test'); I later merge a third branch F3 and continue committing fixes for bugs that happen because of these branches not interacting well (if I found a bug in one specific feature, I would fix it in it's own branch and then re-merge). I later want to graduate only F2, because F1 and F3 are not ready yet (or because the client is on a whim), so I merge that branch directly into 'production'.
What to do next?
What to do with the bug fixes that were in 'test' that involved F2 interacting with F1 or F3 (like C1 and C2)? Do I cherry-pick them into the corresponding not-yet-graduated branch? Wouldn't this be a bit too much manual work?
What about 'test'? Do I discard it and build it again from the new tip of 'production'? If so, how to avoid losing the bug fixes for branches that aren't yet in 'production'? cherry-pick again? Is there a way to update 'test' that does not require reset/rebase?
Would it have been better to revert the merge(s) of F1 and F3 into 'test' and once I have only F2 in there, merge 'test' into production'? Note that this model also requires me to revert the bug fixes that relate to the branch I'm reverting.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
该模型的复杂性来自公共分支“
test
”,其中完成了太多操作。我宁愿:
F1
+F2
+F3
隔离在它自己的分支“integ'
prod
上重置test
(前提是每个人都清楚重置的后果,并准备好重置他/她自己的本地克隆分支test)。
integ
合并到test
上(返回在这三个功能上完成的所有工作,但基于prod
)The complexity of this model comes from the common branch '
test
', where too much operations are done.I would rather:
F1
+F2
+F3
in its own branch 'integ
'test
onprod
(provided everybody is clear on the consequence of a reset, and is ready to reset his/her own local cloned branchtest
).integ
ontest
(getting back all the work done on those three features, but based onprod
)