2

我在另一个问题上链接到这个博客，我读到了这个关于某个 git 工作流程的警告：

这是导致大量头发拉扯的实际情况。

  • 该团队正在使用合并工作流程。很多人改变的东西真的很快。典型的风格是
    • 处理你的东西
    • 在本地提交
    • git pull 并希望没有冲突
    • 在其他人进入之前尽可能快地 git push
  • 很多团队成员都在使用 Tortoise Git，它运行良好，但他们从 Tortoise SVN 迁移，却不了解 Git 和 Subversion 之间的潜在差异。
  • 合并冲突经常发生，因为很多人在做很多事情
  • Tortoise Git 的一位用户会执行拉​​取操作，遇到合并冲突，解决合并冲突，然后在提交结果时仔细查看要提交的文件列表。那里有很多文件，他知道合并冲突只涉及几个文件。对于他的提交，他取消了他未参与的所有其他文件更改的检查，提交了结果并推送了提交。
  • 结果：其他人在该用户的上一次提交和这次提交之间完成的所有提交都被丢弃

我不确定我是否理解这将如何发生？进一步来说：

  • 你如何能够推动你所处的“错误”状态？正如我认为我理解的那样，这需要一个--force，但这里的故事是它被关闭了。pull用户在提交冲突修复和推送之间不需要吗？
  • 在这里丢弃甚至意味着我认为的意思吗？我很难相信它们会被“移除”，我想实际结果更像是它们正在被撤消？
4

2 回答 2

3

是的，这里的“丢弃”意味着被撤消（历史上有，但最上面的提交没有更改）。我认为结果类似于拉取更改并选择ours合并策略，即始终选择自己的版本而不是更改。

逐步解释我认为发生的事情

准备发布时

*---*---*---A---B          <--- user's master

*---*---*---X              <--- public repository master

“一个 Tortoise Git 的用户会做一个拉动”，这是 fetch...

*---*---*---A---B          <--- master
         \         
          \-X              <--- origin/master (remote tracking branch)

...随后尝试合并：“发生合并冲突”...

*---*---*---A---B---[C]          <--- master
         \          / 
          \-X------/

现在有点模棱两可：

解决合并冲突，然后仔细查看他在提交结果时要提交的文件列表。那里有很多文件，他知道合并冲突只涉及几个文件。对于他的提交，他取消了他未参与的所有其他文件更改的检查，提交了结果并推送了提交。

我的看法是“解决...然后”应该阅读“解决...由”，即所述描述是用户如何解决合并，而不是作为单独的步骤完成的事情。解决合并以提交它结束：

*---*---*---A---B----B'          <--- user's master
         \          / 
          \-X------/

使用类似我们的合并策略的结果在哪里B'，从用户版本中获取冲突文件，替换/忘记更改X

假设公共存储库中没有其他活动，其中的“主”分支仍然如下所示：

*---*---*---X              <--- public repository master

并且 push 将快进并成功：

*---*---*---A---B----B'     <--- public repository master
         \          / 
          \-X------/

当其他人将拉新更改时，他/她会看到 state B'，其中不包括X由于错误合并（不正确的手动冲突解决）而导致的更改。

于 2013-09-12T13:13:45.793 回答
1

Jakub 的回答是正确的，但如果有人想要更简短的解释，这里是：

没有提交丢失，也没有从远程存储库中删除。只是合并提交将一些代码恢复到以前的状态。

这种情况类似于使用时发生的情况git revert- 想象一下这样的历史：

A---B---C---D

runninggit revert B将导致一个新的提交b“撤消”由B. 历史就是现在

A---B---C---D---b

CommitB仍然存在，但它的更改已被 commit 删除b。

于 2013-09-13T12:50:19.607 回答