git存储库中的多个历史记录是否可能导致未来问题？

Question

我曾经git filter-branch在我的一个存储库中更新了大量的提交(更正了错误的作者和提交者电子邮件).我使用的命令是:

git filter-branch -f --env-filter "GIT_AUTHOR_EMAIL='mike.r.anderson.13@gmail.com'; GIT_COMMITTER_EMAIL='mike.r.anderson.13@gmail.com';"

接下来是git pull以与远程存储库同步

这很好,但是当我看到GitHub中的历史时,我看到了两个完整的历史,一个在变化之前,一个在变化之后.最终合并在一个点上.

这是一个问题吗？或者我可以安全地将这两个历史留在那里吗？

Answer 1

首先,git filter-branch意味着重写历史,而不是与另一个创建并行历史.如果您filter-branch通过合并完成了操作,则表示您使用不当.

这确实会导致混乱,因为有时您可能会看到历史记录中的一条,有时是另一条.每当你有多条历史记录做出同样的改变时,这都是一件坏事.想象一下诸如bisect或之类的操作blame,您试图找到引入特定更改的提交.现在,通常有两个历史提交实际上做同样的事情 - 你想要哪一个？

甚至基本操作,例如git log,在按日期排序时,可能会显示长时间的"重复"提交.显然不是理想的行为.

在一个更为思想的说明:你是否应该重写历史来纠正这样一个小问题？git具有针对这种情况的功能:" mailmap ".

除非存在安全问题,否则通常应避免重写已发布的历史记录(即:披露问题......即使这样,一旦秘密出现,最好使秘密无效,而不是仅在可能的情况下限制其曝光)或者像这样的情况,其中发布了一些不良历史,这使得存储库难以使用.

请注意,运行历史记录重写命令(例如filter-branch或rebase已发布的历史记录)将使git不再认为您的本地提交"基于"现有的上游提交.因此,正常推送会导致错误,例如:

! [rejected]        master -> master (non-fast forward)

所以你需要"强迫"推动,即:git push -f.关于-f申请的标准警告(确保不要破坏任何其他人的提交),当然还有关于重写公共历史的警告.

除了那些关于重写公共历史的警告之外,只要你实际重写,而不是创建平行历史,那么就没有必要担心了.让我们回顾一下主要潜在问题的摘要,为了完整性:

由于第三点,我建议保留一个标记"旧"历史记录,以便任何提交提交ID的历史讨论仍然指向某个地方有效.但是,请使用某些内容为标记命名,这样很明显标记不会用于新开发.