git log --oneline --graph 输出的含义

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/50430722/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-19 13:07:26  来源:igfitidea点击:

Meaning of git log --oneline --graph output

gitgit-log

提问by NattyC

I'm learning about relative commit references and trying to understand the following git log --oneline --graphoutput provided in a lesson.

我正在学习相对提交引用并试图理解git log --oneline --graph课程中提供的以下输出。

git graph

git 图

In the lesson it says that given HEAD points to the 9ec05cacommit, HEAD^^^ (meaning the great-grandparent commit) is the 0c5975acommit. But it seems to me 4c9749eshould be the great grandparent, if each SHA is a direct descendant of the one below it. Any clarification appreciated.

在课程中它说给定 HEAD 指向9ec05ca提交, HEAD^^^ (意味着曾祖父母提交)是0c5975a提交。但在我看来4c9749e应该是曾祖父母,如果每个 SHA 都是它下面一个的直系后代。任何澄清表示赞赏。

采纳答案by code707

Commit can have more than one parent. ^ 1 means first parent. ^2 means second parent and do on. Just ^ defaults to ^1 which is first parent.

Commit 可以有多个父级。^ 1 表示第一个父母。^2 表示第二个父母并继续。只是 ^ 默认为 ^1,它是第一个父级。

Similarly ~ give access to traverse up for an ancestor. For example if you want 3 generation up ~3. If you want 7th last commit in same branch favouring first parent while traversing.

类似地 ~ 允许访问遍历一个祖先。例如,如果你想要 3 代 ~3。如果您希望在遍历时在同一个分支中进行第 7 个最后一次提交,有利于第一个父级。

Any merge will have two parents with merge to branch becoming first parent. Merge from branch becoming second parent.

任何合并都会有两个父级,合并到分支成为第一个父级。从分支合并成为第二个父级。

回答by Obsidian

setia_'s answer remains the most appropriate but your question is meaningful because a git history can be considered from two distinct perspectives: either you totally view it as a (mathematical) graph in which parent's order is supposed to be non significant, OR you consider a merge operation as the integration of an external branch into a common trunk (i.e. your current branch, very often "master"). This is also the assumption made by git merge.

setia_ 的答案仍然是最合适的,但您的问题很有意义,因为可以从两个不同的角度考虑 git 历史:要么您将其完全视为一个(数学)图,其中父级的顺序应该不重要,要么您考虑合并作为将外部分支集成到公共主干中的操作(即您当前的分支,通常是“主”)。这也是由 做出的假设git merge

This is important not only because browsing an exponentially growing tree rapidly becomes a pain, but also because having a branch "master" that contains a finished product and integrating external submissions is a model followed by many workflows.

这很重要,不仅因为浏览呈指数增长的树迅速变得痛苦,而且因为拥有一个包含成品和集成外部提交的分支“主”是许多工作流程遵循的模型。

Since both these points of view are valid, they cause --first-parentto be a frequently used option, though not a main command nor a default behavior.

由于这两种观点都是有效的,因此它们--first-parent是一个经常使用的选项,尽管不是主要命令也不是默认行为。

For example, browsing the Linux kernel main repository (for which Git was first designed) with a simple git log --graphcan take up to one minute before displaying something, but git log --graph --first-parentwill show you the main branch and let you observe that it's mainly composed of merges, with occasional direct commits.

例如,使用 simple 浏览 Linux 内核主存储库(Git 最初为其设计的)git log --graph可能需要长达一分钟才能显示某些内容,但git log --graph --first-parent会向您显示主分支并让您观察它主要由合并组成,偶尔会出现直接提交。

Another thing one have to keep it mind is that you can ask to have your commits displayed by chronological order using --date-orderor topological order with --topo-order. Let's assume you have two distinct branches and alternatively commit to the one or the other before eventually merging them. Depending on the order, the resulting graph would look like one of these :

另一件必须记住的事情是,您可以要求按时间顺序使用--date-order或拓扑顺序显示您的提交--topo-order。让我们假设您有两个不同的分支,并在最终合并它们之前交替提交一个或另一个。根据顺序,生成的图形将如下所示之一:

Chronological order                     Topological order

*   ec9a124 Merge branch 'B' into A     *   ec9a124 Merge branch 'B' into A
|\                                      |\
* | e5314f2 Ninth                       | * e3e2435 Eighth
| * e3e2435 Eighth                      | * af3bac5 Sixth
* | 308228b Seventh                     | * 3a2f0b9 Fourth
| * af3bac5 Sixth                       | * d901c9f Second
* | ab11578 Fifth                       * | e5314f2 Ninth
| * 3a2f0b9 Fourth                      * | 308228b Seventh
* | 344bd0f Third                       * | ab11578 Fifth
| * d901c9f Second                      * | 344bd0f Third
|/                                      |/
* 0f029bc First                         * 0f029bc First

All commits remain on their respective line but the latter is a depth-first search. And since git log(so does git rev-list) displays a collection of pre-gathered revisions, this order will be the same whether you're using --graphor displaying them as a flat list (actually, if not specified, git loguse reverse chronological order by default, and topological one when using --graph).

所有提交都保留在各自的行上,但后者是深度优先搜索。并且由于git log(也是如此git rev-list)显示一组预先收集的修订,因此无论您是使用--graph还是将它们显示为平面列表(实际上,如果未指定,git log默认情况下使用反向时间顺序和拓扑顺序),此顺序都将相同使用时--graph)。

Because of that, you can't simply rely on the first row to decide which parent to choose.

因此,您不能简单地依靠第一行来决定选择哪个父级。

This can also cause some older commits to appear before the new ones, which can be very confusing when beginning with Git, and give you the impression that your work has disappeared (until it comes to one's mind to perform a search, then retrieve it buried somewhere in history).

这也可能导致一些较旧的提交出现在新的提交之前,这在开始使用 Git 时可能会非常混乱,并且给您的印象是您的工作已经消失了(直到有人想到执行搜索,然后将其检索到掩埋历史上的某个地方)。