有没有办法删除“删除”;“毫无意义”;从git历史记录提交?

有没有办法删除“删除”;“毫无意义”;从git历史记录提交?,git,version-control,collaboration,Git,Version Control,Collaboration,假设我有这样一个git历史记录: A-B-C-D-E-F-G B增加了60k个文件 F删除了那些相同的文件 任何遍历git历史的操作,例如git log,如果必须跨越F(或B),现在都需要花费大量的时间 考虑到B和F只是相互抵消,有没有办法有效地从历史中删除它们 更重要的是:有没有一种简单的方法来做到这一点,然后确保使用回购协议的其他开发商也是最新的?(请记住,开发人员的机器上也有功能分支。)我怀疑所有的解决方案最终都会导致A-C'-D'-E'-G' 我的直觉告诉我,我能得到的最好的方法是从a

假设我有这样一个git历史记录:

A-B-C-D-E-F-G
B增加了60k个文件

F删除了那些相同的文件

任何遍历git历史的操作,例如
git log
,如果必须跨越F(或B),现在都需要花费大量的时间

考虑到B和F只是相互抵消,有没有办法有效地从历史中删除它们

更重要的是:有没有一种简单的方法来做到这一点,然后确保使用回购协议的其他开发商也是最新的?(请记住,开发人员的机器上也有功能分支。)我怀疑所有的解决方案最终都会导致
A-C'-D'-E'-G'


我的直觉告诉我,我能得到的最好的方法是从a创建一个分支,从C到E,然后从G创建一个新分支,并将其合并到第一个分支上。或者别的什么。

只需执行
git rebase-ia
并删除B和F的行。
但正如您所说(或意味着),这将重写已发布的历史记录,因此您的所有开发伙伴都需要基于该被操纵的分支重新设置其所有分支的基础,如“
git-rebase
手册中“如何从上游rebase恢复”一节中所述。

指的是“从上游rebase恢复”:正在讨论的分支是
主分支
。我的理解是否正确?如果我做了一个交互式的重新基址来消除违规提交,我将不得不强制推送到Github以覆盖
master
,然后让我的同事重新基址他们当前拥有的每个主题分支?没错。这就是改写已出版历史的“成本”。这也是为什么您通常只为您的本地分支使用合并和推送更改以及重定基础。