1

感谢您提前提供的所有帮助。

这是一种情况，我试图了解 git 是否提供了解决此问题的方法：

两个用户（U1 和 U2）每个都有一个同步到提示的本地存储库。

U1 进行更改并提交此更改并推送到远程。U2 进行完全相同的更改并提交。但是当他试图推动时，他不能。所以他确实 git pull （没有变基）。现在 git 添加了一条“合并分支主控”消息。现在，如果 U2 现在推送，他的提交（这是 U1 所做的确切更改）再次被推送到远程。

有没有办法避免这种情况？我在这里错过了一些关键命令吗？

4

2 回答 2

3

首先，解决方案（潜在危险）。其次，关于如何使用 git 的一个可能不必要的警告：

危险的解决方案

第 1 步：变基。

（难度：中等——危险：中等）

使用git rebase -i <something>where<something>指示提交的命令，例如提交 SHA 或 HEAD~4（将 4 替换为交互式 rebase 的提交数）。该命令会打开一个编辑器，其中包含几段解释如何使用交互式变基的段落。你可以很容易地从那里删除重复的提交，但为了安全起见，你应该将你的分支保存到另一个分支。git rebase -i是一个非常有用的命令/开关来学习如何使用。

第二步：强制推送。

（难度：低---危险：高）

git push origin <branch name> --force推动你的改变。这是危险的，因为从该分支中​​提取的任何人都将不同步，并且需要删除他们的分支并重新获取它。他们应该遵循步骤 2a。如果除了您之外没有其他人使用该分支，则强制推送是安全的。

步骤 2a：更新其他所有人。

（难度：中等——危险：中等）

git branch -D yourbranch # Delete your branch
git checkout origin/yourbranch # Check out the remote-tracking branch
git checkout -b yourbranch # Recreate the branch

与 GitHub 集成的 CI 工具应该不受影响。

警告

您应该使用git-flow或一些类似的过程。您的两个用户不应该推送到同一个分支，否则您将一直遇到合并冲突。此外，不要对已合并到 master 或多个人将从中提取的任何提交进行 rebase。如果您强制推送，那么您需要将步骤 2a应用于每台机器上的每个仓库上的每个分支，这些机器上已将重新提交的提交合并到其中。如果您对 master 中的提交进行 rebase，那将是一场噩梦。

于 2013-04-30T00:21:25.860 回答
2

更改是否完全相同并不重要，因为 git 的提交对象（及其 SHA1）不仅基于实际差异创建，还基于作者、提交者、提交消息、提交的时间戳等.

由于 U2 执行的是 a pull（即 fetch + merge）而不是 a pull --rebase（即 fetch + rebase），因此您将获得一个新的合并提交，这仍然是一个更改（即使它不涉及工作树本身），因此将被推送到远程。下图应准确显示您的情况。

State of remote(say origin)
U1C1 -- U2C2

State of U1 on start
U1C1 -- U2C2

State of U2 on start
U1C1 -- U2C2

U1 after creating a new commit
U1C1 -- U2C2 -- U1C3

U2 after creating a new commit
U1C1 -- U2C2 -- U2C3'

Remote after U1 pushes the change
U1C1 -- U2C2 -- U1C3

U2 after git pull (Merging origin/master into master)
U1C1 -- U2C2 -- U2C3' -- U2C3"
             \          /
              \ U1C3 --/

Remote after U2 does a git push
U1C1 -- U2C2 -- U2C3' -- U2C3"
             \          /
              \ U1C3 --/

如果 U2git pull --rebase改为执行，U2 至少会注意到冲突，因此会退出他/她的提交。

git-flow用户可以使用类似的工具来管理 git 工作流。如果您在遥控器的裸仓库中使用 gitolite 之类的东西，那么在push少数情况下可能会有一些设置来控制或拒绝操作。

你也许可以通过重写历史来一次性解决这个问题，但是一旦提交被公开，重写历史是一个坏主意，因为可能会有用户仍然有旧的历史，他们会开始看到分歧历史。

于 2013-04-30T00:18:54.417 回答