最近在工作中,我们已经从使用SVN切换到使用git.我们必须维护我们软件的多个版本,之前我们将它们设置为分支.所以在使用之后git svn clone,我们最终得到了4个分支:master,5.0,5.1和5.2.
注意:我们使用master作为我们的开发分支.5.0,5.1和5.2都是来自master的分支,并用作生产分支.
几天过去了,相当多的变化已经成为主人.在5.2中发现了一个错误,我们想要修复它.我们尝试了将一个更改合并到Git中的多个分支的解决方案.我们总是可以轻松地合并回主人,但每当我们合并回5.2时,我们就会遇到一堆冲突.我们看到的所有内容都显示了这个过程(为bugfix创建了一个新的分支并将其合并回开发和生产),这表明它应该如下所示:
(master)$ git checkout -b bugfix
# fixed bug and committed
(bugfix)$ git checkout master
(master)$ git merge bugfix
# successful merge
(master)$ git checkout 5.2
(5.2)$ git merge bugfix
# successful merge
然而,对于我们来说,当我们到达最后一行时,git merge bugfix我们会遇到大量冲突.我们甚至没有在错误修复中触及的文件冲突.我们做错了什么？
注意:我们也尝试通过启动5.2中的bugfix分支来完成此过程.然后将错误修复程序合并到5.2中很容易,但将错误修复程序合并到master中会产生冲突.
显示该过程的其他地方:
abl*_*igh 12
几年前,我们将一个非常大的项目从SVN转移到了git.这是我一直提出的问题.
首先(这一点不是你问题的答案,它是"你为什么问这个问题？"这个问题的答案),请阅读:http: //nvie.com/posts/a-successful-git -branching-model / 并接受它可能是正确的,这意味着放弃你的一些SVN心态.这对我来说是最难的.
现在你已经完成了,我会回答这个问题.
最佳途径是:
确保您始终可以将任何较旧的分支合并到任何较新的分支中,而不会影响较新的分支
执行您需要修复的任何错误修复,修复您想要修复的最旧的分支.然后将其顺序合并到新分支中,随时修复合并冲突.
做第二个使第一个总是工作(如果你考虑它).
只要任何给定分支中的变更集始终包含来自所有旧分支的所有变更集,该技术对于许多不同年龄的分支都是可扩展的.
但是,上面的第二个要点假设一个理想的世界:
你确切知道哪个是你在进行错误修复时需要执行错误修复的最老的分支(即没有人来找你并说"嘿,我们需要将错误修复后移,这会导致问题顾客X也是).
每个分支的错误修复总是相同的(例如,您为旧分支执行创可贴最小熵修复).
您可以通过git cherry-pick选择提交到旧分支来解决第一个问题.但后来(这是重要的一点)将修复程序合并到较新的分支(即使它已经存在).您可以通过明智和极其谨慎的使用来做到这一点:
git checkout newer
git merge older # check it's all merged up
git checkout older
git cherry-pick xxxxx
... fix up cherry pick, check it works ...
git checkout newer
git merge -s ours older
请注意,这标记了合并但实际上忽略了旧分支中已更改的所有内容,因此在更改之前检查它是否合并非常重要.
第二种情况可以类似地处理.应用真正的修复程序newer.检查older合并到newer,然后应用你的绑带older,然后使用git merge -s ours older.