git 1.7.1提交出现故障

以下帖子适用于2010年过时的Git版本（1.7.1版——Centos 6上的默认版本）。虽然显而易见的答案是简单地升级git（我支持这种做法），但我刚刚加入了这个项目，团队负责人关心的是稳定性。我怀疑Git1.7.1被严重破坏了，希望有理由升级

我刚刚对一个我刚刚加入的项目做了第一次承诺，并惊讶地发现git日志在我（SA）最近的承诺之前插入了我的更改——更复杂的是，TortoiseGit将其他人（MH）所做的更改归于我

结果:

* SA committed 3d67c9dd4 on Mon Feb 18 12:42:24 2019 +0000      ## SECOND COMMIT
*   SA committed d6f0c4712 on Mon Feb 18 10:55:42 2019 +0000    ## FIRST PUSH (2 mins after FIRST COMMIT)
|\
| * MH committed c1ad3c336 on Thu Feb 14 17:07:01 2019 +0000
| * MH committed 7442f95dd on Thu Feb 14 15:03:46 2019 +0000
| * MH committed 417dc55e2 on Thu Feb 14 11:28:40 2019 +0000
| * MH committed 0eea851b1 on Thu Feb 14 11:27:01 2019 +0000
| * MH committed 72e0fa612 on Wed Feb 13 17:15:22 2019 +0000
| * MH committed 0e80cc9d6 on Wed Feb 13 17:06:50 2019 +0000
| * MH committed ac37fdf64 on Wed Feb 13 17:04:46 2019 +0000
| * MH committed cb1b84489 on Wed Feb 13 17:04:18 2019 +0000
| * MH committed f5026eee5 on Wed Feb 13 15:03:50 2019 +0000
| * MH committed 1ca37588f on Wed Feb 13 15:01:55 2019 +0000
| * MH committed cedcefd36 on Wed Feb 13 12:23:03 2019 +0000
| * MH committed 0bbd26524 on Wed Feb 13 08:39:33 2019 +0000
| *   MH committed db8b7672c on Thu Feb 7 17:41:56 2019 +0000
| |\
| | * MH committed fca13dfe3 on Thu Feb 7 17:36:05 2019 +0000
| | * MH committed 704e2f3ff on Thu Feb 7 17:35:30 2019 +0000
| * | MH committed 1b34e745c on Thu Feb 7 17:41:20 2019 +0000  #### out of place
| |/
| * MH committed f77456930 on Wed Feb 6 11:43:29 2019 +0000
| * MH committed eb9849449 on Tue Feb 5 17:52:17 2019 +0000
| * MH committed 889f94b00 on Tue Feb 5 15:45:19 2019 +0000
| * MH committed ae4505a10 on Tue Feb 5 13:47:42 2019 +0000
| * MH committed 561c703b6 on Tue Feb 5 13:47:07 2019 +0000
| * MH committed 43b4941f8 on Tue Feb 5 13:45:01 2019 +0000
* | SA committed 2336ac0c7 on Mon Feb 18 10:53:49 2019 +0000  ## FIRST COMMIT -- sandwiched BETWEEN earlier commits!!!
|/
* MH committed 87fcf83a2 on Mon Feb 4 11:25:38 2019 +0000
* MH committed ea096edd3 on Fri Feb 1 17:12:01 2019 +0000
* MH committed c51cd83d3 on Fri Feb 1 10:27:52 2019 +0000

这是Git1.7.1的已知问题吗

更新：我刚刚注意到MH所做的提交也不合适，树中看起来像分支的东西完全是个谜。所有更改都是在同一分支上进行的

更新2似乎归因于我的令人困惑的提交（由TortoiseGit在d6f0c4712上发布）实际上是“与父1的差异”（不管这意味着什么）。我的实际提交列在下面的“与父项2的差异”中；DR

git log --date-order

或

详细信息

我能够用Git 1.7.1在CentOS 6机器上重现您的场景。（我们也有一个较新的Git，但1.7.1版本仍然存在。）

当有一个合并提交时，Git（new and new）似乎把合并在一起的分支视为“最近”，这是有意义的，如果你这样想：我在分支上做了一个改变，然后我合并到别人的改变中，所以这是最后一个发生的事情。 简单的解决方案是将

--日期顺序

提供给

git日志

订购日期：

$ git log --date-order --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"
*   j committed c767018 on Tue Feb 19 06:40:26 2019 -0500
|\
* | j committed f0fe88c on Tue Feb 19 06:40:10 2019 -0500
| * j committed 29b783b on Tue Feb 19 06:39:55 2019 -0500
|/
*   j committed c592f81 on Tue Feb 19 06:34:38 2019 -0500

$ git log --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"
*   j committed c767018 on Tue Feb 19 06:40:26 2019 -0500
|\
| * j committed 29b783b on Tue Feb 19 06:39:55 2019 -0500
* | j committed f0fe88c on Tue Feb 19 06:40:10 2019 -0500
|/
*   j committed c592f81 on Tue Feb 19 06:34:38 2019 -0500

非日期订单：

$ git log --date-order --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"
*   j committed c767018 on Tue Feb 19 06:40:26 2019 -0500
|\
* | j committed f0fe88c on Tue Feb 19 06:40:10 2019 -0500
| * j committed 29b783b on Tue Feb 19 06:39:55 2019 -0500
|/
*   j committed c592f81 on Tue Feb 19 06:34:38 2019 -0500

$ git log --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"
*   j committed c767018 on Tue Feb 19 06:40:26 2019 -0500
|\
| * j committed 29b783b on Tue Feb 19 06:39:55 2019 -0500
* | j committed f0fe88c on Tue Feb 19 06:40:10 2019 -0500
|/
*   j committed c592f81 on Tue Feb 19 06:34:38 2019 -0500

关于所有合并气泡的说明

在我的工作流程中，我不喜欢看到历史上所有的合并气泡。当我合并一个功能分支或bug分支时，我希望将其视为一个合并，但当它只是

master

上的更改而我还没有推送时，我会尝试避免它。你在“更新”下的便条表明你也不喜欢它，所以下面是我对它的看法

当您执行

git pull

时，有一些本地提交尚未被推送，默认情况下，git（旧的和新的）会将远程更改合并到您的本地分支中，创建一个冒泡，就像我在上面重新创建的一样，就像您的历史显示的那样

要避免这些问题，请改用git pull--rebase

我的首选工作流程：使用

git fetch

，然后将

--all

添加到

git log

命令中，检查本地分支机构与

origin

之间的差异，然后在您满意的情况下检查

git rebase origin

git fetch
git log --all --date-order --graph --oneline --decorate ...

或

然后

---

关于重定基址的通常警告适用于：避免重定你以前推动过的任何东西的基址。对于仅存在于沙箱中的本地提交，这是一个好主意。

在我看来，这就像是在第一次提交和第一次推送之间发生的某个合并或重定基础事件。如何使用拉/推/提交？您是否使用自动git，例如Visual studio！？不。Linux上的命令行。在Windows tho上查看回购协议。注意，您在此处看到的分支可能只是从上游分支合并到本地分支。另外，请检查用户SA的系统时间。他的系统时间不同步吗？我猜——但这不是git最新版本的行为，也不能解释在同一个人（MH）所做的更改中出现的明显分支。更新：MH和我（SA）远程使用同一个开发箱，这台机器没有时间问题。这回答了几个问题。重新定基令我害怕。另一个让人困惑的地方是，乌龟将MH的变化列为我的变化，事实上是“与父母1的差异”。我的更改在下面的“与父项2的差异”中列出。（我非常确定git 1.7.1被破坏了，也许默认行为是。）如果您想要更干净的历史记录，那么学习重新设置未推送提交的基础是非常值得的。Git也可以在需要时让您回溯，所以它并没有太大风险。

git log master origin/master --date-order --graph  --online --decorate ...

git rebase origin