了解.git / config的'remote'和'branch'部分

Question

以下是remote文件的branch和.git/config部分的内容。

[remote "origin"]  
    url = https://EvanAad@bitbucket.org/EvanAad/bitbucketstationlocations.git  
    fetch = +refs/heads/*:refs/remotes/origin/*  
[branch "master"]  
    remote = origin  
    merge = refs/heads/master

这些部分内容的含义和目的是什么，特别是fetch和merge小节？ Git如何使用这些信息来指导其运作？

Answer 1

我认为每个merge部分下的branch条目最不明显。 Git文档让它有点模糊。让我们先介绍其他人。

[remote "..."]部分

下的设置

有许多可能的设置。一般情况下，您不必直接使用git config设置其中任何一个 - 几乎所有这些都具有包装器命令，以便将它们设置为更友好的＆＃34;方式。这包括您在此处看到的两种设置。很难想要改变这些。

每个指定远程用户的remote部分（例如origin）列出了git fetch的网址（以及可选的git push推送网址和其他{{} 1}}配置项为described in the git config documentation）。它还有一个或多个remote.*行，用于从该遥控器提供fetch的默认 refspec 参数。

也就是说，如果你跑：

git fetch

Git会查找git fetch origin 以查看连接位置，然后连接到那里，然后根据所有remote.origin.url条目检索引用。您在此处看到的默认值：

remote.origin.fetch

告诉Git从远程复制所有分支 ¹ ，将它们重命名为+refs/heads/*:refs/remotes/origin/* - 前缀远程跟踪分支 ² 在您自己的存储库中，所以：

origin/

基本上取得了一切。 （领先git fetch origin 表示Git应该这样做，无论远程跟踪分支更新是否是快进操作。也就是说，它就像使用+一样，但不必指定--force。）

另一方面，如果你跑：

--force

Git将完全忽略所有git fetch origin a:b c:d 行，仅从远程检索引用fetch =和a，将其写入引用c和您的存储库中的b。 （因为它既没有d也没有+，所以这些都不会被强制更新 - 尽管在大多数情况下无论如何也没有任何区别。）

^1,2 引用是一个通用术语，涵盖分支和标记（以及更多内容）。像--force这样的分支名称只是以master开头的引用的简写。像refs/heads/这样的远程跟踪分支名称只是以origin/master开头的引用的简写。请注意，refs/remotes/部分来自origin/行 - 但为了使所有这些按照预期的方式工作，该行必须匹配远程的名称方括号。

fetch =部分

下的设置

有许多可能的设置。一般情况下，您不必直接使用[branch "..."]设置其中任何一个 - 几乎所有这些都具有包装器命令，以便将它们设置为更友好的＆＃34;方式。这包括您在此处看到的两种设置。使用我们稍后会看到的命令，想要改变其中一个或两个并不罕见。

git config部分本身非常清楚：这意味着如果你在分支remote并运行master而没有提供远程名称，Git应该获取来自名为git fetch的遥控器。

origin部分是棘手的。它列出了远程上看到的分支的名称。请注意，当我们运行merge时，我们告诉我们的Git调用另一个Git，找到其他 Git的git fetch origin，并将其复制到我们的存储库但是调用它master。但是...... origin/master行说merge。不应该说：merge = refs/heads/master？

它可能应该 - 但这个设置首先是遥控器的发明之前。所以它没有;相反，它会列出远程上显示的参考的全名。

如果您运行merge = refs/remotes/origin/master或git merge而未提供合并或重新绑定的分支名称，则会使用此设置。 Git通过远程git rebase行提供的映射运行名称，以确定它应该与fetch =合并。

origin/master方便命令也使用此设置，该命令实际上是 ³ ，与运行git pull后运行git fetch相同。

您可能希望更改其中一个或两个。例如，如果您创建新的本地分支git merge，则可能根本没有否 feature/tall和branch.feature/tall.remote设置。

由于您刚刚创建了此分支，因此没有branch.feature/tall.merge。 origin/feature/tall处的Git还没有origin，所以你没有它的副本。

然后你feature/tall让你的Git打电话给git push origin feature/tall:feature/tall的Git并让他们的Git 创建该分支，这样你现在做有origin。你可能希望你的Git记住这一点。

您可以运行两个origin/feature/tall命令，但您可以运行一个更高级别的包装器命令：

git config

这会告诉您的Git将git branch --set-upstream-to=origin/feature/tall feature/tall 设置为branch.feature/tall.remote，将origin设置为branch.feature/tall.merge（这是refs/heads/feature/tall上的名称）。

您可以使用origin组合git push和git branch --set-upstream-to步骤，这样做会更好，但这里的要点仍然是：您使用包装器来获取两者值一次设置，因为只设置一个值没有用。 ⁴

³ 这故意掩盖了很多细节。

⁴ 仅设置git push -u部分确实会影响未来remote，但git push和git merge赢了＆ ＃39;能够在没有两个条目的情况下进行远程跟踪分支映射。

Answer 2

它被称为refspec。 它是git用来与远程服务器“对话”并将本地分支映射到远程分支的机制。

Refspecs

refspec将本地存储库中的分支映射到远程存储库中的分支。
这使得可以使用本地Git命令管理远程分支，并配置一些高级git push和git fetch行为。

refspec指定为[+]<src>:<dst>。 <src>参数是本地存储库中的源分支，<dst>参数是远程存储库中的目标分支。
可选的+符号用于强制远程存储库执行非快进更新。

Refspecs可以与git push命令一起使用，为远程分支提供不同的名称。例如，以下命令将master分支推送到原始远程repo，就像普通git push一样，但它使用qa-master作为origin repo中分支的名称。这对于需要将自己的分支机构推送到远程仓库的QA团队非常有用。

git push origin master:refs/heads/qa-master

通过在Git配置文件中添加几行，您可以使用refspecs来改变git fetch的行为。

默认情况下，git fetch将获取远程存储库中的所有分支。原因是.git/config文件的以下部分：

[remote "origin"]
    url = https://git@github.com:mary/example-repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*

fetch行告诉git fetch从原始仓库下载所有分支。
但是，一些工作流程并不需要所有这些工作流程。例如，许多持续集成工作流只关心主分支。要仅获取主分支，请更改获取行以匹配以下内容：

[remote "origin"]
    url = https://git@github.com:mary/example-repo.git
    fetch = +refs/heads/master:refs/remotes/origin/master

您也可以以类似的方式配置git push。例如，如果您想始终将主分支推送到原始远程的qa-master（如上所述），您可以将配置文件更改为：

[remote "origin"]
    url = https://git@github.com:mary/example-repo.git
    fetch = +refs/heads/master:refs/remotes/origin/master
    push = refs/heads/master:refs/heads/qa-master

Refspecs让您完全控制各种Git命令如何在存储库之间传输分支。

他们允许您重命名和删除分支从本地存储库fetch/push到具有不同名称的分支，并配置git push和git fetch以使用只有你想要的分支。