如何在Git中获取master分支的默认值? [英] How to get the default for the master branch in Git?

问题描述

简短地说，GitHub建议使用 main 而不是 master 作为默认分支.

Since short, GitHub proposes to use main instead of master for the default branch.

如何为编写有弹性的Git别名获得该名称?如何获得主"服务器的默认值?在Git中分支?

How can we get that name, for writing resilient Git aliases? How to get the default for the "master" branch in Git?

我已经搜索过SO，但是 git-如何获取默认分支?对我来说可靠吗...

I've searched on SO, but none of the solutions in git - how to get default branch? does work reliably for me...

如果我在 feature 分支中，是从 develop 分叉的，它将返回我 develop 而不是 master (或 main ， develop 是其中的一个分支)...

If I'm in branch feature, forked from develop, it will return me develop and not master (or main, from which develop is a fork)...

如何获取该主人"分支名称呢?

How to get that "master" branch name, then?

注意-问题可能是:为什么 git remote show origin 不向我显示 master ，而向我显示 develop ，而不是 HEAD分支?

NOTE -- The question could be: why is git remote show origin not showing me master, but develop instead, as the HEAD branch?

推荐答案

回答问题有两个问题

您提到了 main 与 master .现在，这里的第一个问题是，目前实际上没有任何 default 分支.有种，但是没有保证的查询方式，因为部分原因是因为尚未达成共识:并非每个人都安装了Git 2.28或更高版本.

There are two problems with answering your question

You mention main vs master. Now, the first problem here is that there isn't really any default branch at the moment. There sort of is, but there's no guaranteed way to query it, because the "sort of" part is because there's no common agreement on this yet: not everyone has Git version 2.28 or later installed.

也就是说，正在运行:

git config --get init.defaultBranch

可能会在您自己的Git存储库中生成某些内容，如果它确实 ，并且如果您的Git为2.28或更高版本，则您的 Git将使用在运行 git init 时，将其作为未出生分支的默认名称.(另请参见提交8747ebb7cde9e90d20794c06e6806f75cd540142 .)

may produce something in your own Git repository, and if it does and if your Git is 2.28 or later, your Git will use that as the default name for the unborn branch when running git init. (See also commit 8747ebb7cde9e90d20794c06e6806f75cd540142.)

请注意，如果有人跑步:

Note that if someone runs:

git init --initial-branch=xyzzy

创建一个新的空存储库，这个新的空存储库中未出生分支的名称将为 xyzzy ，而不管是否存在 init.defaultBranch 设置，而不管其中可能包含什么内容.-initial-branch 选项也首先出现在Git 2.28中.

to create a new, empty repository, the name of the unborn branch in this new, empty repository will be xyzzy, regardless of whether there is an init.defaultBranch setting, and regardless of what might be in it. The --initial-branch option also first appears in Git 2.28.

您还询问了有关 git-如何获取默认分支的答案?:

问题可能是:为什么 git remote show origin 不向我显示 master ，而是向 develop 显示，作为 HEAD分支?

The question could be: why is git remote show origin not showing me master, but develop instead, as the HEAD branch?

git remote show 命令和 git ls-remote 命令(尝试)，通过调用一些 other Git存储库来工作并从中获取信息.在讨论这些信息之前，让我们看一下 HEAD 在您的存储库中的工作方式.

The git remote show command, and the git ls-remote command (try it), work by calling up some other Git repository and getting information from it. Before we discuss this information, let's take a look at how HEAD works in your repository.

Git存储库的核心是 commits 的集合.每个提交都用唯一的哈希ID 编号.各地的所有Git系统都使用特定的算法(当前为SHA-1，但计划切换到SHA-256)以根据提交的内容计算提交的哈希ID，以便所有Git系统都可以使用<相同提交的em>相同哈希ID.

A Git repository is, at its heart, a collection of commits. Each commit is numbered with a unique hash ID. All Git systems everywhere use a particular algorithm—currently SHA-1, but there are plans to switch to SHA-256—to compute the hash ID of a commit based on the commit's content, so that all Git systems will come up with the same hash ID for the same commit.

这就是Git在分配提交方面的工作方式.每个存储库都有其自己提交的完整集合.当您交叉连接一个对的Git存储库(例如您自己的存储库和一个在系统上的Git存储库)时，您的Git会调用 origin ，它们会交换哈希ID >.由于哈希ID唯一地标识提交，因此发送方可以列出哈希ID，而接收方可以立即从中得知他是否已提交或需要提交.添加基于提交图结构的一些优化，我们就可以拥有拥有/想要的协议交换.

This is how Git works in term of distributing commits. Each repository has a full collection of its own commits. When you cross-connect a pair of Git repositories, such as your own and one over on a system your Git calls origin, they exchange hash IDs. Since the hash IDs uniquely identify the commits, the sender can list a hash ID, and the receiver can immediately tell from that whether he has the commit, or needs the commit. Add in some optimizations based on the commit graph structure and we have most of what we need for the have/want protocol exchange.

每个Git，查找使用其名称在其自己的存储库中提交:分支名称，标记名称和其他此类名称.这些带有哈希ID，可以找到一些特定的提交.然后，这些提交也可以找到任何更早的提交.

Each Git, though, finds commits in its own repository using names: branch names, tag names, and other such names. These come with hash IDs, which find some particular commit. Those commits then find any earlier commits as well.

出于发送提交的目的，在 git fetch 对中的发送Git列出了他的分支和标签以及其他此类名称，以便接收Git可以找出要询问的提交对于，如果有的话.您可以使用 git for-each-ref 列出自己的名称(全部或某些选定的子集).默认值为列出所有以 refs/开头的名称.

For the purpose of sending commits, the sending Git in a git fetch pair-up lists out his branch and tag and other such names, so that the receiving Git can figure out which commits to ask for, if any. You can list out your own names—all of them or some selected subset—using git for-each-ref. The default is to list all names that start with refs/.

上图缺少一幅，这就是特殊名称 HEAD .这个特殊名称-它不是以 refs/开头的，而Git在内部以各种特殊方式在整个地方使用它-通常是Git称为 symbolic ref 的符号，我们可以使用 git symbolic-ref 来阅读它:

There is one piece missing from the above picture, and that's the special name HEAD. This special name—it doesn't start with refs/ and Git uses it internally all over the place in various special ways—is normally what Git calls a symbolic ref, and we can read it with git symbolic-ref:

$ git symbolic-ref HEAD
refs/heads/master

这告诉我们，在这个特定的Git存储库中，当前分支是一个名为 master 的分支.(分支名称均以 refs/heads/开头；其他名称以其他基于 refs/的前缀开头.)在非裸露的Git存储库中，这是我们通常使用的那种使用-这意味着某人已运行 git checkout master 或 git switch master .

This tells us that in this particular Git repository, the current branch is the one named master. (Branch names all start with refs/heads/; other names start with other refs/-based prefixes.) In a non-bare Git repository—the kind that we normally work with—this means someone has run git checkout master or git switch master.

当我们使用 git ls-remote 连接到其他Git时，其 Git将为我们运行 git for-each-ref ，以列出他们的名称.但是他们以 HEAD 中的值作为列表的前缀，如果我们添加-symref 选项， ¹ ，我们将获得其 HEAD有两种方式:

When we use git ls-remote to connect to some other Git, their Git will run git for-each-ref for us, to list out their names. But they prefix their list with the value in HEAD, and if we add the --symref option,¹ we get their HEAD in two ways:

ref: refs/heads/master  HEAD
72c4083ddf91b489b7b7b812df67ee8842177d98        HEAD
71ca53e8125e36efbda17293c50027d31681a41f        refs/heads/maint
72c4083ddf91b489b7b7b812df67ee8842177d98        refs/heads/master
a3ce27912f980d787926b113d17f1f532e50162a        refs/heads/next
[snip]

因此，这告诉我其 Git存储库具有 master 作为其 HEAD .第一条输出线直接将其清楚地表明；接下来的几行告诉我，他们的 HEAD 和 refs/heads/master 均指的是提交 72c4083ddf91b489b7b7b812df67ee8842177d98 ，这不太直接.> 2

So this tells me that their Git repository has master as their HEAD. The first output line makes this clear directly; the next few lines show me that their HEAD and their refs/heads/master both refer to commit 72c4083ddf91b489b7b7b812df67ee8842177d98, which is less direct.²

git remote show 命令具有调用另一个Git的功能. ³ 这意味着他们可以让他们列出作为其的分支.HEAD .当您看到:

The git remote show command has the ability to call up the other Git.³ This means they can have them list out which branch they have as their HEAD. When you see:

  HEAD branch: develop

这仅表示其Git的分支名称 develop 附加了 HEAD .如果他们的存储库是非裸露的，则表示他们运行了 git checkout开发或 git switch开发.

this merely means that their Git has their HEAD attached to their branch name develop. If their repository is non-bare, this means they ran git checkout develop or git switch develop.

如果他们有一个 bare 存储库，则仍然可以使用 git --work-tree = ... checkout 或 GIT_WORK_TREE获得相同的效果= ... git checkout ，或直接运行 git symbolic-ref .其 HEAD 所附加的分支名称不一定是其 master 或其 main (如果有):他们控制哪个分支名称(如果有)存储在其 HEAD 中.

If they have a bare repository, they can still get the same effect, using git --work-tree=... checkout, or GIT_WORK_TREE=... git checkout, or by running git symbolic-ref directly. The branch name to which their HEAD is attached is not necessarily their master or their main, if they have one: they control which branch name, if any, is stored in their HEAD.

对此没有什么意义.如果他们的 HEAD 命名为他们的 develop ，那仅意味着他们的 HEAD 被附加到他们的 develop 上.由于它们的分支名称是它们的 ，而不是您的，所以这对您来说无关紧要.

There is very little significance attached to this. If their HEAD names their develop, that just means that their HEAD is attached to their develop. Since their branch names are theirs—not yours—this shouldn't matter to you.

尽管如此，在一个重要的地方.如果您运行:

There is one place where it does matter, though. If you run:

git clone <url>

而不是说:

git clone -b somebranch <url>

然后，您要让Git调用其Git并询问他们推荐的分支名称.当提供 -b 分支 时，您正在选择分支.如果您不这样做，则是在告诉您的Git遵循他们的建议.推荐的分支名称是其 HEAD 所附加的名称.因此，无论他们处于什么位置，只要能控制此其他Git存储库， 都应使用自己可以使用的任何方式将其 HEAD 连接到他们个人推荐的分支名称.

then you're asking your Git to call up their Git and ask them which branch name they recommend. When you supply -b branch, you're choosing the branch; when you don't, you're telling your Git to follow their recommendation. The recommended branch name is the one to which their HEAD is attached. So they—whoever they are, in control of this other Git repository—should use whatever means they have at their disposal to connect their HEAD to the branch name they personally recommend.

您无需遵循他们的建议.您的克隆中有您的分支名称.您不需要使用相同的名称.这取决于你.大多数人做大多使用相同的名称，以使事情更容易思考.

There's no need for you to follow their recommendations. Your clone has your branch names in it. You do not need to use the same names they are using. That's up to you. Most people do mostly use the same names, to make things easier to think about.

¹ 较早版本的Git不支持此-symref 选项.当较新的Git与无法进行符号引用传输的旧Git进行通信时，较新的Git必须猜测有关较旧的Git的 HEAD .这是一个有点丑陋的情况，我们仅假设您在这里使用的是更新的Git版本.

¹This --symref option is not supported in older versions of Git. When a newer Git is talking to an old Git that can't do symbolic ref transfers, the newer Git has to guess about the older Git's HEAD. This is a somewhat ugly situation and we will just assume that you're using all-newer-Git-versions here.

² 这向您展示了老版本的Gits如何猜测::如果 HEAD 中的哈希ID恰好与一个分支名称匹配，这告诉我们这是分支名称.但是，如果 HEAD 中的哈希ID匹配两个或三个或更多分支名称哈希ID，该怎么办?那里的情况变得丑陋.

²This shows you how older Gits can guess: if the hash ID from HEAD matches exactly one branch name, that tells us that this is the branch name. But what if the hash ID from HEAD matches two, or three, or more, branch name hash IDs? That's where the situation becomes ugly.

³ 在现代Git中，这是使用 git remote show 的默认方式.我不确定这是否不是默认设置.尽管 git remote 命令有很多子命令，但许多子命令不会打扰其他Git.

³In modern Git, that's the default for the way you are using git remote show. I'm not sure if this was ever not the default. The git remote command has a lot of sub-commands though, and many of them don't bother calling up some other Git.

这篇关于如何在Git中获取master分支的默认值?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！