我个人从未觉得git show-branch
的输出很有用,也不确定它的使用意图以及其他人如何成功地使用它。
同时,我是否可以停止跟踪master分支...
这是无关紧要的。重要的是实际提交记录。任何分支的上游都独立于提交记录。
这是一个问题吗,其中master和current_iteration分支已经分叉,并且合并正在尝试通过回放整个日志来协调合并?
不是。在找到合并基之后,重要的是仅有的内容是合并基提交,也就是两个分支端点提交加起来。中间的所有内容都是无关紧要的。
但是当我检查git merge-base current_iteration mapr_autoinit
时,我发现版本非常新,很可能不会产生冲突。
这通常是开始的方法,因为git merge-base
检查提交历史,并使用它计算合并基提交。请注意,默认情况下,git merge
运行等效于git merge-base --all
。如果这产生了多个合并基(多个提交哈希值),则您有一种特殊情况。现在假设您没有,但是检查一下是个好主意。
找到合并基提交后,您可以查看git log
输出(参见最后一节),并查看合并基如何与两个分支端点相关联。Git并不关心这个问题,好吧,不完全正确:在Git找到合并基之后(这取决于此),Git停止关心它,但是您可能会发现它有帮助。
找到current_iteration
和mapr_autoinit
的(单个)合并基(并假设您位于其中一个分支上)后,Git将执行以下操作:
git diff --find-renames <merge-base-hash> current_iteration > /tmp/1
git diff --find-renames <merge-base-hash> mapr_autoinit > /tmp/2
为了方便多次查看和并排查看,我将它们重定向到这里的/tmp
文件。由于我不知道您从哪里合并——从哪个版本到哪个版本——所以我只是对这两个文件进行了编号,而不是称它们为“我们的”和“他们的”。请注意,在“合并更改”步骤中,情况基本上是对称的。对于每个文件的每个更改,有四种可能性:
- 您在修改这些行而他们没有:Git会接受您的更改。
- 他们在修改这些行而您没有:Git会接受他们的更改。
- 您和他们都修改了这些行,但您做出了相同的更改:Git会采用一份更改副本。
- 您和他们都修改了这些行,但是做出了不同的更改:Git会声明合并冲突,并将两组更改放入工作树文件中。如果您设置了
merge.conflictStyle
为diff3
——我强烈建议这样做——Git还会包括合并基础版本,以显示您和他们在开始之前做出的更改。
通常情况下,通过将合并冲突标记和基础版本包含在内,使用merge.conflictStyle
设置为diff3
即可满足需求。(特别是在某些情况下,Git会错误地将更改配对,并认为它们存在冲突,而实际上这些更改是针对不冲突的其他区域做出的。)如果不行,可以查看提交历史。
有关提交历史的更多信息
git log --graph
的输出结果通常会起作用,但很难理解。1建议使用--decorate --oneline
选项,并列出当前分支2和您打算合并的分支的名称。例如,如果您已经检出了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
有时很有用。
1尽管如此,它仍然值得一读。 如果您愿意,可以使用绘制图形更漂亮的GUI或类似工具,但请注意,至少某些Git GUI似乎会绘制不正确的图形(咳咳各种网络服务咳咳)。
2您始终可以使用大写字母的名称HEAD
代替当前分支名称。 在Windows和MacOS等不区分大小写的文件系统上,全小写字母也起作用,但养成这种习惯并不好。 在任何现代Git中,单独的at符号@
都表示HEAD
,如果您愿意,请使用它代替拼写出HEAD
。 请注意,在使用两个或三个点语法(A..B
和A...B
)时,完全省略一个名称也意味着HEAD
:HEAD..B
、@..B
和..B
是同一事物的三种拼写方式。
git merge <hash-of-other-commit>
,看看Git如何合并它们。如果结果与您感兴趣的合并不匹配,则执行合并的人必须使用了额外的选项或进行了邪恶合并等操作。 - torek