此工作流程如何导致丢弃工作？答案

【问题标题】：How does this workflow result in discarded work?此工作流程如何导致丢弃工作？
【发布时间】：2013-09-16 21:10:01
【问题描述】：

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

这是导致大量头发拉扯的实际场景。

团队正在使用合并工作流。很多人改变的东西真的很快。典型的风格是

处理你的东西

在本地提交

git pull 并希望没有冲突

在其他人进入之前尽可能快地进行 git push

许多团队成员都在使用 Tortoise Git，它运行良好，但他们从 Tortoise SVN 迁移，却不了解 Git 和 Subversion 之间的潜在差异。

合并冲突经常发生，因为太多人做了太多事情

Tortoise Git 的一位用户会执行拉取操作，遇到合并冲突，解决合并冲突，然后在提交结果时仔细查看要提交的文件列表。那里有很多文件，他知道合并冲突只涉及几个文件。对于他的提交，他取消选中了他未参与的所有其他文件更改，提交了结果并推送了提交。

结果：其他人在此用户的上一次提交和本次提交之间完成的所有提交都被丢弃了

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

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

【问题讨论】：

您所说的“其他人在此用户的上一次提交和本次提交之间完成的提交”是什么意思？提交是在那个时间范围内提交的，还是被推送的？
为什么每个人都应该在自己的私有分支上工作，而不是每个人都在努力工作的主要例子。 master...
@Oznerol256 ：我不是那句话的原作者，我只是问我是否说对了。我不确定这是什么意思:)
@twalberg 但是在非私人分支机构工作肯定有好处吗？合作？特别是当它不是主分支时？
@Nanne 在分布式 VCS 中最好在私有分支上完成所有工作，然后将您的工作合并到公共分支中。这导致公共分支上的流量大大减少，冲突和其他竞争条件的频率相应显着下降。

标签： git version-control merge merge-conflict-resolution

【解决方案1】：

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

现在有点模棱两可了：

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

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

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

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

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

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

并且push会快进成功：

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

当其他人拉取新更改时，他/她将看到状态 B'，其中不包括来自 X 的更改，因为错误合并（不正确的手动冲突解决方案）。

【讨论】：

但是如果你想在合并后推送，那么你要么需要先拉取（所以得到这些更改），或者使用--force（这不可能发生）？因此我的第一个问题是：如何在没有本地“知识”其他提交的情况下推动这个状态？
@Nanne：从我的解释中了解到，它是 pull 然后“放弃其他更改”merge然后快进 push.
我读它是因为在合并之后/期间还有其他更改，所以我很困惑 ff push 甚至可以工作？也许更改是在同一个仓库中完成的？虽然这很奇怪，否则我就是不明白。也许第一个问题是：谁做了这些改变以及在哪里改变。
@Nanne：我已经用 ASCII 艺术图（希望可读）逐步解释了我认为发生的事情
但在这种情况下似乎什么都没有丢失？ “其他人的所有提交”在哪里适合？我以为他们在公共存储库主服务器上，因此在状态 Y 中也是如此，因此无法进行快进。我想问题不是那么大，而且我正在寻找真正的麻烦。在您提出的解释中，我无法在任何地方找到这些提交，但也许它们意味着 X 的更改？在这种情况下，您可以 fsck up 的唯一地方是拉动更改，然后我猜没有正确合并？因此，您几乎可以手动删除更改。好吧，我认为这不是一个值得担心的场景。

【解决方案2】：

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

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

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

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

运行git revert B 将导致一个新的提交b “撤消”由B 引入的更改。历史就是现在

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

提交B 仍然存在，但它的更改已被提交b 删除。

【讨论】：

看起来差不多，而且短了一点。这确实可能是作者的意思，但它与第一个问题恕我直言（推力问题）不在同一个级别
这里也有类似的。 push --force 的问题是，当您推送作为先前推送提交的后代的提交时，您不需要它。 “还原提交”（在我的示例中为b）是远程分支（D）的后代，因此即使它删除了东西，也可以在没有--force 的情况下推送它。同样，合并提交是先前推送的提交的后代，无论它可能引入何种破坏性更改。