我正在为我们的团队计划一个新的部署过程。
对于每个版本X,我们都有 $ last_commit_from_last_build X-1 和现有版本X上的 $ last_commit 。
我们不会并行运行构建,这意味着在构建X中可能会有一个以上的提交,因此我们需要列出这些提交,以免丢失它们。 例如,这可能是从最早到最新的提交顺序:
( last_commit_from_last_build )(内部X-1),( some_commit_1 , some_commit_2 , last_commit )(内部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 不是!
在我们的逻辑中可能会出什么问题,并且有更好的方法来获取这些请求的列表吗?这会产生错误的构建,并阻止我们继续进行项目。
答案 0 :(得分:2)
首先,进入Think Like (a) Git。阅读整个内容,或者至少阅读标题为“使用Git进行实验”的页面,并仔细阅读直到理解 reachability 的概念以及Git如何使用引用为止。 / p>
现在,您已经了解了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
的{{1}}变体一样。 (您可以在此处添加--ancestry-path
来包含--boundary
,但在一般情况下请注意A
的一些奇怪的副作用。)
如果您不想要简单的--boundary
,则需要--ancestry-path
的变体。它们之间的两个变体通常捕获有向无环图中的“介于”之间的概念。
答案 1 :(得分:0)
像OP一样,我还注意到GitHub选择显示提交的顺序不是“可靠的”,或者至少与底层图形关系不直接相关,因为似乎选择的顺序取决于提交的时间戳(使用git rebase -i …
之类的命令时实际上可以更改)。
因此@torek答案中解释的基于CLI的方法绝对是可行的方法。
否则,您还可以使用诸如gitk --all
之类的图形命令来显示提交图,并更好地了解给定存储库中的提交,分支和标签之间的关系。
有关更多详细信息,请参见本教程Use gitk to understand git的示例,其中包含gitk
的评论屏幕截图。