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

EN

TL; DR摘要

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

你也可以运行git push，让你的Git调用他们的Git并要求他们创建或更新他们的分支，这对你的分支机构也没有影响。但是，成功git push让你的Git更新你的 Git的远程跟踪名称，因为你的Git的远程跟踪名称记住了他们的 Git分支的去向。

你做了什么

您已经创建了一个新的遥控器。遥控器是你的Git记住其他Git的URL的一种方式，并且与此同时，要记住他们的其他Git分支的部分或全部，至少，就像你Git最后一次与他们的Git交谈一样。

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

git remote add them <url>

只是让你的Git记住<url>名字them，这样你就可以 - 以后 - 运行git fetch them或git push them不必再次输入一个长URL。

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

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

（你可以像往常一样将-t更多的东西拖到前面），你的Git对他们的Git 的下一个 git fetch调用会是这样的：

• 你的GIT：嗨them，你有什么分支？
• 及其GIT：我有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）。
• 他们的GIT：好的，完成了。
• 你的GIT： '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>

如果因为您需要新的提交而没有提交是合适的，那么首先sprint-01从一些现有的提交哈希ID 创建自己的提交：

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

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

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

git push origin sprint-01

让你的Git调用他们的Git，在必要时为他们提供新的提交，然后让他们的 Git创建他们的 sprint-01分支，指向你使用的相同的提交哈希ID。

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

他正在为短跑创建一个远程分支，跟踪主人（所以sprint-01（远程）跟踪主人）...

如上所述，这没有多大意义。

Git的术语有问题。我使用短语远程跟踪名称来描述字符串refs/remotes/origin/master（或origin/master简称）。一个远程跟踪名称是一个名称的 Git仓库，其目的是要记住下存储的散列ID 的 Git的分支名称。Git的调用这个远程跟踪分支，但它实际上并不是一个分支，因为你不能得到关于它的方式，你可以真正的分支：

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

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

请注意这里有关“分离的HEAD”的有点可怕的东西。所有这一切的意思是：你现在不在任何一个分支上。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使用它，所以请记住，“远程跟踪分支”不是分支，即使它中有“分支”一词！）git checkout branch-nameorigin/master

现在，分支 - 但不是远程跟踪名称 - 可以设置为现代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，但有时你可能想。请参阅为什么调用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。1 这意味着远程跟踪名称无法跟踪任何内容，在动词跟踪用于分支的意义上！这是正确的，即使它是一个远程跟踪名称：作为远程跟踪名称，它只是在你运行时根据你从其他Git学到的东西自动更新git fetch。

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

现在我们知道跟踪，对于一个分支，意味着有一个上游集，让我们再看一遍：

（所以sprint-01（远程）跟踪主人）

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

如果你的意思是，当你登录到远程和cd该存储库时，该存储库有一个名为的（本地）分支master，那个存储库（本地）sprint-01当然可以跟踪该存储库中的任何其他名称 - 但该存储库的分支是他们的。。他们的Git不控制您的存储库中的分支名称，并且您的Git 甚至都看不到任何上游集合！所以这个语句是origin的sprint-01设置上origin，以便它跟踪origin的master-could是真实的，但将是完全无关的 Git的。

1从技术上讲，分支是全名以其开头的任何引用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没有。 您还可以在任何遥控器上设置单分支模式。这git remote add与使用时的情况有关-t。在此模式下，您只会git fetch 自动询问您列出的一个分支。这很少有用：它主要用于处理巨大的，高度活跃的存储库，您只需查看或贡献一小部分（一个分支），因此您不关心大多数远程服务器中的所有活动。您可以为小型和不太活跃的存储库执行此操作，但除非您拥有9600波特的互联网连接，否则它将无法为您节省足够的时间。
• git pull只是意味着运行git fetch，然后运行第二个Git命令。这git fetch是所有远程存储库get-me-their-commits发生的地方。这也更新了你origin/master或者其他什么。在第二 Git的命令非常有用，因为 git fetch不碰你的分支。通常情况下，你已经获取之后他们新master提交，你也想更新您的 master。 其中的一些问题在这里，虽然是怎样你要更新master。您想要更新它git merge，还是想要更新它git rebase？如果你知道，对于某些，提前，这要使用命令，你可以运行git pull：git pull --rebase将运行git rebase并git pull没有--rebase运行git merge，作为第二个命令。然后你就完成了，一个git pull比git fetch第二个Git命令更方便。 但如果你不确定自己是否想要或者完全不知道其他东西，那么就是陷阱。我喜欢做的就是运行，然后检查什么，我刚刚得到的，只有再决定怎么做。该命令可让您决定要做什么，然后才能看到所得到的内容。所以我通常会避免它 - 但在我看来，这就是我，这可能与你的不同。git mergegit rebasegit pullgit fetchgit pull （在非常古老的Git版本中，在1.5和1.6天之内，git pull因意外破坏你的工作而享有当之无愧的声誉。我git pull自己也失去了一些工作。）