Git 从上游远程分支合并到本地远程分支

我们在组织中使用fork模型，我正在尝试将上游分支的更新合并到本地分支

这是我的git设置

kartik@ ~/sourcecode/myproject (defect-875) $ git remote -v
origin  git@github.com/kartik/myproject.git (fetch)
origin  git@github.com/kartik/myproject.git (push)
upstream    git@github.com:MyOrg/myproject.git (fetch)
upstream    git@github.com:MyOrg/myproject.git (push)

上游有两条支流

主人

德维尔

我需要将我的本地分支与上游分支同步

这就是我尝试过的

git fetch upstream
git merge upstream/defect-875

其中defect-875是我当地的分支机构

我总是收到这个错误消息

合并：上游/缺陷-875-我们无法合并

我也试过这个

kartik@ ~/sourcecode/myproject (defect-875) $ git merge upstream/devel -m "Merging from seo redirect."
 merge: upstream/devel - not something we can merge

---

如何解决这个问题？

我想你应该说

git merge-upstream/devel-m“Merging from-devel”

（检查了defect-875，这样我们就在同一页上了）。

我认为这是正确的选择，但听起来你应该学习一些git技巧

关于Git，首先要知道的是它主要是关于提交的。分支，或者说分支名称（请参阅）——存在于Git中，以便Git和我们能够找到提交

您可能已经知道，提交实际上是源树的快照。（如果你没有，那么，现在你有了！）但它还有一点更多。首先，每个提交都有一个以散列ID形式表示的唯一“真实名称”。分支名称是表示某些提交的真实名称的一种方式。散列ID和

git rev parse

将向您显示实际的散列ID：

$ git rev-parse master
c05048d43925ab8edcb36663752c2b4541911231

这些丑陋的大ID看起来是随机的，但实际上完全由提交本身的内容决定。这些内容非常简短，这是上面的提交，为了减少垃圾邮件，对

@

进行了一些修改：

$ git cat-file -p c05048d43925ab8edcb36663752c2b4541911231 | sed 's/@/ /'
tree a446a29ef7ca90d9c64825fb00a0f1e1a099ca18
parent e9983f8965c0875cc6727e9644c84ff1dfc99372
author Junio C Hamano <gitster pobox.com> 1536096807 -0700
committer Junio C Hamano <gitster pobox.com> 1536096807 -0700

Git 2.19-rc2

Signed-off-by: Junio C Hamano <gitster pobox.com>

名称

master

指向此提交，它指向较早的提交

e9983f8965c0875cc6727e9644c84ff1dfc99372

。较早的提交指向更早的提交，依此类推

所有这些名称和对象都是您自己的存储库的本地名称和对象 您在自己的存储库中拥有所有这些分支名称，如

master

和

defect-875

。他们不依赖于你自己Git之外的任何东西。它们也指向本地的提交，这些提交（包括它们的快照、它们的父提交和那些提交的快照）在历史上也不依赖于您自己的Git之外的任何东西

但是您确实从其他Git获得了一些提交。你可以让你的Git通过互联网调用这些Git来实现这一点。他们的Git存储库有自己的提交和分支名称。提交都有唯一的散列ID，但是如果它们有一个与您的某个提交具有相同散列ID和相同真名的提交，那么根据定义，它们和您具有相同的提交

git fetch

获取您没有的提交 它们的分支名称不必匹配，但提交哈希ID必须匹配。要么他们匹配，你有承诺，要么他们有你没有的承诺。所以你的Git调用他们的Git并说：你有什么名字，他们的提交哈希ID是什么？他们的Git给了你的Git这个列表，你的Git对自己说：啊，我有这个，嗯，我没有那个。然后，你的Git会给他们的Git一个他们拥有的、你的Git想要的提交列表，他们的Git会打包这些提交，包括他们的快照并将它们发送过来

在这个过程结束时，您有所有的提交（包括您已经有的任何提交）加上他们的所有提交。请注意，它们不仅向您发送提示most提交（分支名称直接指向的提交），还根据需要发送父提交、父提交的父提交等，以便您获得连接回您自己的提交的提交

git fetch

还获取它们的分支名称；现在怎么办？ 你也有他们的分支名称。但是这些是它们的分支名称，所以现在你的Git重命名了这些东西。如果您的Git使用

Git fetch upstream

调用他们的Git，您的Git将重命名他们的

master

，调用它

upstream/master

，并重命名他们的

devel

，调用它

upstream/devel

我们可以像这样绘制提交，使用round

o

s代表实际的散列ID，尽管我现在必须开始猜测它们有多少提交是您没有的。在运行git fetch upstream之前，您有如下操作：

...  <-c05048d43925ab8edcb36663752c2b4541911231   <--master

... <-o <-o <-o   <-- master
               \
                o   <-- defect-875

                     o--o   <-- upstream/devel
                    /
             o--o--o   <-- upstream/master
            /
...--o--o--o   <-- master
            \
             o   <-- defect-875

             L----------------M   <-- defect-875 (HEAD)
            /                /
...--o--o--B                /
            \              /
             o--o--o      /
                    \    /
                     o--R   <-- upstream/devel

（箭头太难画了，所以我用线代替了大部分箭头，记住它们总是指向后方）

现在你可以合并了 运行

git merge

时，必须告诉git要与哪个提交合并。您通常通过给它一个分支名称或远程跟踪名称（如

upstream/devel

）来实现这一点。这个名称解析为一个提交散列ID，您可以运行

git rev parse

来查看它是如何工作的，正如上面所示。它之所以有效，是因为

git fetch

获得了他们的

devel

，并将其重命名为您自己的

上游/devel

。如果您尚未运行git fetch upstream，则必须首先运行该操作，以便git能够提交并重命名其

devel

，成为您的

upstream/devel

合并 此时，所有工作都在您自己的存储库中进行。假设我的画是准确的；但是，让我们将其简化为有趣的名称，并将单词

HEAD

附加到您现在签出的名称上。我还将为三个有趣的提交输入一个字母的名称：

                     o--R   <-- upstream/devel
                    /
             o--o--o
            /
...--o--o--B
            \
             L   <-- defect-875 (HEAD)

Git现在合并了这两组更改。如果它们很容易组合，Git会将组合的更改应用于与commit

B

关联的快照，并对结果进行新的提交。这是一种合并提交，一种特殊的提交。它的特殊之处在于它有两个父项而不是一个父项：它首先列出了您自己的commit

L

，如下所示：

             L----------------M   <-- defect-875 (HEAD)
            /                /
...--o--o--B                /
            \              /
             o--o--o      /
                    \    /
                     o--R   <-- upstream/devel

git push upstream defect-875

             L----------------M   <-- defect-875 (HEAD), upstream/defect-875
            /                /
...--o--o--B                /
            \              /
             o--o--o      /
                    \    /
                     o--R   <-- upstream/devel

git branch --set-upstream-to=upstream/defect-875 defect-875

git push -u upstream defect-875