需要帮助解释git log --graph命令

Question

所以，我对git log --graph的工作方式感到有些困惑。

这是我在GitHub上的存储库：https://github.com/Snedden/capstone

我没有在master分支之外创建任何分支。

但是，当我运行命令git log --graph（在我的本地存储库中）时，看来我在提交“标准化网址以获得更好的可移植性”时有一个分支

所以我的问题是，如果那不是一个单独的分支，那为什么它看起来像git log输出中的一个单独的分支？

注意：有些信息，当我尝试推送c228400 git时说我必须先拉，因为它认为我的遥控器超出了我的本地，我不知道这是怎么可能的，因为我总是线性推出一些相同的帐户

Answer 1

答案在你的图表中（这是一张图片，所以我在这里或多或少地转录过它）：

*  44ccab (HEAD -> testBranch, origin/master, origin/HEAD, master)
|    Merge branch 'master' of https://github.com/Snedden/capstone
|\
| * c228400 standardised urls for better portability
* | 90bbf9e added stage axis and d3 library
* | 2d0ce65 standardised urls for better portability
|/
* 4c?02a4 datasets implemented

事实上，你确实合并了两个分支。

您合并的两个分支是master和master。

这两个master中的一个是你的主人。另一个是'master' of <another repository>。

这是git pull所做的合并。请注意，git pull表示“运行git fetch，然后运行git merge，除非我提前告诉您运行git rebase而不是合并。”

git pull为合并设置的消息是Merge branch 'name' of URL。 name 部分来自您告诉Git使用的分支。该分支的内容是Git从给定的 URL 中检索到的内容，然后将这些内容带入您的存储库（在其他名称之下，因为显然{{ 1}}已经在使用！）。

也就是说，你合并了别人的master。现在，“别人”可能你，但Git不知道或不关心，它只知道URL。

如果您运行master而不是git fetch，则可以选择在完成提取后运行git pull或git merge 而不是以前决定，看不见。此外，如果您随后选择合并，则将按您在您的存储库中使用的名称进行合并，即git rebase，而不是奇怪的名字origin/master :-)其他人正在github.com上的那个其他存储库中使用。这可能会在以后（或可能不是）更有意义。

鉴于master和2d0ce65的提交消息是相同的，我怀疑您在推送c228400之后重新生成或修改了提交。这使得提交的副本（一个不完美的副本，故意，改变了一些东西）。然后，您添加了“stage axis and d3 library”提交，然后当您运行c228400时，您的Git尽职尽责地将您的两个提交git pull加2d0ce65合并到另一个人的提交中，90bbf9e，在github上找到。

这是你的两个分支：你的分支c228400，另一个你在GitHub上master结束。

Answer 2

你可以从我看到的两个分支：testBranch和master，所以这可能发生的事实对我来说似乎是正确的。

为了解释这个图像，我们必须提醒自己Git是一个DAG指导的非循环图，因为它总是以特定的顺序绘制节点。在这种情况下，提交的提交顺序基于祖先; testBranch很可能从主人那里分出来做一些额外的工作。

我相信两个提交--2d0ce65和90bbf9e - 是提交给master的工作。第三次提交 - d228400 - 是在testBranch上完成的。这两个分支在4c002a4中有一个共同的祖先，但后来发生了分歧，这就是为什么有两条不同的路径。

现在，至于为什么提交消息看起来相同，这可能意味着以下任何一个：

• 你rebased your work对抗主人
• 您将cherry-picked提交给master或master提交到testBranch
• 您只需复制相同的说明，并且提交完全不同

您可以通过运行git diff <SHA1> <SHA2>来检查这两个提交，看看是否有任何与它们完全不同的内容。