将本地 master 分支与远程分支合并后，是否应该将其推回远程？

我是 git 的新手，所以如果这个问题没有意义，我很抱歉，但它让我摸不着头脑。我将尝试解释这个场景：

A 点：用户 1 和用户 2 已将主分支与远程存储库同步。

B 点：用户 1 创建一个本地分支“U1”，他将在那里工作。他先完成任务。

点 C： 用户 2 创建了一个本地分支“U2”，她将在那里工作。完成她的任务需要一点时间。

点 D： 用户 1 将检出他的本地 master 分支，将其与 U1 合并，然后将其推送到远程仓库。

E 点：用户 2 完成她的任务，然后尝试做与用户 1 几乎相同的事情。检查她的本地主分支，将其与 U2 合并，然后尝试推送到远程仓库。这就是问题发生的地方。她没有最新版本的 master 分支了。

现在，我知道用户 2 在将修改发送到远程仓库之前必须 git pull origin master，这意味着与她的本地 master 分支和远程 master 分支合并。并且，稍后，她是否应该立即将这个“新”主服务器推送到远程服务器？（因为它现在有那些合并分支的提交）

简短的回答是肯定的。

在这种情况下有很多变量没有确定，但让我们仔细看看：

在最简单的情况下，每个用户都在他们可以的时候进行快进（不重写任何历史记录），并在他们不能时创建合并提交。在这种情况下，两个用户都以类似

O <--(master)(origin/master)

（其中 O 之前的任何历史记录对于本练习并不重要）。 User1 创建 U1 并做一些工作

O <--(master)(origin/master)
 \
  A <--(U1)

当他们合并时，这可能是一个快进，所以他们有

O <--(origin/master)
 \
  A <--(U1)(master)

等推master和简单地

O - A <--(U1)(master)(origin/master)

用户 2 还没有看到这一切，所以她创建了她的分支，工作，然后快进合并以获取

O <--(origin/master)
 \
  B <--(master)(U2)

现在推送失败，所以她可以获取和获取

O - A <--(origin/master)
 \
  B <--(master)(U2)

现在如果她合并（或者如果她跳过了 fetch 而只是 pulled）她以

结尾

O - A <--(origin/master)
 \   \
  \   M <--(master)
   \ /
    B <--(U2)

现在，请注意 origin/master 没有改变；要在 master 上分享她的工作，User2 仍然需要推送它们。如果她不这样做，那么当 User1（或其他任何人）从 master 创建一个新分支时，有两件事可能会出错：

首先，他们不会在 master 分支上看到 User2 的工作。也许它可以帮助他们。也许这会改变他们做某事的方式。或者，也许他们要做的只是与他们看不到的更改创建代码冲突。

因此，当他们推送工作时，共享的 master 分支再次与 User2 的 master 分支不同。再取一次后，她可能会看到

O - A - C <--(origin/master)
 \   \
  \   M <--(master)
   \ /
    B <--(U2)

为了解决这个分歧，她至少必须再次将 origin/master 与 master 合并。如果她只那样做，她就会得到

O - A - C <--(origin/master)
 \   \   \
  \   M - M2 <--(master)
   \ /
    B <--(U2)

如果 hse 想要更清晰的历史，她可能会在本地重写历史以从 M 中取出原来的 master - 但如果 M 包含任何合并冲突，她可能不得不重做它们.

所有这些仍然会让她处于创建 M 后的状态 - 她的工作（来自 U2 分支）仍未在 {{1} 上共享}} 直到她推动。

所有这些或多或少都是“最简单”的情况。由于您提到了在分支上工作的每个用户，因此您可能正在使用 no-ff 方法来保留分支拓扑；这会使上面的所有图表变得更加复杂，但重点是相同的：在推送 master 和 origin/master 的合并之前，远程不知道 {{1} 的本地更改}.