Question

当你在一个分支（在本例中为master）上有一个重复提交列表（与dev分支完全相同）但具有不同的日期时，这意味着什么同一天？

SourceTree图看起来像这样（过度简化）：

| [master] e 
| d
| c
| b
| a
|| [dev] c
|| [origin/dev] b
|| a
|/ [origin/master] x
|

提交a，b和c是相同的（相同的消息，但是不同的散列，因为它们实际上是一个不同的提交，对吧？）。在d分支之上有一些新的提交（e，master）。从a中的e到master，它们的日期相同。

我不完全确定，但我相信那是在那个时候（那个日期）做了一次糟糕的变形的结果。

当我尝试将dev合并到master时，我在许多文件中遇到大量冲突。我真的不是为什么，但我不应该得到任何，我想要做的只是整理回购，删除一些分支（我实际上删除了一个可能有一些提交的分支，现在他们只活了在这个糟糕的基础上，d和e，但我不确定）并且master和开发branch在本地和原点相互匹配。< / p>

如何解决这种情况？到底发生了什么？

我一直在尝试使用SourceTree修复此问题，但也尝试使用命令行，但无论我尝试什么，我总是会回到上述相同的情况。

Answer 1

提交a，b和c是相同的（相同的消息，但是不同的哈希，因为它们实际上是一个不同的提交，对吧？）。

是：哈希ID是提交的“真实名称”。（我假设通过在这些提交上运行git show获得的补丁也与它们的重复项相同，即，它不是只是相同的消息，还有提交转换成的delta。）

当我尝试将dev合并到master时，我在许多文件中遇到大量冲突。我真的不知道为什么......

git merge做的是（尝试）合并来自合并基础的两组更改。合并基础大致是“分支汇集在一起”，在您的简化图中，这将是在下面的提交

：

|/ [origin/master] x
|

因为这一点是线条聚集在一起的地方。

Git通过使用各种选项运行git diff来找到更改（好吧，它执行内部差异，因此没有实际文字git diff -M50% ...，但如果您手动执行此操作，则会获得相同的效果）：

将合并基础提交与dev
将合并基础提交与master

无论这两个差异表明，Git试图将它们结合起来 - 或多或少地接受它们的结合，尽管这个术语容易出错，因为“联合合并”完全是另一回事 - 并将其应用于基础以获得最终结果合并结果。

如果两个分支提示对基础中的相同文件进行了一些更改，则会出现冲突，但这两个提示会进行无法轻松组合的更改。 Git只是抛出了它的隐喻之手，并说：“我无法理解这一点。你解决它。”

我不完全确定，但我相信那是在那个时候（那个日期）做了一次糟糕的变形的结果。

嗯，它肯定可能是一个变种的结果。是否坏 rebase是一种意见问题:-)但是git rebase究竟是什么呢？ copy 提交。通常，复制后，我们都会忘记原件。这样我们就看不到原件和副本了，似乎Git已经神奇地替换了现有的提交，但它没有，因为那是不可能的。

每当某个其他分支挂起到原始提交时，我们see behind the curtain。这里有原件，而且有副本，只有一些分支名称指向新副本。

如果您可以让所有人切换到新副本，并忘记原件，那就很好。或者，您可以放弃使用副本，并让所有人使用原件;你很好，除了修理rebase应该处理的任何需要。但是，一旦多个用户拥有多个提交的多个副本，就可能无法返回：您可能必须通过添加合并并让每个人都获取新的合并来解决此问题。（说服每个人选择刚刚添加到现有提交图表的新工作要容易得多，因为这是git fetch + git merge 做的原因。）

修复双重提交历史记录

1 个答案: