创建远程存储库的远程分支

Question

我已经开始从事前端开发人员的工作，并被指示暂时使用我前任的git工作流程。

他正在为sprint创建一个远程分支，即跟踪母版（因此sprint-01（远程）跟踪母版），然后再次在本地分支（sprint-01（本地））以进行更改。 远程sprint-01部署到暂存网站-在本地服务器上未进行任何开发。

问题是我不知道如何创建远程存储库的远程分支。

到目前为止，我已经尝试过

git remote add -t master sprint-01 <URL>

而且它没有像以前的冲刺一样显示在分支列表中； 我得到：

master 
remotes/origin/master

列出分支机构时。

但是，当我输入命令git remote -v时，我得到：

origin  <URL>(fetch)
origin  <URL>(push)
sprint-01    <URL>(fetch)
sprint-01    <URL>(push)

我想要以通常的方式但又要远程获得另一个分支：

主遥控器/起源/主遥控器/起源/ sprint-01

我目前正在深入学习git教程，但我们将在星期二开始冲刺，即使当时我在文档中找不到答案，也希望能够毫无问题地加入工作流程。 谢谢堆栈社区。

Answer 1

TL; DR摘要

提交的不同的GIT中存储库之间共享（通过复制）。 分支 不共享：当您运行git fetch ，您的Git会询问其他Git有关其分支的信息，然后您的Git会创建远程跟踪名称（例如origin/master以记住其分支。 这对您的分支机构没有影响！

您还可以运行git push ，让您的Git调用其Git并要求他们创建或更新其分支，这再次对您的分支没有影响。 但是，成功的git push可以使您的Git更新您的 Git的远程跟踪名称，因为您的Git的远程跟踪名称会记住其 Git分支的位置。

你做了什么

您已经创建了一个新的遥控器 。 远程是您的Git记住一些其他的Git URL的方式，并与一起，记住一些或全部-另Git's分支，至少，作为最后一次使用Git的交谈，他们的Git 。

默认情况下， git remote add要求您的 Git以某种名称记录其他Git的URL。 这就是默认情况下要做的所有事情，因此：

git remote add them <url>

只是让您的Git记住<url>在them的名称下，以便您以后可以运行git fetch them或git push them而不必再次输入长网址。

添加-t告诉您的Git，它不仅应该记录URL，而且还应该更改Git将来与他们的Git交谈的方式。 通常，您的Git会调用他们的Git，并让他们列出所有分支，然后将所有这些名称复制到您的远程跟踪名称中。 也就是说，之后：

git remote add sprint-01 <url> -t master

（您可以像前面那样，将-t更向前移动），Git对其Git进行的下一个 git fetch调用将如下所示：

• 您的向导：嗨， them ，您有哪些分支？
• 他们的建议 ：我有master ， dev和feature-123 。
• 您的GIT：我不在乎dev和feature-123 ，但是请给我您拥有的我不知道的所有master承诺。
• 插入有关散列ID的冗长对话-现在您的Git知道其master散列ID，一切都通过散列ID进行。 一旦您的Git知道了您没有的哈希ID，您的Git就会将它们发送给您所有提交和所有必要的文件，依此类推。
• 最后，在Git拥有所需的提交之后，Git会创建sprint-01/master来记住其master 。

请注意，在此过程中， 您的 Git从未要求其 Git创建任何分支。 同样，您的Git也没有创建任何分支：在上述git fetch对话结束时，您的Git创建了sprint-01/master 。 （这东西的全名是refs/remotes/sprint-01/master 。）这是您的Git记住其Git master 。 您的Git会将sprint-01/贴在前面，以便记住它来自名为sprint-01的遥控器 ： sprint-01是您用来记住其Git的URL的名称。

你想做什么

您可能已经有了一个遥控器，可以记住另一个Git的URL。 该遥控器的名称为origin 。

您想让您的Git呼叫他们的Git并开始一个截然不同的对话：

• 您的GIT：嗨origin ，我希望你能创建一个名为新的分支sprint-01 。 使其指向（某些特定的提交哈希ID） 。

• 他们的建议：好的，完成了。

• 您的手指头： “ kthxbye！

• 现在，您的Git知道他们的Git创建了sprint-01 ，并且知道您的Git要求他们使用哪个提交哈希ID，您的Git在您的存储库中创建了远程跟踪名称origin/sprint-01 。

这里最棘手的部分是短语“ 某些特定的提交哈希ID” 。 您将从哪里获得此哈希ID？ Git唯一可以使用的哈希ID是您自己的存储库中某些提交的哈希ID 。

通常情况下，你选择的提交哈希ID的方法是通过在你的仓库，你有提交看看，并选择其中一个作为正确提交， 他们也应该为他们使用sprint-01 。 例如，您可以使用git log查找该提交。

然后，使用该提交哈希ID创建自己的分支 ：

git branch sprint-01 <hash>

要么：

git checkout -b sprint-01 <hash>

如果由于需要新的提交而没有合适的提交，则首先根据一些现有的提交哈希ID创建自己的sprint-01 ：

git checkout -b sprint-01 <existing-hash>

然后为自己的新承诺是合适的，在作出任何承诺的常用方法。

然后，在任何情况下，你现在有，在你的Git，一个分支命名为sprint-01指向所需提交的哈希ID。 这可能是他们可能已经拥有的某些现有提交，也可能是您刚刚创建的一些新提交，其父哈希ID是他们可能已经具有的某些现有提交。 您现在可以简单地运行：

git push origin sprint-01

让您的Git调用他们的Git，如有必要，向他们提供新的提交，然后要求他们的 Git创建他们的 sprint-01分支，指向您使用的同一提交哈希ID 。

术语：或者， 跟踪是一个严重重载的动词

他正在为sprint创建一个远程分支，跟踪母版（因此sprint-01（远程）跟踪母版）...

如前所述，这不太有意义。

Git的术语有问题。 我用过短语远程跟踪名称来描述诸如refs/remotes/origin/master （或简称origin/master ）之类的字符串。 远程跟踪名称是您的 Git存储库中的名称，其目的是记住存储在其 Git 分支名称下的哈希ID。 Git将此称为远程跟踪分支 ，但实际上不是分支，因为您无法像真正的分支那样继续使用它：

$ git checkout origin/master
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. ...

请注意此处有关“分离头”的一些令人毛骨悚然的内容。 这实际上意味着： 您现在不在任何分支上。 运行git status将向您显示HEAD detached at ... 。 但：

$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

现在git status将on branch master 。

一个分支，那么，是你可以得到 ，通过运行git checkout branch-name 。 您无法“获得”诸如origin/master类的远程跟踪名称，因此我们不应该将其称为分支 。 较长的短语“远程跟踪分支”中带有单词“ branch”，因此它不是一个好短语。 （但是Git使用它，因此请记住，即使其中包含“分支”一词，“远程跟踪分支”也不是分支 ！）

现在，可以将分支（但不是远程跟踪名称 ）设置为具有现代Git所谓的上游 。 每个分支机构只能有一个上游。 要设置某些现有分支的上游，请运行：

git branch --set-upstream-to=<upstream> <branch>

通常，分支master的上游是origin/master 。 dev或develop的上游将是您的origin/dev或origin/develop 。 此处的模式很清楚：通常，您希望（本地）分支X的上游成为（您的）远程跟踪名称origin/ X

要使其分支没有上游，请运行：

git branch --unset-upstream <branch>

--unset-upstream从来没有必要 ，但是有时您可能想要--unset-upstream 。 请参阅为什么调用git branch --unset-upstream进行修复？

当像master这样的分支将origin/master设置为其上游时，Git表示master正在跟踪 origin/master 。 请注意，此跟踪动词适用于本地分支名称。 您也可以将一个（本地）分支的上游设置为另一个本地分支：

git branch foo                           # create a new local branch named foo
git branch --set-upstream-to=master foo  # set its upstream to master

您不能将上游设置为远程跟踪名称：

$ git status
On branch master
Your branch is up to date with 'origin/master'.
$ git branch --set-upstream-to=master origin/master
fatal: branch 'origin/master' does not exist

这是正确的： 分支 origin/master节点不存在； 仅存在远程跟踪名称 origin/master 。 ¹这意味着在将动词轨道用于分支的意义上，远程跟踪名称无法跟踪任何内容！ 即使这是一个远程跟踪名称也是如此：作为远程跟踪名称，它会在您运行git fetch时根据您的Git从其他Git中学到的内容自动更新 。

同样的动词轨道也适用于文件：某些文件被跟踪而另一些未跟踪 。 这种特殊的跟踪与分支无关！ 当且仅当文件在Git的索引中时，才会跟踪文件。 索引非常重要，但与分支名称和远程跟踪名称无关，因此我在这里只说您可以随时将文件放入索引或从中取出文件，这意味着是否您可以控制某些文件的跟踪 ； 当您运行git commit时，这将产生至关重要的后果，因为git commit 从索引而不是从工作树进行新的提交。

现在我们知道对于一个分支， tracking意味着有一个上游set ，让我们再次看一下：

（因此sprint-01（远程）跟踪母版）

如果sprint-01是本地分支，则它可以跟踪另一个名称，例如master ，但是如果sprint-01是远程跟踪名称，则它不能跟踪任何其他名称。

如果您的意思是，当您登录到远程服务器并通过cd转到该存储库时， 该存储库具有一个名为master的（本地）分支， 那么该存储库的（本地） sprint-01当然可以跟踪该存储库中的任何其他名称，但是该存储库的分支是它们的 。 他们的Git不能控制您存储库中的分支名称，并且Git甚至看不到那里的任何上游集！ 因此， 该声明（即origin的sprint-01是在origin上设置的，以便它可以跟踪origin的master文件）可能是正确的，但与您的 Git完全无关。

---

¹从技术上讲，分支是其全名以refs/heads/开头的任何引用。 远程跟踪名称是其全名以refs/remotes/开头的任何引用。 Git通常会剥离refs/heads/和refs/remotes/部件以显示，尽管有时（例如在git branch -a输出中）它仅从远程跟踪名称中剥离refs/ 。 一些Git命令（例如git for-each-ref默认显示完整的引用名称； 通常，只有整个名称的所谓管道命令。

---

结论

在处理Git时，请始终记住：

• 存储库中保存提交 。 每次提交都保存文件，因此最后，存储库也保存文件，但是一次执行一次提交。 每个提交都有一个唯一的哈希ID。

• 几乎总是有多个存储库。

• 将两个存储库相互连接时，它们通过哈希ID共享提交。 发送Git和接收Git进行交谈并交换哈希ID，以查看谁拥有什么以及谁需要什么。 然后，发送方将提交 （不是文件，而是整个提交）发送给接收方。 现在，发送者和接收者通过哈希ID具有相同的提交 。

• 如果您使用的是git push ，则您是发送者，而他们是接收者。 最后，您的Git会礼貌地问他们的Git一个问题： 如果愿意，请为某些特定的提交哈希ID设置一些分支和/或标记名称？ 或像git push --force一样命令它们： 将这些分支和/或标记名称设置为这些哈希ID！ 哈希ID来自您的 Git，并在必要时与您的Git刚共享的提交相对应（如果它们还没有的话）。

  他们可以拒绝！ 如果有礼貌的请求会因设置分支名称而丢失某些提交，则将被拒绝。 根据控件和权限，是否遵守命令-默认是始终遵循命令，但是Web托管服务现在总是提供控件。

  如果他们服从请求或命令，您的Git将更新您的远程跟踪名称。 （您的Git不知道它们已更新或未更新的任何其他名称，因此您的Git仅更新您设置了它们的分支名称的远程跟踪名称。）

• 如果您使用git fetch ，则您的Git是接收者。 在大多数情况下，您将获得其所有分支名称，然后Git会更新所有远程跟踪名称。 但是，您可以故意限制您的Git询问其Git的名称。 例如：

   git fetch origin master 

  请您的Git叫他们的Git并只问他们关于他们master 。 您会收到他们没有的任何新提交，然后您的Git仅更新您自己的origin/master -您没有选择其他分支来查看，因此您的Git没有。

  您还可以在任何遥控器上设置单分支模式 。 这是与-t使用时git remote add所做的事情。 在这种模式下，您的git fetch 自动仅询问您列出的一个分支。 这很少有什么用处：它主要用于处理大型活动库，而您仅在其中查看或贡献一小部分（一个分支），因此您无需关心大多数远程站点中的所有活动。 。 您可以为小型且活动较少的存储库执行此操作，但是除非您拥有9600波特的Internet连接，否则不会为您节省足够的时间。

• git pull意味着运行git fetch ，然后运行第二个Git命令 。 git fetch是所有远程存储库获取我的提交的地方。 这也会更新您的origin/master或其他。 第二个 Git命令很有用， 因为 git fetch不会触及您的分支。 通常情况下，你已经获取了新的后master承诺，你也想更新您的 master 。

  其中的一些问题在这里，虽然，你是怎么想更新你的master 。 您要使用git merge更新它，还是要使用git rebase更新它？ 如果您事先确定要使用哪个命令，则可以运行git pull ： git pull --rebase将运行git rebase ，而没有--rebase git pull将运行git merge ，作为第二个命令。 然后您就完成了，一个git pull比第二个Git命令的git fetch更方便。

  但是，如果你不知道自己究竟想要做 git merge或git rebase或者是别的东西完全，然后git pull是一个陷阱。 我喜欢做的是运行git fetch ，然后检查什么，我刚拿到 ， 然后才决定做什么。 git pull命令使您可以决定要做什么，然后才能看到所得到的。 因此，我通常会避免这种情况，但是就我而言，就是我，这可能与您的情况有所不同。

  （在非常老的Git版本中，分别在1.5和1.6天内， git pull也因意外破坏您的工作而享有当之无愧的声誉。我自己丢失了一些工作来进行git pull bug。）