声明：我现在已经测试过了，它看起来像预期的那样工作（当然，假设我正确地理解了你）。但是，仍然有很多可能出错。 绝对只能在您的项目存储库的单独工作副本上进行尝试，并确保在推送到任何地方之前检查所有内容。在执行此操作之前，请保持完整的目录备份状态。
所以我假设你有两个独立的存储库。原项目（Gephi）：
A---B---C---D---E
^HEAD of Gephi
和你的项目，其第一个版本看起来与原有项目的最后一次修改：
E'---V---W---Y---...---Z
^HEAD of your project
（可能有一些分支，但其实并不重要。这里）
你想吃点什么（如果我理解正确的话）是：
A---B---C---D---E---V---W---Y---...---Z
您可以尝试以下操作。 再一次，在您自己的单独工作树上执行此操作，并在将其推送到任何中央存储库之前确保一切顺利！
虽然在自己的工作树的目录下，取头和原Gephi仓库的对象：
git fetch /path/to/original/gephi
如果您还没有克隆Gephi库，你还不如指定的github URL而不是本地文件系统路径。
这将导致当前的工作树中的下列情况：
A---B---C---D---E
^FETCH_HEAD
E'---V---W---Y---...---Z
^HEAD
我们没有很大的变化。目前，两位负责人彼此和平共处，完全独立，但您现在可以访问这两个存储库中的对象，并可以尝试将它们结合起来。
我们现在要放弃E”（这应该是相同的E），而是使电子项目的第一次提交的父，这是五，要做到这一点，你可以用git filter-branch：
git filter-branch -f --parent-filter 'test $GIT_COMMIT = <V> && echo "-p <E>" || cat'
分别用V和E的提交哈希代替<V>和<E>。为了找到这些，你可以做git log来检查你的项目的提交，并且，因为我们已经提取它们，所以git log FETCH_HEAD来检查Gephi的提交。
你，意思基于你的项目这将有效v连接直接E.
，如果事实证明，头（即，最后提交）原Gephi库的这应该甚至工作不Gephi中已经有新的提交，你还没有（尚未？）照顾。可以肯定的是，再次将<E>替换为基于您的更改的提交的散列，而不是与头部。
相反，请确保您将<V>替换为的首字母变化。也许你的版本库不包含与E相同的E'，但是第一次提交已经包含了对原始版本的更改。那么这第一次提交散列将是你的<V>，而不是后面的一个。
总结双方最后一段：上面的命令也应该工作，如果你的情况看起来像，例如，这样的：
A---B---C---D---E---F---G---H---I
^ ^FETCH_HEAD
point where your project branched off
V---W---Y---...---Z
^ ^HEAD
first change based on E
只要确保使用commit哈希，在这种情况下才有意义。
我刚刚测试过这个，它似乎工作（所以我更新了我的警告）。我仍然绝对建议你在一次性工作树上进行试验并进行完整备份。很容易让'filter-branch'语句错误，或混淆哈希！ –
如果本地项目有多个分支，或者历史上有任何合并，'git rebase'不是正确的工具，因为它会使历史线性化。改用'filter-branch'。 –
谢谢。这是我原来的，但我认为rebase有更简单的语法。我恢复了我的更改，现在只是再次提到了filter-branch。 –