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

Question

我一直试图围绕git分支模型.我一直在关注http://nvie.com/posts/a-successful-git-branching-model/以获取一些想法并从Subversion获得一件我真正期待的事情就是在一个地方进行改变将它合并到需要它的所有分支.在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-SNAPSHOT,分支处于3.1-SNAPSHOT.

不是我想在分支上创建一个修补程序并将其移动到主干.

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

但是,这似乎不是处理此问题的"正确"方法.有什么建议？

Answer 1

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

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标志是有没有强调Git会创建一个合并提交,保持hotfix分支标签在修补程序尖,而不是拉动标签v3或master.(您可以省略该标志并获得相同的行为,因为hotfix分支有一个不在的提交master或v3.文档中的更多信息.)

就个人而言,我认为这太过分了.我会选择gahooa:在有意义的分支上制作修补程序,然后根据你希望分支相互关联的方式合并或挑选.

Answer 2

真的,你的答案取决于你是否希望你的树基于相同的历史......例如,4.0基于最新的3.X + 4.0中的所有变化......

就个人而言,一旦您决定为新版本开始新的分支,我不建议您这样做.在给定的时间点,软件采取不同的方向,所以你的分支机构也应该.

这git cherry-pick是您理想的解决方案.在任何分支最有意义的情况下进行更改,然后将其选择到旧版本.这与检出旧分支并手动应用相同更改并进行新提交相同.它保持清洁和重点.

Git merge或rebase将尝试将分支历史集成在一起,每个都以自己的方式,我怀疑你在向后移植错误修复时不想要等等...