问git遥控器之间同步分支的过程

EN

TL;DR

我必须明确地..。推到origin

是的，但不是你想的那样。不过，这可能是最方便的。

长

每个Git存储库都是一个独立的实体。Remotes (就像在您自己的存储库中那样)或叉链接(如在GitHub或Bit桶叉中)记录另一个Git存储库的标识，但是这两个存储库仍然是独立的实体。因此，每个分支都有自己的分支，不与任何其他Git存储库共享。

只在“共享时间”(git fetch和git push)时与其他Git存储库共享的是提交。它们使用它们的原始散列ID进行共享。这也是分支名称真正进入图片的地方，因为Git存储库通过其分支名称(以及其他引用)找到它的提交，但这里我们只关注分支名称。

请记住，Git存储库中分支名称的作用是包含最后一次提交的散列ID，该哈希ID将被视为“在”该分支，即分支的尖端提交。当您使用git checkout branch后面跟着最终的git commit时，您的Git：

• 构建新提交
• 将新提交的父哈希ID设置为当前提交哈希ID时
• 然后将新提交的散列ID写入当前名称

这样，分支名称再次指向最新(提示)提交。该提示提交指向前一个提示，该提示指向另一个早期提交，依此类推。

因此，git push所做的是：

• 提交一些提交，在理想情况下，只需扩展一些现有分支，然后
• 请求其他Git设置其分支名称以记住添加的提交的最顶端提交。

(像这样扩展分支是一种快速转发操作。)

如果新提交不只是扩展一些现有的分支(Es)，那么那些特定的名称更新必须是“强制的”：其他Git只会对那些不是快速转发操作而不是强制的更新请求说不。

但是，并不要求这些分支名称值更改与您自己的存储库中的任何实际分支名称相对应。例如，考虑常见的情况(至少对我来说)，我正在处理某些特性，并且编写了六个或更多的提交。从这些中，我确定一个绝对是一个好主意，所以我运行git rebase -i feature并将其放在前面。然后我可以跑：

git push origin <hash>:for-review

并提出了基于for-review的拉请求。从图片上看，我在自己的存储库中拥有的内容如下所示：

...--o--o   <-- origin/feature
         \
          *   <-- origin/for-review
           \
            o--o--o--o--o   <-- feature

六次提交中有五次仍未提交；只有一次(此处标记为* )被推送到origin存储库上的名称for-review。然而，我可以在我自己的feature分支上继续在自己的存储库中工作，即比origin/feature提前6次提交，在origin/for-review之前提交5次。我只需要小心地记住提交*现在是共享的(这很容易:它有一个可以到达它的origin/名称)。

这就引出了您在自己的存储库中必须做的事情，以便将提交从mainline的Git存储库转移到origin的存储库。首先，您必须从mainline获得提交(以及它们的提示指向名称)。

git fetch mainline

现在您有了所有的提交；现在您可以使用以下方法更新origin：

git push origin mainline/2018.05.x:2018.05.x

它将发送origin没有但确实需要的任何提交来完成这项工作，然后在origin上创建名称2018.05.x，指向与您自己的mainline/2018.05.x相同的提交。

诚然，这有点混乱--但关键是，只要您有一个名称，您(和您的Git)就可以在您自己的存储库中找到提交，那么您就不必为提交使用分支名称。要将这些提交发送到另一个Git，您可以通过散列ID或origin/whatever名称将它们发送给Git，也可以创建分支名称，或者执行任何您喜欢的操作，只要它标识了适当的提示提交。但是，在lhs:rhs名称对的右侧，您必须提供一个origin上的Git可以创建或更新的名称。

便利性

使用git push (但不是git fetch!)，如果您运行：

git push origin abc

这个“意思”和：

git push origin abc:abc

因此，在许多方面，为每个分支都有您自己的本地名称肯定更方便。