git - 对在 git 中创建嵌套分支感到困惑

Question

我刚开始使用 git，并开始与其他开发人员协作编写相同的代码。我之前使用过 SVN，但从未在我的代码库上与其他人协作过。现在有合作者处理相同的代码，我需要一个高效的工作流程。在搜索时，我找到了 this ，对于我们的要求来说，这似乎是一个很好的工作流程。

我的存储库驻留在本地机器上。我使用 git init --bare 创建了存储库。我将初始代码添加到 master 并推送它。然后我使用 git branch develop 添加了一个“develop”分支； git push -u origin develop.

现在我想从“开发”创建功能分支，并且我希望所有协作者都可以访问这些功能分支。我希望有一个嵌套结构，像这样

origin/master
origin/develop
origin/develop/newFeature
origin/develop/anotherFeature
etc.

这样，当合作者输入 git branch -a 时，他/她将立即知道“newFeature”在“develop”行中，并决定要做什么。

所以经过一些尝试和错误，这就是我所做的:

git clone file:///path/to/repo --branch develop
git checkout -b newFeature develop
EDIT some files
git add .
git commit
git push origin newFeature

现在这个“newFeature”可供所有协作者克隆。 git branch -a 给我

  develop
* newFeature
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/master
  remotes/origin/newFeature

那么“newFeature”真的是“develop”分支的一部分吗？或者它现在自己分支？一旦我克隆了“newFeature”，我如何检查它是否是开发线？这可能会造成混淆，因为我最终可能会在适当的时候在 master 中拥有一个名为“newFeature”的分支!

我对 git 工作原理的理解肯定是不够的。因此，如果有人能指出我正确的方向，那就太好了!

TIA，

Answer 1

TL;DR 版本:最初只是git checkout -b develop/feature(你需要不有一个名为develop 让它工作!)。

---

分支并没有真正“嵌套”，原因非常简单:分支名称(如 newFeature)仅代表一些提交 ID，即一些 SHA-1“真名”一些 promise 。

(在这方面，分支名称与标签相同，如“v2.3”。)

(本地)分支名称的特殊之处——它们与任何其他引用的不同之处——是“git checkout”将让您通过在 git 的 中写入分支名称来“进入分支” HEAD 文件，和，完成后，进行新提交将自动更新分支名称，以便它指向您刚刚提交的新提交制作。

(远程分支名称不能通过这种方式“打开”，但也会根据需要更改其目标 SHA-1。我提到这一点只是因为下一段提到“远程分支”或“远程跟踪分支” ，您将在 git branch -r 输出中看到。)

然而，分支名称按 git branch --list 排序(在按“种类”排序之后，即首先将所有本地分支组合在一起，然后是所有远程分支)。这意味着您可以将名称组合在一起:只需将名称最初创建为develop/anotherFeature 和develop/newFeature。在这种情况下，斜杠只是名称的一部分。

这里的问题是 git 最初通过将它们放在包含文件的目录中来实现¹ 这些分支名称。在支持 git 的系统上，你不能同时拥有一个名为 develop 的目录和一个名为 develop 的文件。 ² 所以如果你有一个名为 develop 的分支，git 可能已经创建了一个文件(特别是 .git/refs/heads/develop)，这会阻止它来自创建一个目录(.git/refs/heads/develop，再次)包含文件(newFeature)，该文件包含分支当前标识的提交的 SHA-1 .

---

¹虽然 git 现在也使用平面文件 (.git/packed-refs) 来存储分支到 SHA-1 的映射，但它仍然使用目录的文件，并且必须确保您没有创建必须同时用作目录和文件的名称。

²我个人认为文件系统名称实体同时用作目录 和 文件是有意义的:这将是一种方式，例如，存储所有可执行文件的 ELF 部分作为可执行程序目录中的文件，或者处理 MacOS 为应用程序包所做的事情。但这违反了 POSIX 中事物必须工作方式的各种规则，因此需要对文件系统 namespace 进行重大重新设计，并且更适合作为计划 9 的后续(例如)而不是作为 Unix 风格的变体。