6

我们正在使用 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，但是一个特性可以由大量的提交组成，开发中的合并可以赶上它们的特性分支。有更好的解决方案吗？

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

4

1 回答 1

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) 中被引用，但已经被精心挑选并在stage/2.0.

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

确实是这样，但需要注意的是：
在这样的变基之后，它需要进行仔细的测试，因为H,I以及K在 之上完成的地方，分支G中根本不存在。stage/2.0

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

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

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

是的，它将包括合并提交，但不包括所有dev分支。无论如何，它并不理想。最佳实践不是合并dev到feature，而是在( )feature之上重新定位。 然后，当功能准备就绪时，devgit 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分支的提交将包括从HEAD访问的所有提交（这也将包括提交）featuredevelopment

于 2016-06-12T15:23:33.100 回答