git - 这个工作流程如何导致工作被丢弃？

Question

我链接到 this blog在另一个问题上，我读到了关于某个 git 工作流程的警告:

Here's the actual scenario that caused an enormous amount of hair pulling.

• The team was using the merge workflow. Lots of people changing things really fast. The typical style was
  • Work on your stuff
  • Commit it locally
  • git pull and hope for no conflicts
  • git push as fast as you can before somebody else gets in there
• Many of the team members were using Tortoise Git, which works fine, but they had migrated from Tortoise SVN without understanding the underlying differences between Git and Subversion.
• Merge conflicts happened fairly often because so many people were doing so many things
• One user of Tortoise Git would do a pull, have a merge conflict, resolve the merge conflict, and then look carefully at his list of files to be committed back when he was committing the results. There were lots of files there, and he knew that the merge conflict only involved a couple of files. For his commit, he unchecked all the other files changes that he was not involved in, committed the results and pushed the commit.
• The result: All the commits by other people that had been done between this user's previous commit and this one were discarded

我不确定我是否理解这将如何发生？更具体地说:

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

Answer 1

是的，这里的“discarded”是撤销的意思(历史上有，但是topmost commit没有变化)。我认为结果类似于 pull 更改并选择我们的 merge 策略，即选择始终拥有自己的版本而不是更改。

---

逐步解释我认为发生了什么

准备发布时

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

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

“Tortoise Git 的一个用户会做一个 pull”，这是获取...

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

...接着尝试 merge :“有 merge 冲突”...

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

现在有一点歧义:

resolve the merge conflict, and then look carefully at his list of files to be committed back when he was committing the results. There were lots of files there, and he knew that the merge conflict only involved a couple of files. For his commit, he unchecked all the other files changes that he was not involved in, committed the results and pushed the commit.

我的看法是“resolve... and then”应该读作“resolved... by”，即上述描述是用户如何解决 merge ，而不是作为单独的步骤完成的事情。解决 merge 以提交结束:

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

其中 B' 是使用类似我们的 merge 策略的结果，其中冲突文件取自用户版本，替换/忘记 X

中的更改

假设公共(public)仓库中没有其他事件，其中的'master'分支仍然是这样的:

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

并且推送会快进并成功:

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

当其他人将 pull 新更改时，他/她会看到状态 B'，由于错误 merge (不正确的手动冲突)，该状态不包括来自 X 的更改分辨率)。