Что именно мы подразумеваем под "ветвью"?

Question

Короче...

Насколько я могу судить, термин "ветвь" (на языке Git) может относиться к связанным, но различным вещам:

1. не символьная ссылка / указатель на коммит,
2. название такой ссылки (например, "мастер"),
3. подграф DAG коммита репозитория состоит из всех коммитов, достижимых из коммита, на который указывает такая ссылка.

Тем не менее, я видел термин, используемый для обозначения чего-то иного, чем эти три возможных использования (более подробно ниже). В контексте Git, есть ли другие допустимые и недвусмысленные использования термина "ветвь", которые отсутствуют в моем списке выше?

Подробнее

После года использования Git я готовлю краткое руководство для студентов CS. Я действительно хочу закрепить терминологию Git, чтобы избежать путаницы.

Конечно, я уже некоторое время использую ветки Git; Мне удобно их использовать, и я нахожу модель ветвления Git классной. Тем не менее, я все еще нахожу термин "ветвь" проблематичным и неоднозначным, потому что он, по-видимому, относится как минимум к двум различным вещам, в зависимости от контекста, в котором он используется... иногда даже в том же учебнике / руководстве.

Использование 1: ветвь = указатель / ссылка на коммит

Книга Pro Git (в 3.1 - Что такое ветка), после показа следующей диаграммы,

продолжает определять ветвь как

просто легкий подвижный указатель на один из этих коммитов.

Насколько я могу судить, это также означает, что "ветка" имеет на страницах руководства Git.

Я совершенно доволен этим определением. Я рассматриваю ветвь как просто ссылку, указывающую на конкретную фиксацию в группе обеспечения доступности баз данных, а "коммит-подсказка" ветви - это фиксация, на которую указывает эта ссылка. Все идет нормально. Но ждать...

Использование 2: ветвь = подграф DAG

Учебник по Atlassian Git представляет следующие ветки:

Филиал представляет собой самостоятельную линию развития.

Я предполагаю, что они подразумевают под этим последовательность коммитов. Позвольте мне уточнить эту мысль... Единственная интерпретация, которая имеет смысл для меня, состоит в том, что термин "ветвь" может также относиться к подграфу коммитов DAG репозитория, состоящему из всех коммитов, достижимых из рассматриваемого коммит-коммита.

Однако книга Pro Git, например, также содержит следующую диаграмму (см. 3.4 - Ветвящиеся рабочие процессы),

что, кажется, противоречит моей интерпретации, потому что, кажется, подразумевает, что только совершает C2-C5 (не C1) принадлежат develop ветвь, и это только совершает C6-C7 (не C1-C5) принадлежат topic ветка.

Я нахожу это использование неоднозначным и расплывчатым, потому что, если бы я нарисовал группу DAG на этом этапе, не зная, куда в прошлом указывали ссылки на ветви, и не предполагая какой-либо иерархии между тремя ветвями, все, что я получил бы, это

Я также нахожу некоторые диаграммы в других учебных ресурсах Git запутанными. Рассмотрим, в частности, следующее (взято из вступительного видео Lynda.com - Git Essential Training):

Здесь верхушка master на самом деле 534de (а также HEAD указывает на master), но положение "основной" метки на диаграмме очень обманчиво. Что этот ярлык должен описать в этом случае мне неясно...

Изменить: с тех пор я нашел этот отличный пост в блоге Марка; раздел Ветви повторяет мои замечания выше.

Answer 1

Ты прав.

Мы можем далее разделить ваш элемент 1, разделив "локальные" и "удаленные" метки ветвей: локальные ветви (локальные метки) - это имена, которые начинаются (внутренне - многие команды переднего плана скрывают это) refs/heads/в то время как "удаленные ветви", которые также называются "удаленными ветвями", начинаются с refs/remotes/ и затем иметь еще один компонент пути, называющий конкретный пульт, перед частью, называющей ветвь. (Правка, апрель 2018 г.: мне не нравится фраза "удаленная ветвь" или "удаленная ветвь"; я думаю, что лучше просто называть эти имена для удаленной слежки. Но существует много существующей документации, в которой используются две другие фразы, поэтому мы должны знать об этом использовании.)

Например, вы, без сомнения, знакомы с refs/remotes/origin/master, но если у вас есть пульт с именем bob вы также можете иметь refs/remotes/bob/hacks/feep который отслеживает Боба hacks/feep,

Название местного филиала refs/heads/branch имеет отличительную особенность, которая git checkout по умолчанию поместит вас в эту ветку, записав это имя в специальный HEAD ссылка; и как только вы настроены таким образом, новые коммиты (созданные git commit, git merge, git cherry-pickи т. д.) заставить SHA-1 нового коммита записываться в файл филиала. (Новый коммит имеет в качестве своего родителя или одного из своих родителей старый кончик ветви.)

Я попытался использовать такие термины, как "tip tip", чтобы обозначить фиксацию, к которой относится название ветви refs/heads/master точки, "имя ветви" или "имя локальной ветви" для обозначения самого имени (с префиксом refs/heads/ или нет) и - я думаю, что это наименее успешная - "структура ветвления" для ссылки на подмножество DAG. Однако, с учетом DAG с разветвлением и слиянием, как это:

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

Иногда я хочу называть одну или другую половину небольшого объекта, похожего на бензольное кольцо, также "ветвью", и у меня нет действительно хорошего термина для этого.

(Между прочим, если бы вы были топологом, тот факт, что диаграмма Атлассиана также может быть нарисована линейно, не беспокоил бы вас. Однако, как гласит старая шутка, топологи продолжают пить из своих пончиков и есть свои кофейные кружки, так как каждый это просто тор.)

Answer 2

Во втором случае мы имеем в виду "коммиты, которые достижимы из коммита, на который указывает ветвь".

В примере Pro Git, предполагая, что topic точки ветвления для фиксации C7эта ветвь содержит коммиты C7, C6, C5, C4, C3, C2, а также C1, Нет другого понятия, что коммит находится "на" ветке, кроме этого в Git, и вы правы в том, что вы можете перерисовать DAG линейно.

Диаграмма Lynda.com ужасно неясна, и я подозреваю, что вы правы, что она вводит в заблуждение.