我正计划在我们的团队中进行新的部署过程。
对于每个构建X,我们在现有构建X上有$ last_commit_from_last_build X-1和$ last_commit。
我们不会并行运行构建,这意味着在构建X中可能会有多个提交,因此我们需要列出这些提交,以便我们不会错过它们。例如,这可能是从最旧到最新的提交顺序:
(last_commit_from_last_build)(Build X-1),(some_commit_1,some_commit_2,last_commit)(Build X)
在Build X中,我们需要构建$ last_commit_from_last_build和$ last_commit之间的所有提交。我们只想要$ last_commit_from_last_build和$ last_commit之间的提交。
所以,我们决定使用:git log $last_commit_from_last_build...$last_commit
。
如果我们在GitHub上有以下历史记录,它会显示奇怪的结果:
当我们运行git log 3ec29f0...573e22e
我们收到以下结果:
提交bdd和e57是在这些提交之间。
637不是!
在我们的逻辑中可能出现什么问题,是否有更好的方法来获取这些请求列表?这会产生错误的构建,并阻止我们继续我们的项目。
首先,前往Think Like (a) Git。阅读整篇文章,或至少通过标题为“试验Git”的页面,阅读并完成这一过程,直到您理解了可达性的概念以及Git如何使用引用。
现在您已经了解了解Git命令行提供的两个和三个点语法所需要知道的所有内容:
A...B
是从name-or-hash-ID A
或name-or-hash-ID B
可以访问的提交集,但不是两个名称都可以。与此同时:
A..B
是从B
可以访问的提交集,不包括从A
可以访问的提交集。这可能是,但不一定,你想要的。
当提交A
是提交B
的祖先时,您可能需要一个与其中任何一个不同的集合。特别是,您可能想要从A
开始的所有提交集合,这些提交是A
的后代和B
的祖先。这没有通用的语法,但可以通过git rev-list
(因此通过git log
)获得:
git rev-list --ancestry-path A..B
请注意,这省略了A
,但包括B
,就像没有A..B
的--ancestry-path
变体一样。 (您可以在这里添加--boundary
以包含A
,但在更一般的情况下,请注意来自--boundary
的一些奇怪的副作用。)
如果一个简单的--ancestry-path
不是你想要的,那么A..B
的变种就是你想要的。它们之间的两种变化通常在有向的非循环图中捕捉到“介于”之间的某种滑溜的概念。
和OP一样,我也注意到GitHub选择显示提交的顺序不是“可靠”,或者至少与底层图形关系没有直接关系,因为看起来选择顺序取决于时间戳的时间戳。提交(使用git rebase -i …
等命令时实际可以更改)。
所以在@ torek的答案中解释的基于CLI的方法绝对是可行的方法。
否则,您还可以使用gitk --all
等图形命令来显示提交图,并更好地了解给定存储库中提交,分支和标记之间的关系。
有关更多详细信息,请参阅本教程Use gitk to understand git,其中包含gitk
的评论截图。