我有点困惑…
我有两个分支，它们都有相同的提交序列。
真实的历史是它们是由我的同事撰写的，提交并推送到分支A上的github。在某个阶段，我将分支A与我的B分支合并。
git现在显示的是他在分支A中的提交，以及它们的哈希值，同样的提交在我的分支(发散的)中，显示我是作者，以及一组不同的哈希值，混杂着我在分支上所做的工作。
这感觉像是某种重基问题，(我们都使用GitHubForWindows的一些时间做重基作为同步的一部分)，但我不知道一个问题被报告给我们中的任何一个。
任何关于什么导致了这个，或者如何得到它的想法将是感激的。
你应该得到一些强大的工具(普通的gitk应该做得很好)，并仔细检查匹配(但在哈希值上不同)提交-寻找Author, Committer和Date字段的差异。还要比较父提交的哈希值，因为提交对象也记录了它们的父提交的哈希值，因此引用不同父SHA-1提交名称的相同提交将不同。
你能详细说明一下你的提交是如何精确地"混合"的吗?用你同辈的书吗?所有这些提交是形成一个线性历史还是有合并点?
前者表明使用了重基。
根据目前可用的信息，我将这样做:
-
停止使用"Github for windows";因为无需动脑筋的解决方案往往会造成你现在面临的情况:当东西坏了，你不知道它为什么坏了，也不知道如何恢复。
-
得到"regular"Git for Windows(如果你想要漂亮的GUI，也可以是Git Extensions)
-
通过分支另一个分支来保存当前的功能分支。
-
(硬-)重置你的特征分支为你的对等体。
-
从保存的分支中挑选最旧的更改到最新的更改。
这可能会产生冲突(因为这些提交将被植入到它们最初创建的代码的不同状态中)。
结果你将得到一个没有"虚假相同"的分支。提交。
然后你和你的同事都应该仔细阅读合并和重基工作流，采用其中的一个，然后，当在特性分支上工作时，明智地合并和/或重基，理解你为什么要这样做以及结果会发生什么。我建议您不要盲目地依赖一个工具来做正确的事情。
我遇到了这个"git diff diff"的问题后，两个分支是串联。相同的提交应用到相同的分支点，所以看到分支分叉时我很困惑。甚至patch-id也是一样的
查看原始差异，发现"提交者时间"是不同的:
$ diff <(git show --format=raw $COMMIT1)
<(git show --format=raw $COMMIT2)
1c1
< commit $COMMIT1
---
> commit $COMMIT2
5c5
< committer $ME <me@work.com> 1470128045 +0200
---
> committer $ME <me@work.com> 1470129095 +0200
在git rebase上使用--committer-date-is-author-date重做rebase修复了一些分歧，但不是全部。我不知道为什么……我认为分歧发生在第一次反向合并时)
然后我使用filter-branch作为大锤:
git filter-branch --env-filter
'export GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE'
origin/master..HEAD
这足以使这个系列保持在一行:
$ git show --format=raw HEAD | egrep 'author|committer'
author $ME <me@work.com> 1470065063 +0200
committer $ME <me@work.com> 1470065063 +0200
如果git rebase是您的工作流程的一部分，那么您所描述的是常见的。例如:
$ git log --graph --oneline --all
* 76af430 fc # branch: foo
| * 7c495ad mb # branch: bar, master
|/
* 74cbb35 a
$ git rebase foo # while on branch master
First, rewinding head to replay your work on top of it...
Applying: mb
$ git log --graph --oneline --all
* 6810e67 mb # branch: master
* 76af430 fc # branch: foo
| * 7c495ad mb # branch: bar
|/
* 74cbb35 a
我有来自不同哈希id的远程和本地分支的相同提交。似乎git pull --rebase解决了我的问题。