git - 创建新分支时，基础分支是什么？

Question

创建分支时，我需要确认/纠正我的假设。如果我在master分支中，请执行以下操作：

git checkout -b some_branch

这意味着我已经从master开设了一个新分支。

另一方面，如果我签出另一个分支，并在那里创建一个分支：

git checkout some_branch
git checkout -b other_branch

这意味着我已经使用some_branch提交的所有当前代码创建了other_branch，对吗？

并且，无论当前分支如何，如果这样做：

git branch branch_2 branch_1

然后，将使用branch_1作为基础创建branch_2。
这些假设正确吗？

Answer 1

Git中没有这样的东西作为分支的基础分支。取而代之的是，只有一个当前提交，Git将其称为分支的尖端。

画图

要从视觉上理解它，应该首先绘制Git的提交图（至少一部分）。这是一个只有三个提交的小型存储库的示例：

A <-B <-C   <--master

任何给定提交的“真实名称”都是那些大的丑陋哈希ID（ c0ffeeface1deadbead...）之一，依此类推。该哈希ID唯一标识特定的提交，并且实际上是通过对该提交的内容进行哈希处理（因此称为“哈希ID”）来实现的。它们看起来是随机的，难以记住，因此在这里我只使用单个大写字母。

Git“查看”图形的方式是，它通过读取分支名称（例如 master）开始。该分支名称包含 C之类的提交的哈希ID。我们说 master指向提交 C。

同时，提交 C本身包含其先前（或父）提交 B的哈希ID。因此，我们说 C指向 B，与 master指向 C的方式相同。

同样，提交 B指向 A。 A是有史以来的第一个提交，因此没有地方可以指向...，所以它没有。我们将 A称为根提交，这使我们（和Git）停止向后工作。

这些内部箭头很烦人，请注意， B的哈希ID实际上是 C本身的一部分，因此它永远不会更改（如果尝试更改 C的这一部分，则会得到一个新的，不同的提交）。因此，我们可以不再烦恼绘制它们，而是编写：

A--B--C   <-- master

但是，从分支名称中出来的箭头不是恒定的，这就是提示提交的整个想法所来自的地方。

假设我们要向 master添加新的提交。我们完成了Git所需的所有常规设置（添加或修改某些文件并使用 git add），然后运行 git commit。 Git：


写出一个新的提交 D（它将获得一个新的，唯一的哈希ID）。这个新的提交指向 C：

A--B--C     <-- master
       \
        D

然后，更改 master（或更确切地说，是其存储的哈希ID），使其指向我们刚刚进行的新提交：

A--B--C
       \
        D   <-- master

当然，没有理由再在图纸中保留这种纽结了：

A--B--C--D   <-- master

这就是Git中分支的增长方式。

要创建一个新分支，Git只需创建指向某个现有提交的分支名称：

A
 \
  B
   \
    C
     \
      D   <-- master

我们可以选择这些提交中的任何一个，并在那里指定新的分支名称。让我们选择 B并使 newbr指向此处：

A
 \
  B   <-- newbr
   \
    C
     \
      D   <-- master

我们可以使用 git branch newbr <thing-that-finds-B>来实现。

但是，我们如何找到提交？

我们如何找到 B？好吧，一种方法是运行 git log并剪切并粘贴哈希ID。但是另一种方法是使用分支名称。现在，名称 newbr指向 B。如果我们也想创建另一个分支点来提交 B：

git branch thirdbr newbr

这使Git查找指向 newbr的 B，并创建新名称 thirdbr，它也指向 B：

A--B   <-- newbr, thirdbr
    \
     C--D  <-- master

这就是为什么在Git中创建分支如此之快的原因：它几乎什么都不做！它只是制作一个指向现有提交的标签。

一些分支名称指向的提交称为该分支的尖端提交。请注意，一次提交可以同时成为多个分支的提示。这是有关Git的更大事情的一部分：一些提交同时存在于多个分支上。例如，提交 A（根提交）在每个分支上。 （尽管有点棘手，但在存储库中可能有多个root提交，我们现在不必担心这一点。到目前为止，您不能用所示的命令来这​​样做。）

是什么使分支名称特别

但是，分支标签的特殊属性是它们可以移动。它们不仅会移动，而且会自动移动。

进行新的提交 D时，我们已经看到了这一点。 Git将新提交的ID写入 master。但是：Git怎么知道使用 master？因此，Git如何知道使 D的父母成为 C？

好吧，当然我们当时只有一个分支，但是现在我们有了三个标签 master， newbr和 thirdbr，现在就进行一次新提交。首先，让我们做 git checkout thirdbr并绘制结果：

A--B   <-- newbr, thirdbr (HEAD)
    \
     C--D  <-- master

图中没有真正改变，1只是我在这里添加了 HEAD一词。 HEAD是Git如何知道当前分支和提交的分支和提交的方式。

因此，现在我们进行通常的“修改某些文件” git add和 git commit。 Git会写出新提交，其父设置为提交 B。 Git看到当前分支为 thirdbr，并且 thirdbr指向 B，因此当前提交为 B。让我们绘制新的提交 E：

     E
    /
A--B   <-- newbr
    \
     C--D  <-- master

剩下的唯一事情就是移动当前分支名称 thirdbr，使其指向新的提交 E：

     E   <-- thirdbr (HEAD)
    /
A--B   <-- newbr
    \
     C--D  <-- master

到此为止，我们已经完成了：我们已经向分支 thirdbr添加了一个新提交（仍然是HEAD，因此仍然是当前分支，但是现在 E是当前提交）。

当您将提交添加到当前分支时，是HEAD，它指示当前提交是什么以及新提交在哪里。 HEAD通常包含分支的名称，这就是 git checkout的作用：它检出特定的提交（通常是现有分支的尖端提交），然后设置文件 HEAD来记住分支的名称。记住提示提交的是分支名称本身。

使用 git checkout -b newname commit的意思是：“签出指定的提交，然后创建一个指向该提交的新分支名称newname，然后将HEAD设置为该新名称。”如果省略提交部分，则默认为使用HEAD。由于HEAD（始终）是当前提交，因此Git可以跳过“签出”部分，而只需创建新的分支名称并将其存储到 HEAD文件中即可。



1虽然图中没有任何变化，但Git确实必须更新我们的工作树和索引，以便我们可以像提交 B那样拥有文件。