我正在尝试找出使用Git将远程分支（origin/develop）合并到我的远程主分支（origin/master）中的标准方法。我看了这个：
Git - How to merge a remote branch into remote master
这表明我要执行以下操作：
1）在我的本地develop分支上进行更改
2）在develop上提交更改
3）将本地develop合并到本地master
4）将本地master推送到origin/master
这是我的问题：我不需要将一个远程分支合并到另一个分支中吗？标准方法是否只是为了不断更新像origin/develop这样的远程分支以保存进度，最终将这些更改合并到本地master中并推送到origin/master？
我认为这会弄乱我的远程提交日志，因为我最终将删除我用来跟踪本地develop进度的远程分支...
谢谢！
答案 0 :(得分：2)
我永远不需要将一个远程分支合并到另一个分支中吗？
事实上，您不能这样做。好吧，虽然可以，但是-好，令人困惑。让我们备份。 ：-）
Git在这里用的术语比较差。 branch （分支）一词不明确。一旦您习惯了其所有不同的含义，它就不是一个坏名字了：有人说“在分支X上工作”或“签出分支Y”，我们都知道我们的意思，但是要达到这一点很难。有关更多信息，请参见What exactly do we mean by "branch"?，但首先请注意：Git主要与 commits 有关。分支名称稍后出现。
Git（和您）找到提交的最基本方法是通过其哈希ID，该哈希ID保证对该特定提交是唯一的。但是这些哈希ID似乎是随机的：例如，26e47e261在8b026edac之前，而1f1cddd55在其中一个之后（例如，这是Git的Git存储库中的实际提交）。名称，如分支名称和远程跟踪名称，可以让Git和您查找提交。每个这样的名称都只能记住一个哈希ID。
几乎每个提交都还记住一个或两个哈希ID。这些是该提交的 parent 提交。 Git可以将这些不同的哈希ID（从存储在名称中的哈希ID开始，然后向后工作）放入提交链中：
A <-B <-C <--master
名称master会记住提交C的哈希ID，它会记住提交B的哈希ID，后者会记住提交A的哈希ID。 A是第一个提交（在这个只有三个提交的小型存储库中），因此它没有父级，因此结束了链。
添加新提交的过程包括写出新提交，使用当前分支链的哈希哈希ID作为其父对象，然后使 name 指向新提交。提交：
A--B--C--D <-- master
（不绘制内部箭头会更容易，因为内部箭头始终按定义指向后方，而且与分支名称不同，一旦创建就永远不能更改，因此我通常不绘制它们。）
使用Git存储库时，通常首先要从其他现有的Git存储库中获取所有提交。 other Git使用 its 分支名称来查找这些提交。您的Git会收集这些提交，但是您的Git会给您您的分支名称，而与它们的名称无关。因此，您的Git需要一些 other 名称（不是 branch 名称的名称）才能找到它们的提交。您克隆他们的存储库，然后将自己的master的Git 重命名到您的origin/master-一个远程跟踪名称或远程跟踪分支名称，有人将其称为远程分支名称。 1
在创建origin/*的初始克隆之后，git fetch origin将调用相同的URL（从您进行克隆时保存的时间）开始，与同一个Git进行对话，并从中收集所有新提交它可能具有，并更新您的所有远程跟踪名称以匹配其分支名称。因此，您的远程跟踪名称会自动 其分支名称。这是他们的主要目的：记住其分支名称正在记住。
1 “远程分支名称”可能是所有这些短语中最差的，并不是每个短语都很棒，因为Git使用单词 remote 来指代像origin这样的名称，您可以用来标识 other Git存储库。因此，如果您要通过remote.origin.url下列出的URL进入Git并询问其分支，您将得到 their master， their develop，依此类推。这些是遥控器上的分支名称：遥控器的分支名称。每个名称必须一定是一个远程分支名称。但是它们不在您的 Git中，而Git却具有origin/master和origin/develop之类的名称。我认为将origin/master称为远程跟踪名称是这些模棱两可的短语中最好的：它是其的您的名称（{{ 1}}'s origin。
master的最后一步通常是git clone。 2 您的Git还没有 }，所以您的Git会遍历它所拥有的所有远程跟踪名称（只是使它们命名）（git checkout master和master等），然后找到它们的origin/develop。这指向某些特定的提交，因此您的Git现在创建您的origin/master，指向相同提交：
origin/master如果您现在运行master，则会创建自己的A--B--C--D <-- master (HEAD), origin/master
\
E <-- origin/develop
，指向与git checkout develop相同的提交：
develop请注意，origin/develop附加在您的分支名称之一上，这就是Git在进行新提交时如何知道您所在的分支的原因。
假设您通过执行A--B--C--D <-- master, origin/master
\
E <-- develop (HEAD), origin/develop
并进行一些工作将自己的提交添加到自己的HEAD中。这将创建一个新的唯一的哈希ID提交，并使您的master指向此新提交：
git checkout master此特定示例未使用master，它有其自身的一系列复杂性（我不想在这里进行详细介绍），但要点很简单：您始终会做所有事情您的在您自己的分支上的工作。完成此工作后，您可以运行 F <-- master (HEAD)
/
A--B--C--D <-- origin/master
\
E <-- develop, origin/develop
到：
因此，您现在可以git merge向您发送新的提交git push，并要求他们将他们的新提交 git push origin master指向提交{{1} }。如果他们同意这一点，那么您的Git会记录此更新，以便您现在拥有：
F 2 您可以告诉您的Git使用另一个名称，如果不使用，另一个Git告诉您的Git使用哪个名称，但是通常是master。