Iv'e做了以下流程由于我们遇到了一个问题：Git - 主提交符合提交时间/日期吗？
我有2点本地仓库的克隆 - > rep_A，rep_B（二者均位于主）
（所有提交都做了时间上连续，1是第一个4是最后一个）
我希望师傅看起来这样的：
虽然主结果如下：
有人可以帮忙解释一下这种行为？
当git log有提交它可能显示“同时”，因此必须选择一个第一显现。那就是，这里的基本问题是：什么是实际的时间戳？和您的查看器如何线性化非线性历史记录？
作为一个略有不同（可能更明显）例如，假设你运行：
git log br1 br2
其中br1和br2是两个不同的分支名称有两个不同的提示提交。 Git应该首先显示哪个提交？一般来说，Git的答案（对于git log和git rev-list）是：使用最新的提交者日期。有标志可以更改：--author-date-order,--date-order和--topo-order（--graph暗示--topo-order为max630 noted in a comment）。
提交日期与作者日期分开。每个提交都有两个时间戳，一个用于提交最初写入的时间，另一个用于实际提交的时间戳。这两者通常是相同的，但您可以通过各种方式让它们分离，包括重新绑定（复制的提交在保留原始作者日期的情况下获取新的提交者日期），或者通过电子邮件发送修补程序git format-patch并将其应用于git am。
其他东西 - 除git log之外的其他观众 - 有自己的策略来处理这个问题，其中有承诺，当有选择时首先展示。 （还有一个潜在的问题是，当处理多台计算机时，每台计算机上的挂钟时钟可能会大错特错，幸运的是，只用一台计算机就可以解决这个问题。想必没有它的日期随机重置上周，然后明年再回到今天。即使你的计算机的时钟是错误的，它可能相当一致错误。）
现在，鉴于上述情况，让我们来看看你所做的提交以及由此产生的提交图。我们从三个相同的Git仓库开始：一些在中央服务器（可能是GitHub）上，另外两个克隆rep_A和rep_B。
我们会把更新的（通过提交日期）提交给右边，连同它们的链接（记住，每个提交“记得”它的父代）。
server: ...--F--G <-- master
rep_A: ...--F--G <-- master
rep_B: ...--F--G <-- master
现在加入您的四次提交，但在交替库：
rep_A: ...--F--G--1-----3 <-- master
rep_B: ...--F--G-----2-----4 <-- master
（请注意，服务器没有这些还）接下来，你没有从rep_A一个git push到服务器，所以现在服务器有F--G--1--3序列，然后在rep_B上运行git pull。
git pull命令意味着：运行git fetch，然后运行第二个Git命令。我们可能需要知道第二个命令是什么，因为它可能是git merge，或者它可能是git rebase ...和git rebase更改提交者日期。
这里是你有什么git fetch步骤之后：
server: F--G--1-----3 <-- master
rep_B: F--G-----2-----4 <-- master
\
`1-----3 <-- origin/master
现在，我们需要知道，如果你配置git pull运行git rebase（或等价地，跑了git pull --rebase）。如果您做，这里是你在rep_B得到什么：
rep_B: F--G--2--4 <-- origin/master
\
1'--3' <-- master
但是，这些将在正常显示（即反向）顺序3'（这是由原始3的副本底垫中），然后1'，然后4，然后2。所以可能是不是的情况。如果添加了合并，而不是，这是你在rep_B得到什么：
rep_B: F--G-----2-----4--M <-- master
\ /
`1-----3---’ <-- origin/master
在任何情况下，你再从rep_B推回服务器（也许取回并合并有或重订，即git pull，回到rep_A以及）。
如果您现在使用git log master或同等代码显示这些提交，Git将以合并提交M开头，因为它现在只有一个提交：即合并提交本身。但M有两个父母，所以接下来，Git将4和3放入提交显示列表中。
现在会发生什么情况取决于您告诉git log使用哪种顺序。默认情况下，它将选择要显示的日期最高的提交。这将是承诺4;它会显示，并将其父母，提交2，列入清单。然后它会在列表中选择具有最高日期的提交，这将是提交3。它会表明，并把3的父母1列入清单。然后它会选择最高日期的提交，这将是2，依此类推。
另一方面，如果你给它--topo-order标志，它会选择合并的两个父母之一，选择4。然后，它会确保它显示所有的4回到岔路口的地步，父母中至少G显示提交3之前，所以你会看到4，然后2，然后3，然后1，然后G，然后F ， 等等。
根据您观察到的输出，看起来您使用的任何观看者都在做最后一个序列。但是我在这里做了很多假设（比如合并vs rebase）。
我做的例子是将存储库克隆到本地计算机上的2个不同文件夹中。不是2个本地克隆上的分支机构。 – lddmonster
嗯......好的，你应该提到这一点。但为什么会有所作为呢？如果一个回购在远程“主”背后，您仍然需要在推之前拉回。 –
没有分支，两个folders.repositories在主分支.. – lddmonster