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

标签 git git-rewrite-history

这个问题可能看起来很奇怪,但在重写了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历史记录的步骤是什么?

最佳答案

理解这里问题的关键是,在git中:
承诺就是历史。
任何提交的“真名”都是它的哈希ID。
任何提交都不能更改。
每个提交都通过hash id记住其以前的(直系祖先,也称为父)提交。
名称,包括分支和标记名称,主要只存储一(1)个hash id。
分支名称的特殊属性是,它会随着分支的增长而更改存储的散列ID,通常是以一种“友好”的方式,以便无论今天提交的分支名称是什么,该提交(按散列ID)最终返回到昨天标识的提交(按散列ID)。
当你“重写历史”时,你不能改变任何现有的提交。相反,您复制每个现有的提交。git filter-branch所做的是将您请求的所有提交按“最早”(最早)的顺序复制到“最新”(最早/最晚)的顺序,应用过滤器:
提取原始承诺;
应用筛选器;
根据结果进行新的提交,父哈希ID更改由以前的一个或多个副本指示。
最后,这对于一个真正的大规模重写意味着,本质上,您有两个并排放置的不同存储库:一个是旧的,有旧的提交,另一个是新的,有新的提交。在筛选过程结束时,git filter-branch将名称更改为指向新副本。
如果您有一个只有三个提交的小型存储库,我们将其称为commitsAC-和一个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'
也就是说,Bgit filter-branch复制到一个新的提交,但根本没有做任何更改(甚至没有对任何父信息进行更改),因此新的提交结果是对原来的A的重用。然后它将A复制到一个新提交,并进行了更改,因此新提交现在是B。然后它复制B'而不做任何更改,将父级更改为C,并编写新的commitB'
如果您的过滤器只对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。也就是说,我们只希望共享几个原始提交:在大规模重写的早期,我们更改commitorigin或其附近的一个提交,以便将每个后续提交复制到新的提交。因此,创建一个新克隆可能比更新现有克隆更昂贵。当然更容易!
严格地说,这不是必要的。作为一个“下游”消费者,我们可以运行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,那么它通常会正确地实现这一点,这实际上是一个单独的问题(已经在其他地方得到了回答)。请注意,对于您已承诺要结转的每个分支,您都必须这样做。

关于git - 大量git历史记录重写后如何同步本地历史记录?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48267025/

相关文章:

linux - 如何让本地安装优先于系统范围安装?

javascript - nodejs lstat 找不到文件

git - 是否有包含 merge (仅)和非 merge 提交的 `git log` 摘要?

java - 如何在给定 commit-sha 的情况下使用 JGit 读取 Git 注释

GIT - 如何 merge 分支?

git - 修改 merge 前 Git 提交的消息

Git:删除除特定目录之外的所有内容(BFG Repo Cleaner)

git,在所有分支上过滤分支

git - 您如何修复错误的 merge ,并将您的良好提交重播到固定的 merge 中?

git - 使用 git rewrite 重新格式化整个代码库