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

问题描述

长话短说...

据我所知，术语分支"(在 Git 中)可能指的是相关但不同的事物:

1. 一个非符号引用/指向提交的指针，
2. 此类引用的名称(例如master")，
3. 存储库提交 DAG 的子图，由此类引用指向的提交可访问的所有提交组成.

但是，我已经看到该术语显然是指除了这三种可能的用法之外的其他东西(更多详细信息见下文).在 Git 上下文中，我上面的列表缺少分支"一词的其他有效且明确的用法吗?

更多详情

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

当然，我使用 Git 分支已经有一段时间了；我很乐意使用它们，并发现 Git 分支模型很棒.但是，我仍然觉得分支"这个词有问题且模棱两可，因为它似乎指代至少两种不同的事物，具体取决于使用它的上下文……有时甚至在同一个教程/手册中.

用法 1:分支 = 提交的指针/引用

Pro Git 书(在 介绍分支如下:<块引用>

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

我猜他们的意思是一串提交.让我细化一下这个想法......对我来说唯一有意义的解释是术语分支"也可以指存储库提交 DAG 的子图，该子图由所考虑的提示提交可到达的所有提交组成强>.

但是，例如，Pro Git 书还包含以下图表(参见 ):

这里master的提示实际上是 534de(而HEAD指向master)，但是图中master"标签的位置很容易让人误解.在这种情况下，该标签应该描述什么我不清楚......

编辑:此后我发现了这个 Marc 博客上的精彩帖子；Branches 部分与我上面的评论相呼应.

解决方案

你说得对.

我们可以通过分离本地"和远程"分支标签来进一步拆分您的项目 1:本地分支(本地标签)是以 refs/heads 开头的名称(在内部——许多前端命令隐藏了这一点)//code>，而远程分支"——也称为远程跟踪分支"——以 refs/remotes/ 开头，然后在部分之前还有一个路径组件命名特定的远程命名分支.(编辑，2018 年 4 月:我不喜欢远程分支"或远程跟踪分支"这个词；我认为最好只调用这些远程跟踪名称.但是有很多现有的文档使用了另外两个短语，所以我们需要注意这种用法.)

例如，您无疑熟悉 refs/remotes/origin/master，但如果您有一个名为 bob 的遥控器，您可能还有 refs/remotes/bob/hacks/feep 跟踪 Bob 的 hacks/feep.

本地分支名称 refs/heads/branch 具有显着特征，git checkout 默认会让你在"那个分支, 通过将该名称写入特殊的 HEAD 引用；一旦你这样设置，新的提交(由 git commit、git merge、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. (Edit, April 2018: I dislike the phrase "remote branch" or "remote-tracking branch"; I think it's better to just call these remote-tracking names. But there is a lot of existing documentation that uses the other two phrases, so we need to be aware of this usage.)

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屋！