以下是我的gitlab存储库（远程服务器）的主分支上的所有提交的列表。
commit #5 - user#1
commit #4 - user#3
commit #3 - user#2
commit #2 - user#1
commit #1 - user#1
我刚刚意识到提交＃5没有在提交＃4和提交＃3中进行更改。用户＃1没有强制提交。怎么会这样？
我很无能
P.S。它表示提交＃5，提交＃4和提交＃3的父提交＃2。 commit＃1是commit＃2的父级。这是什么意思？
答案 0 :(得分：3)
如果＃5的父级是＃2，＃4的父级是＃2，而＃3的父级是＃2，而＃2的父级是＃1，那么你有一系列的提交我们可以这样绘制，左侧是较旧的提交，右侧是较新的提交：
3
/
1--2--4
\
5
提交3,4和5是兄弟姐妹：他们都是提交＃2的孩子。但是＃4不是＃3的后代，所以期望＃4承受＃3累积的伤害是不合理的。 ： - ）
我们还会调用所有3,4和5 分支，从2分支出来。＃3的历史将是（1,2,3）; ＃4的历史将是（1,2,4）;而＃5的历史将是（1,2,5）。你没有向我们展示这三个分支的名称，但它们可能有名字。 修改：除非，即他们再次聚在一起。例如，假设有后续合并：
3----
/ \
1--2--4--M34--M5--... <-- master
\ /
5--------
现在关系相当混乱，你需要一个称职的图形查看器（例如git log --all --decorate --oneline --graph或gitk --all）才能看到它们。
如果您只是从服务器检索源图像：
我直接从gitlab服务器...
下载了commit＃5中的所有文件
然后您将永远无法在这些提交之间看到关系。要查看关系，您应该克隆存储库。这为您提供了一个新的存储库，至少在目前，它是您克隆的存储库的近乎精确的副本。然后，您可以使用各种Git命令来检查您的副本，该副本相当忠实于原件，也会告诉您有关原件的有用信息。
（克隆故意不是完全副本，所以除其他外，你可以告诉它是克隆，以便你可以处理它。你可以< / em>制作一个精确的副本，但这样做会为你提供一个你不应该工作的克隆，一般来说 - 你应该只使用它从原版中收集更新，这样它就可以保留一个精确的副本。）