我们正在使用git来跟踪开发和版本化版本,并遇到了一些合并分支的问题。这是我们的工作流程:
production/1.0.0 A--B
stage/2.0.0 A--B--C--D
development E--F--G--J--L
\
feature H--I--K
功能开发发生在从开发中创建的功能分支上,并在准备就绪时合并回来进行演示和测试。
这一切都运行良好,问题在于创建该功能分支的开发人员将其功能放入阶段分支进行部署。因为他们在G的开发中分支,当他们去合并时,它包括EFG,当他们只想合并HIK时。
我们的git工作流程的目标是让开发人员标记自己的代码以备发布,并协调整个开发分支将能够合并到部署分支是不可行的,因为开发发生在世界各地。
是否有一个git命令来合并在功能分支上进行的提交?我知道rebase和cherry pick,但是一个功能可以由大量的提交组成,其中包括开发追赶其功能分支的合并。有更好的解决方案吗?
此工作流程是否正确?我们是在尝试做一些不可持续的事情吗?
答案 0 :(得分:5)
这将是git rebase --onto
加上git merge-base
:
git checkout stage/2.0
git rebase --onto stage/onto $(git merge-base development feature) feature
这将重放 feature
之后的G
分支的提交(这是"合并基础"开发和功能之间的提交)到stage/2.0 branch
。
结果:
stage/2.0.0 A--B--C--D
\
feature H'--I'--K'
development E--F--G--J--L
旧的H
,I
和K
提交仍会在reflog(git reflog
)中引用,但已被挑选并在{{{{{ 1}}。
此工作流程是否正确?我们是在尝试做一些不可持续的事情吗?
以下是警告:
它需要在这样的变基之后进行仔细测试,因为stage/2.0
,H
和I
在K
之上完成,G
中根本不存在stage/2.0
1}}分支。
如果这些提交依赖于基于G
的内容,则在暂存分支中找不到该初始内容。一些回归测试应该表明这一点。
使用git cherry-pick
(也是can replay multiple commits)将复制这些提交到暂存分支上,保留feature
分支(即不在分期分支)
这看起来很奇怪,考虑到你需要开始哪些提交被挑选出来,以及其他新的feature
提交尚未被挑选出来进行分期。
如果将开发合并到
I
和K
之间的功能中,会发生什么? (开发者缓存他们的分支)
樱桃挑选还包括合并和所有开发分支代码吗?
是的,它将包括合并提交,但不包括所有dev
分支。无论如何,它并不理想。最佳做法是不要将dev
合并到feature
,而是在feature
(dev
)之上重新定位git rebase dev
。
然后,当功能准备就绪时,rebase --onto stage/2.0
那么
rebase --onto
命令的作用基本上是将功能分支移到stage/2.0.0
上?
是
功能分支是否会消失?
否:通过将每个提交补丁重新应用到 stage/2.0.0
来重新创建。
在rebase --onto
之前看到的功能分支的旧提交仍然存在,但不可见,仅由git reflog
引用,如上所述。
嵌套命令
$(git merge-base development feature)
是否在将分支移动到stage / 2.0.0分支之前将更改从功能应用到开发?
否:计算该功能分支的起始提交,即:从development
分支开始的feature
提交。
如果我没有使用它,只是一个简单的git rebase
,来自feature
分支的提交将包括所有提交,可以从feature
HEAD访问(这将包括< em>还 development
提交)