免责声明：我现在已经对此进行了测试，它似乎可以按预期工作（当然，假设我理解正确）。但是，仍然有很多地方可能出错。绝对只在项目存储库的单独工作副本上尝试此操作，并确保在将其推送到任何地方之前检查所有内容。在执行此操作之前保留状态的完整目录备份。
所以我假设你有两个独立的存储库。原始项目（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 相同），而是将 E 作为项目第一次提交的父级，即 V。为此，您可以使用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
只要确保使用在这种情况下有意义的提交哈希。
