有没有一种方法可以显示从HEAD到特定用户所做的提交的git日志图?

时间:2018-12-07 19:21:35

标签: git git-log

我们的日常构建是由自动化用户完成的,它将使用消息中的构建信息对仓库进行空提交。

我想知道是否可以:

  1. 从我当前在该自动用户和/或
  2. 提交的回购中的位置获取最后一个日志条目(或 n 个日志条目)
  3. 显示从HEAD到同一自动用户提交的图形,其中显示了在此之间进行的所有用户提交。

可以只使用git命令,还是必须做一些外部处理?

2 个答案:

答案 0 :(得分:1)

编辑:为方便起见,我在下面添加了一些(较长的)背景。

(要查找特定用户的提交,请使用--author=。这适用于大多数修订修订操作,因为它是由git loggit rev-list以及其他Git实现的命令使用这些。)

考虑使用git log --ancestry-path --graph [options] automated-commit..HEAD,但有一些注意事项:

  • 自动提交和HEAD提交之间可能没有 路径。
  • 如果有路径,则HEAD提交位于自动提交的后面,则可能相反。

还要注意,Git将忽略边界(停止点)提交-即,在A..B中,Git确实在做B ^A,因此它包括提交B,但不包括提交A。如果还希望包含提交A,则有几种选择:

  • 备份一个提交作为停止点:使用^A^,假设A只有一个父对象,如果^A^@可以合并,则使用A提交(A^@的意思是“ A的所有父母,而前导^从扩展A..B到其内部B ^A的形式,此处具有普遍性)

  • 或者,使用--boundary使Git包含边界提交。根据我的经验,Git倾向于添加过多的边界提交,但是--ancestry-path可能会消除这种情况,因为--ancestry-path通过要求显示的提交以A..B作为祖先来增强通常的A

(最重要的是:只要有一条路径,并且您能正确地定购订单,它就应该可以工作。要使它真正有用,并处理各种情况,就更难了。)

背景:git log及其姐妹git rev-list的工作方式

在Git中,提交是通过其真实名称(即其哈希ID)知道和找到的。每个提交的哈希ID是一个丑陋的大字符串,例如8a0ba68f6dab2c8b1f297a0d46b710bb9af3237a(它是a commit in the Git repository for Git itself。)每个ID是唯一的:没有其他提交可以拥有此ID。它们实际上不是随机的,但是它们似乎是随机的,并且对人类没有用,因此我们使用诸如masterdevelop之类的名称。 Git会保留一张不断更新的表格,例如 master的意思是8a0ba68f6... ,等等。

使用这些表条目,我们说master 指向一些提交。假设master指向一些提交,我们将其哈希ID缩短为一个大写字母G

G   <--master

(稍后您会看到为什么我将master放在右边)。

向分支添加新提交只会更新名称到哈希ID的映射:创建一个新提交,Git为它分配一个唯一的哈希ID,如果您使用的是master,则Git更新master的表条目包含该新的哈希ID:

H   <--master

这意味着某些分支名称指向的提交(分支名称中存储的箭头)随时间变化。这就是Git如何找到该分支的最新提交的方式。根据定义,为该分支名称保存的任何提交哈希,该 都是该分支的提示。

现在,每个提交都拥有一定数量的 parent 哈希ID,通常是一个。 的意思是,给定一个表** mastera1234...,并提交a1234...表示我父母为{{1 }} ,Git知道0f987...是master上的最新提交。然后,Git 读取提交a1234...,以找到对master的第二最新提交,a1234...。因此,0f987...指向最新提交master,该提交指向其父对象,其父对象指向祖父母,依此类推。

这意味着从 end 开始,Git可以在整个提交链中向后工作:

a1234...

名称... <-F <-G <-H <--master 使Git能够找到提交master,它可以找到提交H,可以找到G,依此类推,直到历史。因此,历史记录只是所有提交的字符串,从结尾开始并向后工作。

特殊名称F通常包含分支的名称。有两种相当明显的绘制方法,一种是HEAD指向分支名称,然后是指向提交的分支名称:

HEAD

在某些方面更准确,但不是很紧凑。为了紧凑起见,我喜欢省略提交本身内的箭头。它们永远不会改变(与分支名称箭头不同)—关于任何提交的任何事情都不会改变。因此,如果我们看到:

                      HEAD
                       |
                       v
... <-F <-G <-H   <--master

我们知道...--F--G--H 指向H,而G指向G,依此类推。然后,我有一个从F来的箭头找到master

H

为此,我将单词...--F--G--H <-- master 附加到 ,以表示这是 current 分支,这样,如果我们有更多分支,我们可以看到什么继续:

HEAD

在这里,我们有两个分支;名称...--F--G--H <-- master (HEAD) \ I--J <-- develop 指向提交develop,其父级为J,它返回到IG,依此类推,而名称{{1 }}指向F,指向masterH,依此类推。

在旁边:某个提交“在”哪个分支上?

看看上面的内容,可以说提交GF上,而Hmaster上。这很自然,因为这些名称直接指向那些提交。但是关于提交J,它在哪个分支上呢?

某些系统会选择一个答案并坚持下去。 Git是不同的。 Git说develop在每个可以到达G 分支上,所以它在 G / em> G。为了从masterdevelop,我们回跳了一跳。要从Gmaster,我们要返回两跳。无论哪种方式,我们都会降落在G上。

developG只需遵循以下箭头

考虑到某个起点,例如git loggit rev-list甚至是masterdevelop所做的只是太简单了一点:

  • 显示当前具有的提交,无论是什么。
  • 继续进行父提交。
  • 重复直到我们用尽提交。

此说明不是错误,但是缺少许多重要的细节。第一个并发症来自合并。让我们使用以下方式将图远的图像和 merge HEAD回到git log中:

develop

无需深入研究 master的工作原理(这是它自己的问题和答案(但已经被问过很多次了)),我们最终得到以下图表:

$ git checkout master
$ git merge develop

提交git merge合并提交,这意味着它至少有两个父母。 ...--F--G--H---K <-- master (HEAD) \ / I--J <-- develop 的两个父对象分别是KK(因为我们合并了提交H,就像通过名称J找到的一样)。 / p>

J显示提交develop之后,应该继续执行哪个提交?它可以选择任何一个。它真正的作用是将都提交到队列中,然后选择一个并显示它,然后将其父对象放入队列(如果尚未这样做)。然后从队列中选择另一个,然后重复:

  • 最初,将命令行上列出的提交放入队列。如果您没有指定任何特定的提交,则git log使用K。然后,在循环中:
    • 显示在队列前面的提交。
    • 如果提交的父母尚未排队并且尚未显示,则将他们全部放入队列。
  • 重复循环,直到队列为空(或用户退出)。

因为有一个队列,所以管理谁在最前线上存在一些魔术。默认情况下,这是按日期/时间戳排序处理的,但是您可以使用各种排序选项进行更改。

这意味着默认情况下,git log的Git将首先显示HEAD,然后是 git log K,然后一个{em> HJ,然后另一个另一个 HI ,现在队列中只有H,因此顺序很明确(I,然后是G)。请注意,如果不通过G,Git就无法到达F,因此I肯定比J早出现,但是Git可以两步到达J方式,所以我们不确切知道I的出处。

对排队和/或显示内容的限制

无论您做什么,HH 总是都必须遍历此优先级队列,选择要显示的下一个提交,将父提交添加到队列中,然后循环播放。但是您可以控制添加哪些父母和/或哪些提交实际显示

父母控制旋钮是:

  • git log:这表示当步行代码命中合并提交时,它应仅添加该合并的 first 父级。在我们的示例中,合并提交git rev-list有两个父级,其中--first-parent是第一个父级,因此对于KH--first-parent到{{1} }到git log,而忽略了我们从侧分支合并的提交。

  • K:这表示步行代码不应执行任何操作:请勿添加任何父母。这使得循环很快停止:我们仅在命令行上看到提交。

要显示的 旋钮要复杂得多,因为它们很多。在这里,我将忽略所有面向pathspec的参数,仅查看HG以及--no-walk / --author的数字。前两个告诉Git:仅在列出的作者或提交者时显示提交。(您可以列出多个--committer--max-count; Git将显示如果它与您指定的任何名称匹配,则提交。)

请注意,行走仍基于图形。只是您没有查看没有正确作者或提交者的提交。

与此同时,-n(又称--author)数字告诉Git,它应该在显示一定数量的提交后退出循环。例如,使用--committer,Git将照常遍历所有提交,显示由--max-count创作的所有提交,但是一旦显示了五个此类提交,请停止。当然,如果提交次数较少,它将尽早停止。

何时使用-n-n 5 --author automatic@local

automatic@local命令就是Git所说的瓷器:它应该干净整洁,对用户有吸引力。因此,用户可以对其进行自定义。您可以设置输出颜色,git log之类的选项以及其他对人类有用的项目。

git rev-list命令更加严格和无聊。这就是Git所说的 plumbing::该程序旨在产生不一定对人类有益的输出,但对其他计算机程序有用。不管谁运行它,它的行为都相同。是这样的,这样一个程序需要git log可以提供的某些信息,就可以以一致的方式获得它。 (如果您愿意,该程序可以继续以花式和面向人的方式进行。)log.decorate默认情况下产生的只是一系列提交哈希,它们是提交的哈希ID。同样的git rev-list命令也会显示。

无论出于何种原因,git rev-list默认将从git rev-list开始,而git log则不会。因此,要将git log命令(您正在测试以查看是否获得正确的提交)转换为HEAD命令(将在其他程序中使用),有时需要在参数中添加git rev-list

答案 1 :(得分:0)

  

从当前我在该自动用户提交的存储库中的位置获取最后一个日志条目(或n个日志条目)

为此考虑一下--author的{​​{1}}或--committer选项:

git log
     

将提交输出限制为具有与指定模式(正则表达式)匹配的作者/提交者标题行的提交。如果有多个--author=<pattern>, --committer=<pattern> ,则选择其作者与任何给定模式匹配的提交(类似于多个--author=<pattern>)。

因此,要显示--committer=<pattern>在您当前已签出的分支上的最后5次提交,您可以这样做

that-user