Git工作流:如何合并仅在新分支上进行的提交

Question

我们正在使用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,但是一个功能可以由大量的提交组成,其中包括开发追赶其功能分支的合并.有更好的解决方案吗？

这个工作流程正确吗？我们是在尝试做一些不可持续的事情吗？

Answer 1

那将git rebase --onto与git merge-base：

git checkout stage/2.0
git rebase --onto stage/onto $(git merge-base development feature) feature

那会在（）之间重播feature分支的提交（这是开发和功能之间的“合并基础”提交）。 Gstage/2.0 branch

结果：

stage/2.0.0       A--B--C--D
                            \                   
feature                      H'--I'--K'

development       E--F--G--J--L

老H，I以及K提交在该引用日志（仍然被引用git reflog），但都被樱桃采摘和回放之上stage/2.0。

这个工作流程正确吗？我们是否正在尝试做一些不可持续的事情？

需要注意以下几点：
在进行这种重新设置之后，需要进行仔细的测试，因为H，I并且K在之上完成了G，而stage/2.0分支中根本不存在。

如果这些提交依赖于基于的内容G，则该初始内容将不会在暂存分支中找到。一些回归测试应该使这一点显而易见。

使用git cherry-pick（也可以重播多个commit）会将这些提交复制到登台分支上，而使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分支将包括所有可触及提交featureHEAD（这将包括同样的development提交）