问题标签 [git-history-rewrite]

我有一个看起来像这样的 git 存储库：

我想在分支历史记录中移动常见的提交C和D更早的位置，main以便 repo 看起来像这样：

需要注意的是C//和C'//提交对代码的修改是相同的，但是由于在不同的分支中，它们都有不同的提交哈希。C''DD'D''

我们在 git 中使用了一个非常简单的结构。

首先我们有我们的master分支。

下面我们有develop

最后我们可以有任何feature分支

我们只使用 rebase 来更新我们分支的历史记录，然后 f-forwarding 到上面的分支。

每周，我们的develop分支都更新了一些features. 并且这个分支被重新定位并合并到 master （从developto master）。

问题

当我们变基并合并develop到 时，有时会出现冲突，我必须通过在我的分支中master执行master变基来修复它们。develop修复冲突后，我执行git push --force-with-lease将更改上传到远程。

在这个过程之后，发展的历史因为力推而改变。

当另一个开发人员正在feature基于强制推送之前的分支develop（强制推送develop之前）处理一个分支时，问题就存在了。

我们如何feature用新的分支历史更新这个开发者的develop分支。因为，git rebase develop 在我们的feature分支里面做的时候。我们最终会发生很多冲突。

我有一个托管在 GitHub 上的存储库，我想用git 历史记录中的LICENSE另一个文件替换我的文件。LICENSE原始LICENSE文件是在存储库的第一次提交中添加的。

尽管目前没有太多积极的开发活动，但我和一个队友的 repo 已经公开了 PR。

如何安全地LICENSE替换我的 git 存储库历史记录中的文件？ 我读到在用其他分支重写历史时可能会出现问题，因为当强制将更改的历史记录到上游时，它们依赖于不再存在的引用。 理想情况下，我希望所有上游分支仍然“工作”，即我应该能够在重写历史记录后将它们与正确的差异合并。

我可能不必关注没有被推向上游的其他同事的本地分支机构。最好不要破坏它们，但这并不重要。

我看到git filter-branch git filter-repo现在应该使用而不是。只要它安全地工作，任何解决方案对我来说都可以，尽管我也会对“最佳实践”解决方案感兴趣；）

为简单起见，让我们创建一个只有两个提交的存储库：

为清楚起见，此时git log --oneline返回

我想要得到的是以下内容

with somefileinthird具有与 in 相同的somefile内容first。

我当然可以做git cherry-pick master~（这里master是fd5b1ce）并完全解决冲突first，但也许有更清洁的方法？

在处理补丁时，我希望提供一组干净的提交。因此，我经常发现自己在提交集干净并准备好合并之前反复重写历史记录。
在这个过程中，在收到审稿人的意见后，我会回去rebase -i修复我的代码，修复提交消息等。每次创建一个新的修订提交来替换之前的提交。先前的提交仍然存在，但不再是修订历史的一部分。

经过几次历史重写迭代后，我终于得到了一个干净的修订提交集，我可以推送或转换为补丁集。但现在我有时喜欢回顾一下我对一个或一组提交所做的更改历史，看看我在这个历史重写过程中做了什么。
我可以手动跟踪它——在某个地方写下我正在编辑的每个提交的提交哈希，然后再重写它。这样我可以回顾历史重写的历史，但这很乏味且容易出错。

有没有办法自动化这个，让 git 自己跟踪“二阶”历史——历史重写的历史？获取一个git log'提交，以显示历史上为生成该提交而执行的所有“修改”操作？