我该如何通过git历史记录查看提交路径,或者说“它是如何进入当前分支的”?

4
我正在使用 gitkgit log 查看提交历史记录,并尝试查看特定提交如何到达某个分支。我可以在历史记录中看到这些提交,所以我知道它们存在。
我想了解的是它们是如何被合并的(它们本应该保留在自己的分支上)。这是一个非常大的项目,在特定提交和当前分支状态之间有数百个提交,所以我无法清楚地通过 gitk 中有限的 DAG 进行辨析,而且该提交会被其他分支、合并和提交消息掩盖。
为此,我一直在尝试:
gitk {sha1hashIDstring}..branch_name
gitk {sha1hashIDstring}..branch_name --ancestry-path
git log {sha1hashIDstring}..branch_name --reverse
git log {sha1hashIDstring}..branch_name --merges --reverse
git log {sha1hashIDstring}..branch_name --ancestry-path --reverse
git log {sha1hashIDstring}..branch_name --ancestry-path --merges --reverse

我不理解这些结果。我只想看到包含特定提交的项目,以便清楚地了解它是如何进入相关分支的。我该如何做?

示例

我想在gitk中查看,但如果使用git log也可以:

Message       Author         Date         #commit that merged branch z into current branch
Message       Author         Date         #commit that merged branch y into branch z
Message       Author         Date         #commit that merged branch x into branch y
Message       Author         Date         #commit that merged {sha1hashIDstring} commit/branch a into branch x
Message       Orig_Author    Date         #{sha1hashIDstring} original commit, on branch a

更多信息

我还没有看到任何答案,所以如果没有人回答,我会开始设置悬赏,但也许我没有正确解释问题(我乐意听取改进和澄清的建议)。

这样做的原因是我可以看到提交本身,并被告知它不应该在某个特定分支上。这是我所看到的:

Message       Orig_Author    Date         #{sha1hashIDstring} commit
Message       Orig_Author    Date         #Merged into branch test_dec14 (includes original commit)
...
Message       Author         Date         # unrelated commits
Message       Author         Date         # more unrelated commits
# Stuff happened here ??? everything I do gives me hundreds of things here 
# Not all of them related to the {sha1hashIDstring} commit
# No idea how to see only the ones that are
...
Message       Author         Date         # final commit on test_jan15 branch

有人告诉我,如果没有发布,test_dec14中的提交不应该出现在test_jan15中,因此{sha1hashIDstring}提交不应该出现在test_jan15中,但它确实出现了。我想知道为什么会这样,它是如何出现的,谁放进去的。


我猜你是在使用 "--merges" 而不是 "--merge"?git log sha..branch --ancestry-path --merges - Andrew C
是的,已编辑 - 谢谢。 - Ehryk
输出列表列出了分支 HEAD 和提交之间的数百个提交,其中大多数与将特定提交合并到分支无关。 - Ehryk
--ancestry-path --merges 在我的代码库中提供了合理的输出。不知道为什么在你的代码库中不能。 - Andrew C
正如我之前提到的,这是一个庞大的项目。它有约30名全职开发人员,并且由于gitk无法显示所有开发人员的DAG,因此会出现断层。我只想看到与将特定提交放入所选分支有关的提交。 - Ehryk
显示剩余5条评论
5个回答

2
对于您问题的后半部分,“它是如何进入当前分支的?”,请查看 git-when-merged
这是一个Python脚本,根据其自述文件:

查找提交合并到一个或多个分支的时间。查找将COMMIT合并到指定BRANCH(ES)的合并提交。具体来说,查找包含COMMIT作为祖先的BRANCH的第一个父历史记录中最旧的提交。

这听起来就像您在确定{sha1hashIDstring}提交何时合并到test_jan15分支的情况下所需要的。

1

我谷歌了一些内容并为您找到了一些信息。功劳归于#vonC

git when-merged [OPTIONS] COMMIT [BRANCH...]

查找提交(commit)合并到一个或多个分支的时间。 查找将提交(commit)带入指定分支(es)的合并提交(merge commit)。

具体来说,查找包含提交(commit)作为祖先的第一父历史记录中最早的分支(BRANCH)。

git-what-branch

发现提交(commit)所在的分支,或者它是如何到达命名分支的。 这是Seth Robertson的一个Perl脚本,看起来非常有趣:

SYNOPSIS

git-what-branch [--allref] [--all] [--topo-order | --date-order ]
[--quiet] [--reference-branch=branchname] [--reference=reference]
<commit-hash/tag>...
OVERVIEW

默认情况下,该命令告诉我们引起所请求的提交进入指定分支的最早提交和合并的因果路径。如果提交直接在指定分支上进行,则显然是最早的路径。 通过最早的因果路径,我们指的是按提交时间(除非指定--topo-order)最早合并到命名分支的路径。 性能 如果许多分支(例如数百个)包含提交,则系统可能需要很长时间(对于linux树中的特定提交,探索一个分支需要8秒,但有200多个候选分支)来追踪每个提交的路径。 选择特定的--reference-branch --reference tag进行检查将快几百倍(如果您有数百个候选分支)。
**EXAMPLES**
 # git-what-branch --all 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4
 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4 first merged onto master using the following minimal temporal path:
   v2.6.12-rc3-450-g1f9c381 merged up at v2.6.12-rc3-590-gbfd4bda (Thu May  5 08:59:37 2005)
   v2.6.12-rc3-590-gbfd4bda merged up at v2.6.12-rc3-461-g84e48b6 (Tue May  3 18:27:24 2005)
   v2.6.12-rc3-461-g84e48b6 is on master
   v2.6.12-rc3-461-g84e48b6 is on v2.6.12-n
   [...]

谢谢,这也很有用。 - Ehryk

1

你尝试过使用git log的“--decorate”选项吗?

我在我的.gitconfig中有这个别名:

[alias]

        k = log --graph --oneline --abbrev-commit  --decorate
它展示了一个类似于gitk所展示的图形,其中在分支的最近提交旁边“装饰”着分支名称。

--

还可以尝试使用tig。 在我的使用中,它比gitk更具信息性;)。 可以参考http://gitready.com/advanced/2009/07/31/tig-the-ncurses-front-end-to-git.html。 我认为任何一个解决方案都能给你所需的结果。


1

我一开始也是这么想的,但这并不能帮助他。听起来他已经知道了相关的提交,现在他正在尝试追踪它是如何合并的,以及谁做的。 - eddiemoya

0

我知道这个问题没有标记为“GitHub”,但如果项目在那里,Blame或History的视觉样式(在查看特定文件时文件头中的按钮)可以使跟踪事情发生的时间变得更容易。

不确定这是否实际解决了这个(非常)具体的问题,但它可能会帮助其他遇到类似问题的人找到这个问题...


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接