Feb 12, 2024 , with read , about 12min.

Git 强制执行 reset 可能会导致什么问题？

场景设定

假设有一个远程仓库 origin，其中 master 分支有以下提交历史：

A -- B -- C (master, origin/master)
copy success
copy

• 开发者甲 和 开发者乙 都从 origin/master 拉取了最新的代码。

开发者甲的操作

1. 开发者甲 发现提交 C 有问题，决定撤销它。

2. 开发者甲 使用 git reset 回退到提交 B，并创建一个新的提交 D 来修复问题：

   git checkout master
   git reset --hard B
   # 修复问题
   git commit -am "修正提交 C 的问题"
   copy success
   copy

   此时，开发者甲 的本地仓库历史：

   A -- B -- D
   copy success
   copy

3. 开发者甲 强制推送到远程仓库：

   git push origin master --force
   copy success
   copy

   远程仓库的 master 分支现在变为：

   A -- B -- D (origin/master)
   copy success
   copy

开发者乙的问题

开发者乙 当前仍在本地拥有提交 C，他的仓库历史：

A -- B -- C (master)
copy success
copy

当 开发者乙 执行常规的拉取操作时：

git pull origin master
copy success
copy

由于远程仓库的历史已经被 开发者甲 强制推送覆盖，Git 会尝试将 开发者乙 的本地分支与新的远程分支进行合并。这会导致以下几种可能的情况：

1. 合并冲突：

   如果 开发者乙 对提交 C 进行了修改，Git 无法自动合并，会产生合并冲突，需要手动解决。

2. 历史重写导致的问题：

   如果 开发者乙 没有及时同步，可能会遇到以下错误：

   error: Your local changes to the following files would be overwritten by merge:
       <文件>
   Please commit your changes or stash them before you merge.
   copy success
   copy

   或者，如果 开发者乙 使用 git pull --rebase，可能会看到类似以下的错误：

   CONFLICT (commit not found): commit C not found in origin/master
   copy success
   copy

   这些情况都需要 开发者乙 手动处理，可能会导致工作丢失或需要额外的时间来解决冲突。

如何避免问题

1. 使用 git revert 代替 git reset：

   通过创建反向提交来撤销更改，而不是重写历史记录。

   git revert C
   git push origin master
   copy success
   copy

   这样，远程仓库的历史会保持线性，且不会影响其他开发者的工作。

2. 提前通知团队成员：

   如果必须使用强制推送，提前告知所有团队成员，让他们做好准备和同步。

3. 使用分支保护：

   在远程仓库中设置分支保护，防止未经审核的强制推送。

总结

通过这个简化的例子，可以看到强制推送如何覆盖远程仓库的历史记录，导致团队成员在拉取更新时遇到合并冲突或其他问题。为了避免这种情况，推荐使用 git revert 等非破坏性的方法来撤销更改，并在必要时与团队成员进行充分沟通。