每个人都通过“合并 git 存储库”来理解不同的东西，所以这是我的情况。我们有一个 TFS 存储库，并且我们在某个时间点检查了源代码并进行了初始 git 提交。然后我们在 git 中进行了正常的开发（分支、合并等）。问题是在新存储库中，我们在 git 存储库中没有历史记录，我们想修复它。因此，我已将整个 TFS 存储库转换为 git 存储库，现在我需要将转换后的 TFS 存储库与当前的 git 存储库合并。
从上面的描述可以明显看出，存储库从 git 的角度来看是独立的，但从逻辑的角度来看，它们有一个共同的提交（成为当前 git 存储库的初始提交的提交）。
如何在不丢失其中任何一个历史记录的情况下合并这些存储库？我可以将转换后的 TFS 存储库作为基础，然后从当前存储库的 master 中挑选更改，但这不会导入在当前存储库中创建的所有分支。
【问题讨论】：
编辑：我之前的回答并没有带来任何好处。 git rebase 并不是为了这样做。 然而，类似的事情已经在 stackoverflow 上发生了：Merging two git repositories to obtain linear history
你可以试试这个过程：
git init combined
cd combined
git remote add old url:/to/old
git remote add new url:/to/new
git remote update
您将拥有一个新的存储库，其中包含两个存储库的引用。那么
git reset --hard old/master
这将使 master 分支指向旧 repo 的 master 分支。 您现在可以从新 repo 的主分支中挑选所有提交
git cherry-pick <sha-1 of first commit on new repo>..new/master
我们刚刚开始：master 分支还可以，但是新仓库中的其他分支呢？ 好吧，你不再需要你的旧仓库了，所以
git remote rm old
然后，假设您的新存储库中有一个名为“branch1”的分支。
git checkout branch1
git rebase master
这应该会更改 branch1 的历史记录，使其从 master（合并的 master，包含来自您导入的 repo 的历史记录）开始，并且 rebase 应该不会发生冲突。 检查history是否与gitk一致，然后可以强制push with
git push -f new master
git push -f new branch1
在强制推送之前，您必须确保历史记录正常，因为这会更改上游历史记录（保留新旧存储库的备份以在需要时恢复）
【讨论】：
我就是这样做的，不确定这是不是正确的做法，但至少对我有用：
git clone url:/to/new
cd repo
git remote add old url:/to/old
git remote update
git rebase --committer-date-is-author-date old/master
就是这样。现在，如果还有其他分支，也许您还需要在 master 上重新设置它们的基础，这可能不是那么简单。
新 repo 的 git 历史变平了，但对我来说，在查看 git log -p --graph 时没问题
主要问题是我成为了新仓库所有提交的提交者。为避免这种情况，您可以查看使用git filter-branch --parent-filter 而不是git rebase 的类似问题的答案：
https://stackoverflow.com/a/44078243/4374441
【讨论】：