我们的日常构建是由自动化用户完成的,它将使用消息中的构建信息对仓库进行空提交。
我想知道是否可以:
可以只使用git命令,还是必须做一些外部处理?
答案 0 :(得分:1)
编辑:为方便起见,我在下面添加了一些(较长的)背景。
(要查找特定用户的提交,请使用--author=
。这适用于大多数修订修订操作,因为它是由git log
和git 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。它们实际上不是随机的,但是它们似乎是随机的,并且对人类没有用,因此我们使用诸如master
和develop
之类的名称。 Git会保留一张不断更新的表格,例如 master
的意思是8a0ba68f6...
,等等。
使用这些表条目,我们说master
指向一些提交。假设master
指向一些提交,我们将其哈希ID缩短为一个大写字母G
:
G <--master
(稍后您会看到为什么我将master
放在右边)。
向分支添加新提交只会更新名称到哈希ID的映射:创建一个新提交,Git为它分配一个唯一的哈希ID,如果您使用的是master
,则Git更新master
的表条目包含该新的哈希ID:
H <--master
这意味着某些分支名称指向的提交(分支名称中存储的箭头)随时间变化。这就是Git如何找到该分支的最新提交的方式。根据定义,为该分支名称保存的任何提交哈希,该 都是该分支的提示。
现在,每个提交也都拥有一定数量的 parent 哈希ID,通常是一个。 这的意思是,给定一个表** master
为a1234...
,并提交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
,它返回到I
和G
,依此类推,而名称{{1 }}指向F
,指向master
和H
,依此类推。
看看上面的内容,可以说提交G
在F
上,而H
在master
上。这很自然,因为这些名称直接指向那些提交。但是关于提交J
,它在哪个分支上呢?
某些系统会选择一个答案并坚持下去。 Git是不同的。 Git说develop
在每个可以到达G
的 分支上,所以它在 G
和 / em> G
。为了从master
到develop
,我们回跳了一跳。要从G
到master
,我们要返回两跳。无论哪种方式,我们都会降落在G
上。
develop
和G
只需遵循以下箭头考虑到某个起点,例如git log
或git rev-list
甚至是master
,develop
所做的只是太简单了一点:
此说明不是错误,但是缺少许多重要的细节。第一个并发症来自合并。让我们使用以下方式将图远的图像和 merge HEAD
回到git log
中:
develop
无需深入研究 master
的工作原理(这是它自己的问题和答案(但已经被问过很多次了)),我们最终得到以下图表:
$ git checkout master
$ git merge develop
提交git merge
是合并提交,这意味着它至少有两个父母。 ...--F--G--H---K <-- master (HEAD)
\ /
I--J <-- develop
的两个父对象分别是K
和K
(因为我们合并了提交H
,就像通过名称J
找到的一样)。 / p>
J
显示提交develop
之后,应该继续执行哪个提交?它可以选择任何一个。它真正的作用是将和都提交到队列中,然后选择一个并显示它,然后将其父对象放入队列(如果尚未这样做)。然后从队列中选择另一个,然后重复:
git log
使用K
。然后,在循环中:
因为有一个队列,所以管理谁在最前线上存在一些魔术。默认情况下,这是按日期/时间戳排序处理的,但是您可以使用各种排序选项进行更改。
这意味着默认情况下,git log
的Git将首先显示HEAD
,然后是 git log
或 K
,然后一个{em> H
或J
,然后另一个另一个 H
或I
,现在队列中只有H
,因此顺序很明确(I
,然后是G
)。请注意,如果不通过G
,Git就无法到达F
,因此I
肯定比J
早出现,但是Git可以两步到达J
方式,所以我们不确切知道I
的出处。
无论您做什么,H
和H
总是都必须遍历此优先级队列,选择要显示的下一个提交,将父提交添加到队列中,然后循环播放。但是您可以控制添加哪些父母和/或哪些提交实际显示。
父母控制旋钮是:
git log
:这表示当步行代码命中合并提交时,它应仅添加该合并的 first 父级。在我们的示例中,合并提交git rev-list
有两个父级,其中--first-parent
是第一个父级,因此对于K
,H
从--first-parent
到{{1} }到git log
,而忽略了我们从侧分支合并的提交。
K
:这表示步行代码不应执行任何操作:请勿添加任何父母。这使得循环很快停止:我们仅在命令行上看到提交。
要显示的 旋钮要复杂得多,因为它们很多。在这里,我将忽略所有面向pathspec的参数,仅查看H
和G
以及--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