git跟踪中的切换分支

Question

What does the 'main' setup to track remote branch main from origin mean?

我了解 Origin 是我的远程存储库的 URL

> PC@DESKTOP-R8DI61V MINGW64 ~/Desktop/team6/ch (team1.1) $ git checkout
> main Switched to a new branch 'main' Branch 'main' set up to track
> remote branch 'main' from 'origin'.

另外，当我更改为不同的分支时，请说 team1

并使用git分支，主分支不显示

Answer 1

'main' setup to track remote branch main from origin意味着有一个名称也是 main 的本地分支，它被配置或设置为跟踪远程分支（其名称也是 main 托管在某个地方，例如在 github 中）

每当您对远程分支（主）进行更改时，您的本地主将跟踪这些更改

the main branch does not show 

对于分支机构，我通常使用它

git branch # to show all branch 
git branch -a # to show all branches low and remote 
git checkout branchname # to shift to another branch 

Answer 2

关于你的第二个问题：

...我如何检查分支结构。 例如，如果 Dev 分支是 main 的子分支

分支——或者更准确地说，分支名称——绝不是任何其他分支名称的超分支或子分支。 他们都生活在同一个“水平”上，因为它是：

• 这里的第一个技巧是在 Git 中，分支名称并不重要。 真正重要的是提交本身。 无论哪个分支包含它们，这些提交都存在。

• 第二个技巧——它不会撤消第一个！——是分支名称是我们找到提交的方式。 由于提交很重要，这使得分支名称很重要......但仅在我们需要这些分支名称来查找提交的范围内。

正如Jatin Mehrotra 评论的那样，您可以使用git log --graph （通常带有附加标志）来要求 Git 绘制提交图。 有关此的（更多）更多信息，请参阅Pretty git branch graphs 。 出于 StackOverflow 发布的目的，我喜欢水平绘制图表，每次提交都使用o字符，如下所示：

...--o--o--o   <-- master

或单个大写字母代表每个提交的实际 hash ID。 当您运行git log时，您将看到提交的真实 hash ID。 它们又大又丑，仅靠人类是不可能处理的——你需要一台计算机才能使用 hash ID——这就是为什么在我的图纸中，我使用字母来代替：

... <-F <-G <-H   <-- master

在这里，我们有一串以提交H结尾的提交（ H是 Hash-ID 的缩写）。 Git找到提交H的 hash ID，因为分支名称master持有它。 也就是说，我们可以从字面上问Git： master这个名字代表什么hash ID？

$ git rev-parse master
225365fb5195e804274ab569ac3cc4919451dc7f

所以这里的H可能代表225365fb5195e804274ab569ac3cc4919451dc7f 。

提交H本身由两部分组成。 这两部分都是完全只读的，没有什么可以改变这些，所以提交H将这两个东西永远保存：

• 提交的一部分是每个文件的快照。 提交中的文件以特殊的、只读的、仅限 Git 的、压缩的和重复数据删除的形式存储。 它们实际上是您文件的存档。 重复数据删除是因为大多数提交主要重用来自其他提交的文件，这意味着重用的文件不占用任何空间。

• 提交的另一部分是一些元数据，或者关于提交本身的信息。 例如，这包括提交人的姓名和 email 地址。 它包括他们提交的日期和时间。 它包括他们的日志消息，他们应该在其中解释他们为什么提交。 而且，出于 Git 自己的内部目的，元数据包括一些较早提交的实际 hash ID。

较早的提交（提交H之前的提交）有一些丑陋的 hash ID，例如140045821aa78da3a80a7d7c8f707b955e1ab40d （我们简称为G ）。 这看起来是随机的， ¹因此没有简单的方法将一个哈希或一个提交与另一个相关联，除了提交H在H中有提交G的 hash ID 的事实。 我们说H指向G 。

反过来，提交G存储一个快照——每个文件的完整集合； 将G中的快照与H中的快照进行比较，可以显示哪些文件发生了更改——以及元数据。 G中的元数据指向更早的提交F 。 提交F ，与G和H一样，存储快照和元数据，因此从F Git 可以 go 向后提交到更早的提交，依此类推。

---

¹它实际上是一个加密校验和，在某些方面类似于为数字货币提供动力的一些技巧。

---

分行名称

这些东西——带有快照和元数据的提交——主要是存储库中的内容。 快照包含文件，Git 可以提取这些文件供您查看和处理/使用，以及元数据，Git 可以用来查找早期提交。 但是要使用最新的提交，我们必须知道哪一个是最新的。 这就是分支名称的来源。

每个分支名称仅包含一个 hash ID。 根据定义，存储在分支名称中的 hash ID 是该分支上的最后一次提交。 所以，假设我们有这个：

          I--J   <-- branch1
         /
...--G--H
         \
          K--L   <-- branch2

此图表示分支名称branch1持有提交J的 hash ID，即指向提交J 因此，提交J是此分支上的最后一次提交。

同样， branch2持有提交L的 hash ID。 因此，提交L是此分支上的最后一次提交。

在哪个分支上提交H ？ 这是一个有点技巧的问题，但图表本身就是一个提示：

• 请注意，提交I在branch1上，因此J指向I的事实意味着提交I在branch1上。 J是branch1上的最后一次提交，因此较早的提交也在branch1上。

• 提交K在branch2上，因为提交L在branch2上。

• 因此，提交H同时在两个分支上。 至少，它在 Git 中。 （其他版本控制系统以不同的方式执行此操作。）

实际上，如果我们添加一个新的分支名称，指向提交H ，如下所示：

          I--J   <-- branch1
         /
...--G--H   <-- main
         \
          K--L   <-- branch2

这只是意味着提交H现在在所有三个分支上（并且是最后一个或tip提交在main上）。 如果我们删除名称main ，则提交H现在仅在剩余的两个分支上。

这就是为什么——更重要的是，何时——分支名称并不重要。 由于我们可以通过其他两种方式找到H ，我们可以完全删除名称main 。 我们将通过从其他两个分支名称之一开始并向后工作来找到H 但是请注意，一旦我们不再拥有main ，我们将“忘记”提交H应该是main上的最后一次提交。

这让我们回到您最初的问题和理解 Git 的关键

克隆现有 Git 存储库时：

$ git clone ssh://git@github.com/user/repo.git

例如，您的计算机创建了一个新的 Git 存储库。 It then copies all the commits from the other Git repository—which your Git reaches by calling up their Git at the URL you give—so that you have all of their commits ... but it does not copy any of their branch names yet .

相反，您的 Git 有他们的 Git 列出了他们所有的分支名称，连同那些提交 hash 的 ID 用于他们的分支的提示提交。 您的 Git 然后获取他们的分支名称并更改它们。 您的 Git 将其分支名称转换为您的远程跟踪名称，例如origin/main或origin/develop ² 。 它通过将远程名称origin （和斜杠）粘贴在它们的分支名称前面来做到这一点。 ³

结果是，如果他们有：

          I--J   <-- branch1
         /
...--G--H   <-- main
         \
          K--L   <-- branch2

然后你得到这个：

          I--J   <-- origin/branch1
         /
...--G--H   <-- origin/main
         \
          K--L   <-- origin/branch2

请注意，此时您根本没有分支名称。

通常， git clone的最后一步是运行git checkout （或在 Git 2.23 及更高版本中， git switch ） 正是这一步创建了你的main分支，前提是你有你的 Git 首先检查那个名字main 。

当您运行git checkout main时，您的 Git：

• 检查您是否有一个名为main的分支（没有，或者至少还没有）；
• if that fails, checks to see if there's a file named main (this is a drawback / bad-feature / bug in git checkout , corrected in git switch , and is the reason that the Git folks added git switch in Git 2.23); 最后
• 去寻找你的 Git 可以用来创建一个名为main的分支的origin/main main 。 ⁴

最后一部分有效，因此您的 Git创建main ，并将其设置为“跟踪” origin/main ：您自己的 Git远程跟踪名称，用于其他 Git 的分支名称main 。

这种事情发生在最初的git clone和您自己运行的git checkout上。 这给了你：

          I--J   <-- origin/branch1
         /
...--G--H   <-- main, origin/main
         \
          K--L   <-- origin/branch2

如果您现在运行git checkout branch1 ，您的 Git 会注意到没有名为branch1的实际分支，并且最终会使用aha，有一个origin/branch1我可以用来创建一个（本地）分支名称branch1来挑选提交内置于git checkout和git switch的J技巧。

Git 将此特殊技巧称为 DWIM ，它代表按我的意思执行：创建分支，就像我运行git checkout -b branch1 --track origin/branch1 。 它现在也称它为guessing ，并且git checkout --no-guess告诉它不要尝试 DWIM 代码：如果您没有branch1 ，请不要搜索可用于创建的远程跟踪名称.

---

² Git 文档调用这些远程跟踪分支名称。 如果您喜欢它，您可以使用该短语，并且您应该期望 Git 文档使用它 - 但许多人不小心在此处输入了错误的单词并开始说remote-tracking branch ，而不是remote-tracking name 。 如果你删除多余的单词branch ，你就不会犯这个特别的错误。 事实是，您无法像“打开”分支那样“打开”远程跟踪名称，因此重要的是要知道这些不是真正的分支名称。

³如果愿意，您可以为远程名称选择一个与origin不同的名称。 远程名称主要是存储您必须早先键入的 URL 的一种方式，以便稍后您可以只说origin而不是ssh://...或https://... 但请注意，您选择的实际远程名称，无论它是什么，也是 Git 粘贴在其分支名称前面的字符串。 如果你选择xyzzy而不是origin ，你会得到xyzzy/main等，而不是origin/main等等。

⁴这个过程比我在这里展示的要复杂。 详细信息也取决于您的特定 Git 版本。 但是有了一个创建origin/main的新克隆，这就是最终结果。

---

通过提交来扩展分支

请注意，在使用 DWIM 模式创建（本地）分支名称之后，分支名称和远程跟踪名称都 select 相同的 commit ，像这样：

...--G--H   <-- main, origin/main

但是，Git 现在说您on branch main 。 如果您运行git status ，它将on branch main打印出文字文本。 在这种绘图中，为了表示这一点，我喜欢将特殊名称HEAD （全部大写）附加到分支名称：

...--G--H   <-- main (HEAD), origin/main

如果你现在进行一个新的提交——我们不会介绍这样做的机制，我们只是假设你知道如何去做——Git 会让你为新的提交提供一个日志消息，向你自己解释并其他人为什么你做出承诺。 该提交获得一个新的、完全独特的 hash ID。 这个 hash ID 不能在任何其他 Git 存储库中使用，这就解释了为什么 hash ID 如此之大和丑陋，一旦它是你的，它就不能再使用了。 ⁵但我们在这里只称它为I ：

...--G--H
         \
          I

请注意新提交I如何向后指向现有提交H 。

正是在这一点上，Git 做了它真正的大魔术：Git 写入新的HEAD ID，以便新提交到分支名称得到更新。 所以现在我们有：

...--G--H   <-- origin/main
         \
          I   <-- main (HEAD)

虽然HEAD仍然附加到main ，但名称main本身现在指向新的提交I 。

---

⁵如果两个 Git 存储库从未相互联系，则将提交 hash ID 用于不同的提交不会破坏任何内容。 但在实践中，我们永远不必担心它； 它与 Git 的加密 hash function 一样安全。 嗯，呃，嗯：新发现的SHA-1冲突对Git有什么影响？

---

这就是为什么每个 Git 存储库都有自己的私有分支名称的原因

只要您的分支名称指向与远程跟踪名称相同的提交，您就不需要分支名称，至少目前还不需要。 你可以只git checkout origin/main 。 但这会导致 Git 称为分离的 HEAD ，我将其绘制如下：

...--G--H   <-- HEAD, origin/main

如果您在此模式下进行新的提交，您将获得：

...--G--H   <-- origin/main
         \
          I   <-- HEAD

没有可以用来查找提交I的分支名称。 暂时可以，但是如果您现在git checkout出其他内容，我们将丢失提交I的实际 hash ID 。 所以这就是为什么你想在进行新的提交之前“在”一个分支上。

（有一些方法可以从错误中恢复，所以在 detached-HEAD 模式下进行提交并不是致命的。这只是......烦人。）