use*_*592 10 git branch github
简而言之，GitHub 建议使用main而不是master默认分支。
我们怎样才能得到这个名字来编写弹性的 Git 别名呢？如何获取 Git 中“master”分支的默认值？
我已经搜索过了，但是git 中没有任何解决方案 - 如何获取默认分支？对我来说可靠地工作...
如果我在分支feature，从 分叉develop，它会返回我develop而不是master（或者main，从develop分叉 ）...
那么如何获得“master”分支名称呢？
注意 -问题可能是：为什么git remote show origin不向我展示master，而是develop作为HEAD branch？
tor*_*rek 12
你提到mainvs master。现在，这里的第一个问题是目前实际上没有任何默认分支。有点是，但没有保证可以查询它，因为“有点”部分是因为对此还没有达成共识：不是每个人都安装了 Git 版本 2.28 或更高版本。
也就是说，运行：
\ngit config --get init.defaultBranch\n可能会在您自己的 Git 存储库中生成某些内容，如果确实如此，并且您的 Git 是 2.28 或更高版本，则您的Git 将在运行时使用它作为未生成分支的默认名称git init。（另请参阅提交 8747ebb7cde9e90d20794c06e6806f75cd540142。）
请注意，如果有人运行：
\ngit init --initial-branch=xyzzy\n要创建一个新的空存储库，这个新的空存储库中未诞生的分支的名称将为xyzzy，无论是否有init.defaultBranch设置，也无论其中可能有什么。该--initial-branch选项也首次出现在 Git 2.28 中。
您还问过关于git 的答案 - 如何获取默认分支？:
\n\n\n问题可能是：为什么
\ngit remote show origin不向我展示master，而是develop作为HEAD branch？
该git remote show命令以及该git ls-remote命令（尝试一下）的工作原理是调用其他一些Git存储库并从中获取信息。在我们讨论此信息之前，让我们看一下HEAD在您的存储库中如何工作。
Git 存储库的核心是提交的集合。每个提交都使用唯一的哈希 ID进行编号。各地的所有 Git 系统都使用特定的算法\xe2\x80\x94，当前为 SHA-1，但计划切换到 SHA-256\xe2\x80\x94，以根据提交的内容计算提交的哈希 ID，这样所有 Git 系统都会为相同的提交提供相同的哈希 ID 。
\n这就是 Git 分发提交的工作原理。每个存储库都有自己的提交的完整集合。当您交叉连接一对Git 存储库（例如您自己的存储库和您的 Git 调用的系统上的一个）时origin，它们会交换哈希 ID。由于哈希 ID 唯一标识提交，因此发送者可以列出哈希 ID，接收者可以立即判断他是否拥有该提交，或者需要该提交。添加一些基于提交图结构的优化，我们就拥有了 have/want 协议交换所需的大部分内容。
不过，每个 Git 都使用名称在自己的存储库中查找提交：分支名称、标签名称和其他此类名称。它们带有哈希 ID，可以找到一些特定的提交。然后，这些提交也会找到任何较早的提交。
\n为了发送提交，发送的 Git 会成对git fetch列出他的分支和标签以及其他此类名称，以便接收的 Git 可以找出要请求的提交（如果有）。您可以使用 列出您自己的名称\xe2\x80\x94全部或某些选定的子集\xe2\x80\x94 git for-each-ref。默认是列出所有以 开头的名称refs/。
上图中少了一块，那就是特殊的名字HEAD。这个特殊的名称 \xe2\x80\x94 它并不是以 \xe2\x80\x94 开头refs/，Git 在内部以各种特殊方式在各处使用它 \xe2\x80\x94 通常是 Git 所说的符号 ref，我们可以使用以下方式读取它git symbolic-ref：
git config --get init.defaultBranch\n这告诉我们，在这个特定的 Git 存储库中，当前分支是名为master. （分支名称全部以 开头refs/heads/；其他名称以 otherrefs/基于前缀开头。）在非裸 Git 存储库\xe2\x80\x94（我们通常使用的那种）\xe2\x80\x94 中，这意味着有人运行了git checkout master或git switch master.
当我们git ls-remote连接到其他 Git 时，他们的Git 会为我们运行git for-each-ref，列出他们的名字。但他们在列表前加上 中的值HEAD，如果我们添加选项1--symref，我们可以通过两种方式获得它们：HEAD
ref: refs/heads/master HEAD\n72c4083ddf91b489b7b7b812df67ee8842177d98 HEAD\n71ca53e8125e36efbda17293c50027d31681a41f refs/heads/maint\n72c4083ddf91b489b7b7b812df67ee8842177d98 refs/heads/master\na3ce27912f980d787926b113d17f1f532e50162a refs/heads/next\n[snip]\n所以这告诉我他们的Git 存储库已经master作为他们的HEAD. 第一个输出行直接说明了这一点；接下来的几行告诉我，theirHEAD和theirrefs/heads/master都引用commit 72c4083ddf91b489b7b7b812df67ee8842177d98，这是不太直接的。2
该git remote show命令能够调用其他 Git。3 这意味着他们可以让他们列出自己的分支HEAD。当你看到：
HEAD branch: develop\n这仅仅意味着他们的 Git 已HEAD附加到他们的分支名称develop。如果他们的存储库是非裸露的，这意味着他们运行了git checkout develop或git switch develop.
如果他们有一个裸git --work-tree=... checkout存储库，他们仍然可以通过直接运行使用、 或GIT_WORK_TREE=... git checkout、 或 来获得相同的效果git symbolic-ref。their 附加的分支名称HEAD不一定是 theirmaster或 their main，如果它们有的话：它们控制哪个分支名称（如果有）存储在 your 中HEAD。
这没有什么意义。如果他们HEAD命名为“他们” develop，那就意味着“他们”HEAD依附于“他们” develop。由于他们的分支名称是他们的\xe2\x80\x94而不是你的\xe2\x80\x94，这对你来说应该不重要。
不过，有一个地方确实很重要。如果你运行：
\ngit clone <url>\n而不是说：
\ngit clone -b somebranch <url>\n那么你要求你的 Git 调用他们的 Git 并询问他们推荐哪个分支名称。当您供货时，您就是在选择分支机构；如果你不这样做，你就是在告诉你的 Git 遵循他们的建议。推荐的分支名称是它们所附加的名称。因此，他们\xe2\x80\x94无论他们是谁，控制另一个Git存储库\xe2\x80\x94都应该使用他们拥有的任何手段将他们连接到他们个人推荐的分支名称。-b branchHEAD HEAD
您无需遵循他们的建议。您的克隆中包含您的分支名称。您不需要使用与他们所使用的相同的名称。这取决于你。大多数人大多使用相同的名称，以使事情更容易思考。
\n1--symref旧版本的 Git 不支持此选项。当较新的 Git 与无法进行符号引用传输的旧 Git 进行通信时，较新的 Git 必须猜测较旧的 Git 的HEAD. 这是一个有点难看的情况，我们假设您在这里使用的是全新的 Git 版本。
2这向您展示了较早的 Git 可以如何猜测：如果来自的哈希 IDHEAD与一个分支名称完全匹配，则告诉我们这是分支名称。但是，如果来自的哈希 ID 与HEAD两个、三个或更多分支名称哈希 ID 匹配怎么办？这就是情况变得丑陋的地方。
3在现代 Git 中，这是您使用git remote show. 我不确定这是否不是默认设置。不过，该git remote命令有很多子命令，其中许多子命令不需要调用其他 Git。
这本身并没有回答问题，但实际上核心问题是确定存储库是否使用main或master命名标准。因此，大多数情况下我们可以这样做：
git branch | grep -o -m1 "\\b\\(master\\|main\\)\\b"\n-o\xe2\x80\x94 仅打印匹配项-m1\xe2\x80\x94 仅打印第一个匹配项| 归档时间： |
|
| 查看次数： |
3895 次 |
| 最近记录： |