将修补程序合并到多个分支？内容来源于 Stack Overflow，并遵循CC BY-SA 3.0许可协议进行翻译与使用
内容来源于 Stack Overflow，并遵循CC BY-SA 3.0许可协议进行翻译与使用
- 回答 (2)
- 关注 (0)
- 查看 (16)
我一直在试着把头绕在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在修补端处的分支标签，而不是将标签拉到v3或master。
就我个人而言，我觉得这太过分了。在有意义的枝条上做个修复，然后根据你想要的枝条之间的联系。
扫码关注云+社区