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

是的，这里的“丢弃”意味着被撤消(历史上有，但最上面的提交没有更改)。我认为结果类似于 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.

我的看法是“解决...然后”应该读为“解决...”，即所述描述是用户如何解决 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 的更改分辨率)。