这个问题可能看起来很奇怪,但在重写了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
将名称更改为指向新副本。
如果您有一个只有三个提交的小型存储库,我们将其称为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
,并编写新的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/branch
force会更新所有的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/