git - 大量git历史记录重写后如何同步本地历史记录？

Question

这个问题可能看起来很奇怪，但在重写了100多个提交之后，我在同步git历史记录时遇到了问题。
在我重写的机器上，一个简单的git fetch将其全部同步。
在另一台mac机器上，git sync没有帮助，但是在随机删除本地.git/日志和refs文件，然后发出git pull之后，历史记录被刷新。
但是，无论我在windows机器上做什么，我都无法刷新项目历史记录。都试过了：
git reset --hard HEAD&git fetch
git fetch --all
git pull
等
每次在windows机器上，我都会得到同一提交的不同作者的重复条目（我更改了作者字段）。
我使用本教程进行了大量历史重写：
https://help.github.com/articles/changing-author-info/

Open Terminal.

Create a fresh, bare clone of your repository:

git clone --bare https://github.com/user/repo.git
cd repo.git
Copy and paste the script, replacing the following variables based on the information you gathered:

OLD_EMAIL
CORRECT_NAME
CORRECT_EMAIL

#!/bin/sh

git filter-branch --env-filter '
OLD_EMAIL="your-old-email@example.com"
CORRECT_NAME="Your Correct Name"
CORRECT_EMAIL="your-correct-email@example.com"
if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags
view rawgit-author-rewrite.sh hosted with ❤ by GitHub
Press Enter to run the script.
Review the new Git history for errors.
Push the corrected history to GitHub:

git push --force --tags origin 'refs/heads/*'
Clean up the temporary clone:

cd ..
rm -rf repo.git

有没有人有过大规模git历史重写的经验？如果是，其他团队成员刷新git历史记录的步骤是什么？

Answer 1

理解这里问题的关键是，在git中：
承诺就是历史。
任何提交的“真名”都是它的哈希ID。
任何提交都不能更改。
每个提交都通过hash id记住其以前的（直系祖先，也称为父）提交。
名称，包括分支和标记名称，主要只存储一（1）个hash id。
分支名称的特殊属性是，它会随着分支的增长而更改存储的散列ID，通常是以一种“友好”的方式，以便无论今天提交的分支名称是什么，该提交（按散列ID）最终返回到昨天标识的提交（按散列ID）。
当你“重写历史”时，你不能改变任何现有的提交。相反，您复制每个现有的提交。git filter-branch所做的是将您请求的所有提交按“最早”（最早）的顺序复制到“最新”（最早/最晚）的顺序，应用过滤器：
提取原始承诺；
应用筛选器；
根据结果进行新的提交，父哈希ID更改由以前的一个或多个副本指示。
最后，这对于一个真正的大规模重写意味着，本质上，您有两个并排放置的不同存储库：一个是旧的，有旧的提交，另一个是新的，有新的提交。在筛选过程结束时，git filter-branch将名称更改为指向新副本。
如果您有一个只有三个提交的小型存储库，我们将其称为commitsA到C-和一个master分支，并且所有三个提交都需要一些更改，那么您将拥有：

A--B--C   [was the original master]

A'-B'-C'  <-- master

新的提交实际上是新的提交。任何仍在使用旧提交的人实际上仍在使用旧提交。他们必须停止使用这些提交，转而开始使用新的提交。
在某些情况下，使用 git filter-branch指定的筛选器最终不会在原始提交中更改任何内容。在这种情况下，如果 filter-branch写入的新提交与原始提交是逐位相同的，那么，只有在那时，新提交实际上与旧提交相同。如果我们查看这三个相同的提交原始存储库，但选择只修改第二个提交的内容或元数据的筛选器，我们将得到：

A--B--C
 \
  B'-C'  <-- master

最后的结果。
请注意，即使原始 B没有被过滤更改，也会发生这种情况。这是因为原始 C的某些内容发生了更改，导致新的和不同的提交 B。因此，当 B'拷贝 git filter-branch时，它必须做一个更改：拷贝 C的父级是新的 C'而不是原始的 B'。
也就是说， B将 git filter-branch复制到一个新的提交，但根本没有做任何更改（甚至没有对任何父信息进行更改），因此新的提交结果是对原来的 A的重用。然后它将 A复制到一个新提交，并进行了更改，因此新提交现在是 B。然后它复制 B'而不做任何更改，将父级更改为 C，并编写新的commit B'。
如果您的过滤器只对 C'进行了更改， C命令会将 git filter-branch复制到自身， A复制到自身， B复制到 C，从而：

A--B--C
    \
     C'  <-- master

处理上游重写
一般来说， the easiest way for people to deal with a really massive upstream C' rewrite is for them to discard their existing repositories entirely。也就是说，我们只希望共享几个原始提交：在大规模重写的早期，我们更改commit origin或其附近的一个提交，以便将每个后续提交复制到新的提交。因此，创建一个新克隆可能比更新现有克隆更昂贵。当然更容易！
严格地说，这不是必要的。作为一个“下游”消费者，我们可以运行 A并获得所有带有更新的分支名称的新提交，也许还有更新的标记（这里要特别小心，因为默认情况下标记不会更新）。但是，由于我们有自己的分支名称，指向原始提交而不是新复制的提交，我们现在必须使每个分支名称都引用新复制的提交，也许还复制上游没有的任何提交（因此还没有复制）。
换言之，我们可以为每个分支运行：

git checkout <branch>
git reset --hard origin/<branch>

要使我们的 git fetch名称作为提示提交，请使用与 branch名称相同的提交。（请记住， origin/branchforce会更新所有的 git fetch名称，以匹配 origin/branch指向的散列id）
这相当于删除每个分支并使用 branch重新创建它们。换言之，它不会推进我们的任何承诺，即重写 origin的人没有复制（因为他们不能复制，因为他们没有复制）。为了推进我们的承诺，我们必须做同样的事情，我们将 deal with an upstream rebase。内置的fork-point代码是否能为您正确地实现这一点，如果您的git至少是2.0，那么它通常会正确地实现这一点，这实际上是一个单独的问题（已经在其他地方得到了回答）。请注意，对于您已承诺要结转的每个分支，您都必须这样做。