基于Git中两个历史尾部的混合合并

我有两个具有不同历史记录的Git存储库。经过大量的研究和修补，我最终得到了一个类似这样的历史记录（使用

YYYY-DD

作为伪提交散列）：

注意，这段历史似乎有两个“根”，因为

2015-10

序列被合并/嫁接到中间。重要的是

2016-07

历史记录和

2015-10

历史记录中的文件包含完全不同的文件，没有任何共同之处

我想将此历史记录合并成一个完整的提交行，按照从最早到最新的原始提交顺序，不跳过任何内容（即删除稍后再次出现的内容）。换句话说，我想以以下内容结束：

HEAD---2016-09---(2016-08)---2016-07---2016-06---2015-10---2015-09

我把

（2016-08）

放在括号中，因为作为合并提交，如果一切正常，我甚至认为我不需要它

起初我想做一个

git-replace--edit 2016-08

来删除它的

2015-10

父项，然后做一个

git-replace--edit 2016-06

来将

2015-10

作为它的父项（参见），果然，在做了一个

git过滤器分支--tagname filter cat--all

之后，我得到了一个看起来像我想要的序列

但后来我开始思考：因为这两个“尾巴”的内容完全不同，所以

2015-10

中的内容不会在

2016-06

中“消失”，然后在

2016-08

中“回来”吗？（我承认，我现在无法立即验证它是否正确；我删除了那次尝试，今晚我太累了，不能再做了。）我如何有效地“合并”（日常意义上）这两条尾巴，就好像

2016-06

中的内容被添加到

2015-10

中一样？也就是说，任何替换

2016-06

的提交都将包含

2015-10

中的所有内容以及原始

2016-06

中的内容？但是，我希望新的

2016-06

具有其原始提交日期、日志消息等

然后，在完成之后，如何从历史记录中删除“合并”提交

2016-08

，因为它不再需要了？我假设我可以使用git rebase--2016-08~2016-08 HEADfrom。我在最初的尝试中尝试过，但没有成功——我想这与

2016-07

和

2016-06

中“消失”的内容有关，因为我只是以不同的顺序重新缝合了尾部，但我不确定

---

如果这是一个重复的问题，我很抱歉，但是经过数小时的研究和深入历史（并小心翼翼地在vi中翻来翻去），我今天有点“Git疲劳”。提前谢谢。

关于一个简化的示例，我能够

git checkout -b middle 2016-07
git rebase 2015-10

这将在2015-10的基础上重播您的2016-07和2016-06承诺

git checkout master

假设您的主控点指向2016-09或其后代

git rebase middle

wich在我们刚刚创建的新中间层上重放2016-09（或更多，取决于您的主人）。此重基还将放弃合并提交

---

如果，正如你所说，

2016-07历史记录和2015-10历史记录中的文件包含完全不同的文件，没有任何共同之处

这应该会给你一个没有冲突的美好历史。

哇，谢谢你——我不知道这里发生了什么神奇的事情，但它似乎起了作用！一切都井然有序，甚至合并提交也不见了。唯一奇怪的是，在Bitbucket中，

2015-10

commit的所有提交都在时间线上显示了正确的日期，而

2016-06

forward的所有提交都在Bitbucket中显示了“X分钟前”的日期。然而，原始提交似乎有正确的日期，并且它们在Git和Ortoisegit中正确显示。知道为什么吗？在任何情况下，我都会增加一笔赏金，只是为了奖励你或任何最终得到答案的人。我对bitbucket不太了解，但这可能与bitbucket跟踪（并向你展示）有关，当提交被实际推到它时。2015-10年后的提交被重定基础，这改变了它们的父提交，因此提交id——对于bitbucket，这些可以被视为“新的”。2015-10-2015-09没有更改，仍然是相同的提交id。因此，这可以解释显示中的不可分离性。这是有道理的@lucanLepus，这太棒了——我只是在等待堆栈溢出让我悬赏，这样我就可以奖励你的答案。同时，我必须做的最后一件事是重新排序一些提交（这些提交是在事件发生后手动输入的，带有正确的过期时间戳）。我想我会做一个手动的、交互的重基——只有几个提交不符合顺序。如果您对此有任何提示，请告诉我。使用交互式重新基址进行重新排序非常简单，命令行版本允许您只需移动行，大多数GUI都会进行拖放。重新约会我从未做过的承诺，但例如，应该让你度过难关

git rebase middle