将修补程序合并到多个分支?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (12)

我一直在试着把头绕在Git分支模特身上。我一直在看对于一些想法和颠覆,我真正期待的一件事是在一个地方做一个改变,并将它合并到所有需要它的分支。在Subversion中,我们最终完成了大量代码的复制工作。

不过,我还是不完全明白。下面是我所拥有的一种标准工作流类型,它总是会产生冲突。

# create new version branch
git checkout master
git checkout -b v3
vim pom.xml  # change branch version to "3.1-SNAPSHOT"
git commit -a
git checkout master
vim pom.xml  # change master version to "4.0-SNAPSHOT"
git commit -a

所以主服务器是4.0快照,分支是3.1快照。

不,我想在分支上创建一个修复程序并将其移动到主干。

git checkout v3
git checkout -b hotfix
vim file.txt  # make a bugfix change
git commit -a
git checkout v3
git merge hotfix  # this works fine
git checkout master
git merge hotfix  # this has a conflict since both branches have changed the version

我明白为什么会发生这种事,这是有道理的。有更好的方法吗?

我测试了它,并做了一些工作:

git checkout v3
git cherry-pick a518b0b75eaf28868
git checkout master
git cherry-pick a518b0b75eaf28868

然而,这似乎并不是处理这个问题的“正确”方法。有什么建议吗?

提问于
用户回答回答于

真的,你的答案取决于你是否希望你的树建立在相同的历史基础上。例如,4.0是基于最新的3.x+4.0中的所有更改.

就我个人而言,一旦你决定为一个新的版本开始一个新的分支,我就不推荐它。在给定的时间点,软件正在采取不同的方向,所以你的分支也应该如此。

这就剩下了git cherry-pick作为你的理想解决方案。在任何最有意义的分支中做出改变,然后再将它挑选成旧版本。这和你查过老分行的情况一样手动应用了相同的更改,并进行了新的提交。它能保持它的清洁和重点。

Git合并或Rebase将尝试将分支历史集成在一起,每个分支都有各自的方式,我怀疑您在修复bug时不希望这样做。

用户回答回答于

如果想获得有关它的超级技术,可以从一个共同的祖先创建修补程序:

git merge-base v3 master
git checkout -b hotfix <whatever you got from merge-base>
# make your fix
git checkout v3 && git merge --no-ff hotfix
git checkout master && git merge --no-ff hotfix

        v3--------v3 (hotfixed)
       /         /
ancestor----hotfix
       \         \
        master----master (hotfixed)

--no-ff标志保持hotfix在修补端处的分支标签,而不是将标签拉到v3master

就我个人而言,我觉得这太过分了。在有意义的枝条上做个修复,然后根据你想要的枝条之间的联系。

扫码关注云+社区