Git有助于理解合并基础冲突

我在没有修改的文件上遇到冲突.合并时,一行文件的冲突会发生变化.我开始处理可能发生的事情,但仍然无法解决问题.

这是分支结构.

主

current_iteration

mapr_autoinit

Master已经很老了,并且在相当长的一段时间内没有从current_iteration进行过更改.然而,master通过直接将其他碱基重新定位到master上来直接应用它.所以技术上master和current_iteration已经分道扬.. 我们始终对current_iteration进行分支和标记.我看到的问题是,当我从current_iteration合并回到我的分支时.根据对current_iteration的更改,我遇到的冲突多于应该发生的冲突.我能够从current_iteration做一个git diff/git apply,它应用得很干净.

当我git show-branch --merge-base在mapr-autoinit上运行时,我看到提交实际上是几个月前的主提交.但是,当我检查时,git merge-base current_iteration mapr_autoninit我发现该版本是非常新的,很可能不会有冲突.

从我在过去几天看到的情况来看,如果我将master合并到current_iteration,提交然后将current_iteration合并回master,这似乎是合乎逻辑的.这可能应该解决我的分支merge-base指向更新版本.

也有可能我可以停止跟踪主人.我尝试使用git config --unset branch.master.merge; git config --unset branch.master.remote停止跟踪主人,但这并没有解决我的问题.

这是一个问题,其中master和current_iteration已经分歧,并且merge正在尝试通过重放整个日志来协调合并？

这里还有更多细节.我现在开了一个新问题,问题更具体.我将使用有效的答案更新两者或删除旧的,具体取决于哪个是首选.

Git合并导致不合理的冲突

我自己从来没有发现git show-branch输出非常有用,我不确定它是如何被使用的,也不确定其他人如何成功使用它.

也有可能我可以停止跟踪主...

这无关紧要.重要的是实际的提交图.任何分支的上游都独立于提交图.

这是一个问题,其中master和current_iteration已经分歧,并且merge正在尝试通过重放整个日志来协调合并？

第要紧后的合并基础调查仅仅是-合并基础提交,即加两个分支的顶端提交.介于两者之间的一切都无关紧要.

但是,当我检查时,git merge-base current_iteration mapr_autoinit我发现该版本是非常新的,很可能不会有冲突.

这通常是入门的方式,因为git merge-base检查提交图,并使用它来计算合并基础提交.请注意,git merge默认情况下运行相当于git merge-base --all.如果这会产生多个合并库(多个提交哈希ID),则会出现特殊情况.我们假设您现在不这样做,但检查是个好主意.

找到合并库提交后,您可以查看git log输出(请参阅上一节)并查看合并库如何与两个分支提示相关联.Git并不关心这一点,这不太对劲:在Git找到合并基础(取决于此)后,Git不再关心它 - 但你可能会觉得它很有帮助.

找到(单个)合并基础current_iteration和mapr_autoinit(假设你在这两个分支之一),这是Git的作用:

git diff --find-renames  current_iteration > /tmp/1
git diff --find-renames  mapr_autoinit > /tmp/2

我将这些/tmp文件重定向到这里的文件,以便于多次查看和并排查看,具体取决于您的文件查看器.因为我不知道你要合并的方向 - 从什么,到什么 - 我只是编号这两个文件,而不是称它们为"我们的"和"他们的".注意,无论如何,组合变化步骤在很大程度上是对称的.对于每个文件的每次更改,有四种可能性:

你碰到了线条而他们没有:Git接受你的改变.

他们碰到了这些台词而你却没有:Git采取了他们的改变.

你和他们触及了这些界限,但是你做了同样的改变:Git只需要一份改变.

您和他们触及了这些行,但做了不同的更改:Git声明了合并冲突,并将两组更改放入工作树文件中.如果你设置merge.conflictStyle为diff3-I 强烈推荐这个-Git也包括合并基础版本,以向你展示你和他们在你做出相互冲突的变化之前的开始.

查看结果,与合并冲突标记,并与基础版本包括-通过merge.conflictStyle设定为diff3,是通常就足够了.(特别是,它有时会显示Git具有错误配对更改并认为它们发生冲突的情况,实际上这些更改是针对其他不冲突的区域.)如果不是,则查看提交图可能会有所帮助.

有关提交图的更多信息

东西做的工作,但可能很难弄明白的,¹是输出git log --graph.包含--decorate --oneline选项很有帮助,对于这种特殊情况,您需要列出当前分支²和要合并的分支的名称.例如,如果您已mapr_autoinit签出并打算运行git merge master,则可以运行:

git log --graph --decorate --oneline mapr_autoinit master

Git将尽力在ASCII艺术中绘制,并添加可选的额外颜色以帮助提交图.当然,结果在很大程度上取决于图中的内容.以下是来自Linux内核的Git存储库的片段:

* 1ffaddd029c8 (HEAD -> master, tag: v4.18-rc8, origin/master, origin/HEAD) Linux 4.18-rc8
*   a8c199208cd6 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
|\  
| * 1b3a62643660 x86/boot/compressed/64: Validate trampoline placement against E820
* |   2f3672cbf9da Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
|\ \  
| * | 0a0e0829f990 nohz: Fix missing tick reprogram when interrupting an inline softirq
| * | 80d20d35af1e nohz: Fix local_timer_softirq_pending()
* | |   0cdf6d4607df Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

可以使用它来跟踪自合并基础以来发生的事情.还有更多工具:

git log --graph --decorate --oneline --boundary mapr_autoinit...master

比如会告诉你什么是不能合并(提交标注*),加(由于--boundary)该边界提交的合并(提交标注o),但没有去任何深入的图形比.

对于非常简单的情况 - 对于--left-right三点语法的内部分支和重新合并而言并不可怕的图表有时也是有用的.对于复杂的情况,每条腿都有很多内部分支和合并操作,--first-parent有时很有用,--simplify-by-decoration有时也很有用.

¹尽管如此,它仍然值得一试.如果你愿意,可以使用GUI或者类似的东西更精确地绘制图形,但要注意至少一些Git GUI似乎绘制了不正确的图形(咳嗽各种咳嗽 webservices 咳嗽).

²您始终可以使用HEAD全部大写字母的名称代替当前分支名称.例如,全小写适用于Windows和MacOS上不区分大小写的文件系统,但这种习惯并不好.但是,在任何现代Git中,单独的符号@意味着HEAD,所以如果您愿意,请使用它而不是拼写出来HEAD.请注意,当使用两个或三个点语法(A..B和A...B),完全忽略一个名字也意味着HEAD:HEAD..B,@..B,和..B三种拼写为同样的事情.