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分支开发，当他们去合并的时候，他们只想合并HIK的时候包括EFG。

我们的 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 分支的提交之后 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) 中被引用，但在 stage/2.0 之上进行了精心挑选和重播。

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

确实如此，但需要注意以下几点：
在这样的 rebase 之后需要进行仔细的测试，因为 H、I 和 K 是在 G 之上完成的，而 stage/2.0 分支中根本不存在。

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

使用git cherry-pick（也称为can replay multiple commits）会将这些提交复制到暂存分支，使feature 分支保持原样（即不重新基于暂存分支）。
这似乎很奇怪，考虑到您需要开始挑选哪些提交，以及尚未挑选出哪些其他新的feature 提交来暂存。

---

如果将开发合并到 I 和 K 之间的功能中会发生什么？ （开发人员缓存他们的分支）
樱桃选择是否还包括该合并以及所有开发分支代码？

是的，它将包括合并提交，但不包括所有 dev 分支。无论如何，它并不理想。最佳实践不是将dev 合并到feature，而是在dev (git rebase dev) 之上重新设置feature。
然后，当功能准备就绪时，rebase --onto stage/2.0

---

那么rebase --onto 命令所做的基本上是将功能分支移动到stage/2.0.0 上？

是的。

功能分支会消失吗？

否：通过重新应用每个提交补丁 onto stage/2.0.0 重新创建它。
在rebase --onto 之前看到的功能分支的旧提交仍然存在，但不可见，仅由git reflog 引用，如上所述。

嵌套命令$(git merge-base development feature) 是在将分支移动到stage/2.0.0 分支之前应用从特性到开发的更改吗？

否：它是计算该功能分支的起始提交，即：feature 分支开始的development 提交。
如果我不使用它，而是使用简单的git rebase，则来自feature 分支的提交将包括可从feature HEAD 访问的所有 提交（这将包括也 development 提交）