Короче говоря...

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

несимволическая ссылка/указатель на фиксацию,
имя такой ссылки (например, "master" ),
подграф репозитория фиксирует DAG, состоящий из всех коммитов, достижимых из фиксации, на которую указывает такая ссылка.

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

Подробнее

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменить. С тех пор я нашел эту ; раздел "Филиалы" повторяет мои замечания выше.

Ответ 1

Вы правы.

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

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

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

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

  o - o       /\
...- o - o o - o -...       \/        о - о
Код>

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

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

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

Короче говоря...

Подробнее

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

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

Ответ 1

Ответ 2