我们所说的“分支”究竟意味着什么？ [英] What exactly do we mean by "branch"?

问题描述

据我所知，术语分支（用Git的说法）可能指的是相关但不同的东西：

/ b>

1. 非符号引用/指向提交的指针，
   
2. 这样的引用的名称例如master），
   
3. 存储库提交DAG的子图由所提交的所有可提交的提交组成。

ol>



然而，我已经看到这个词用来明确指出除了这三种可能的用法之外的其他用法（更多细节在下面）。在Git上下文中，是否还有其他有效和明确的术语分支用法，以上列表缺失？



更多详细信息





使用Git大约一年后，我正在为CS学生准备一个简短的教程。我真的想要确定Git的术语，以避免混淆。





当然，我一直在使用Git分支，我很喜欢使用它们，并发现Git分支模型真棒。然而，我仍然觉得术语分支是有问题的和模棱两可的，因为它似乎至少指两种不同的东西，这取决于它使用的上下文......有时甚至在同一个教程/手册中。





用法1：分支=指向提交的指针





Pro Git书籍（介绍如下分支机构：




一个分支代表一条独立的开发线。


他们的意思是，我猜，是一串提交。让我细化这个想法......唯一对我有意义的解释是术语分支也可以指代存储库提交的子图DAG由提交提交可达到的所有提交组成，但是，Pro Git书籍中还包含以下图表（请参阅）：






这里， master 的提示实际上是 534de （和 HEAD 指向 master ），但图表上主标签的位置非常具有误导性。这个标签应该描述的内容对我来说是不清楚的......





编辑：我自从发现这个 Marc的博客上出色的帖子; 部分 部分回应了我上面的评论。 $ b

解决方案


$ b

我们可以通过分离本地和远程分支标签来进一步拆分项目1：本地分支（本地标签）是启动的名称（内部许多前端命令将其隐藏） refs / heads / ，而远程分支（也称为远程跟踪分支） - 从 refs / remotes / ，然后在命名分支的部分命名特定的远程命令后再有一个路径组件命名。

例如，您无疑熟悉 refs / remotes / origin / master ，但是如果你有一个名为 bob 的远程，你可能还有 refs / remotes / bob / hacks / feep 跟踪Bob的 hacks / feep 。




本地分支名称 refs / heads / 分支 具有显着特征： git checkout 在由d分支通过将该名称写入特殊的 HEAD 引用中;一旦你这样设置，新的提交（由 git commit ， git merge ，<$ c创建$ c> git cherry-pick 等）导致新提交的SHA-1写入分支文件。 （新提交作为其父项或其父项之一，旧分支。）



我试图使用分支提示具体表示分支名称如 refs / heads / master 点，分支名称或本地分支名称以提及名称本身的提交（无论是否为前缀通过 refs / heads / 或不），并且 - 我认为这是最不成功的 - 分支结构来引用DAG子集。但是，给定一个像这样的分叉合并的DAG：



  o  -  o 
 / \ 
 ...- o  -  o o  -  o -... 
 \ / 
 o  -  o 
  

我有时想把这个小的苯环状物体的一个或另一个称为分支，我也没有真正的好名词（顺便说一下，如果你是一个拓扑学家，Atlassian图也可以线性绘制的事实不会打扰你，但是，随着老玩笑的发展，拓扑学家们不断尝试从他们的甜甜圈中喝酒，并且因为每个人都只是一个圆环，所以他们只喝咖啡杯。）


Long story short...

As far as I can tell, the term "branch" (in Git parlance) may refer to related but different things:

1. a non-symbolic reference/pointer to a commit,
2. the name of such a reference (e.g. "master"),
3. the subgraph of the repository's commit DAG composed of all the commits reachable from the commit pointed to by such a reference.

However, I've seen the term used to apparently refer to something other than those three possible usages (more details below). In a Git context, are there other valid and unambiguous usages of the term "branch" that my list above is missing?

More details

After using Git for about a year, I'm preparing a short tutorial for CS students. I really want to nail down the Git terminology, so as to avoid any confusion.

Of course, I've been using Git branches for a while now; I'm comfortable using them and find the Git branching model awesome. However, I still find the term "branch" problematic and ambiguous, because it seems to refer to at least two different things, depending on the context in which it's used... sometimes even in the same tutorial/manual.

Usage 1: branch = pointer/reference to a commit

The Pro Git book (in 3.1 - What a branch is), after showing the following diagram,

goes on to define a branch as

simply a lightweight movable pointer to one of these commits.

As far as I can tell, this is also the meaning "branch" has in the Git man pages.

I'm perfectly comfortable with this definition. I think of a branch as just a reference that points to a particular commit in the DAG, and the "tip commit" of a branch is the commit pointed to by that reference. So far, so good. But wait...

Usage 2: branch = a subgraph of the DAG

The Atlassian Git tutorial introduces branches as follows:

A branch represents an independent line of development.

What they mean by that, I guess, is a string of commits. Let me refine that thought... The only interpretation that makes sense to me is that the term "branch" can also refer to the subgraph of the repository's commit DAG composed of all the commits reachable from the tip commit considered.

However, the Pro Git book, for instance, also contains the following diagram (see 3.4 - Branching workflows),

which seems to contradict my interpretation, because it seems to imply that only commits C2-C5 (not C1) belong to the develop branch, and that only commits C6-C7 (not C1-C5) belong to the topic branch.

I find this usage ambiguous and vague because, if I were to draw the DAG at that stage, without knowing where the branch references have pointed to in the past, and without any assumption of any hierarchy between the three branches, all I would get is

I also find some diagrams in other Git learning resources confusing. Consider, in particular, the following one (taken from the introduction video of the Lynda.com - Git Essential Training):

Here, the tip of master is actually 534de (and HEAD points to master), but the position of the "master" label on the diagram is very misleading. What that label is supposed to describe in this case is unclear to me...

Edit: I've since found this excellent post on Marc's blog; the Branches section echoes my remarks above.

解决方案

You are correct.

We can further split your item 1 by separating "local" and "remote" branch labels: local branches (local labels) are names that start (internally—many front-end command hide this) with refs/heads/, while remote branches—which are also called "remote-tracking branches"—start with refs/remotes/ and then have one more path component naming the specific remote before the part naming the branch.

For instance, you are no doubt familiar with refs/remotes/origin/master, but if you have a remote named bob you might also have refs/remotes/bob/hacks/feep that tracks Bob's hacks/feep.

A local branch name refs/heads/branch has the distinguishing feature that git checkout will put you "on" that branch by default, by writing that name into the special HEAD reference; and once it you are set up this way, new commits (created by git commit, git merge, git cherry-pick, etc.) cause the new commit's SHA-1 to be written into the branch-file. (The new commit has as its parent, or one of its parents, the old tip-of-branch.)

I have attempted to use terms like "branch tip" to denote specifically the commit to which a branch name like refs/heads/master points, "branch name" or "local branch name" to refer to the name itself (whether prefixed by refs/heads/ or not), and—I think this is the least successful—"branch structure" to refer to the DAG subset. However, given a DAG with a fork-and-merge like this:

         o--o
        /    \
...-o--o      o--o-...
        \    /
         o--o

I sometimes want to refer to one or the other half of the little benzene-ring-like object as "a branch" as well, and I have no really good term for this.

(Incidentally, if you were a topologist, the fact that the Atlassian diagram can also be drawn linearly would not bother you. However, as the old joke goes, topologists keep trying to drink out of their donuts and eat their coffee mugs since each one is just a torus.)

这篇关于我们所说的“分支”究竟意味着什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！