Ответ: Комментарий Сами Кухмонена :
Я предполагаю, что список отсортирован в алфавитном порядке и ничего не показывает, как ветви связаны друг с другом.
Однако стоит добавить, что здесь есть еще кое-что важное: В ветвях Git нет никаких внутренних связей. Нет такой вещи, как родительская ветвь какой-то другой ветки.
Что сбивает с толку, так это то, что коммиты do имеют отношения родитель / потомок, и в некотором смысле ветви состоят из коммитов. Так что, похоже, ветви тоже должны иметь их. Проблема в том, что когда мы говорим ответвлений прямо здесь, мы имеем в виду имен филиалов , таких как master и develop. Эти имена являются просто изменяемыми пользователями именами, которые Git предоставляет нам для отслеживания одного отдельного коммита . Тот единственный коммит, который запоминает каждое имя ветви, называется tip ветви:
A <-B <-C <--master
Каждый фактический коммит имеет какой-то большой уродливый идентификатор хеша в качестве своего реального имени, и с ними невозможно работать людям, поэтому у нас есть имя master, чтобы запомнить хеш-идентификатор коммита C. Commit C запоминает хэш-идентификатор своего родителя B, а B запоминает хэш-идентификатор своего родителя A. (A - это первый коммит, когда-либо сделанный в этом крошечном репозитории с тремя коммитами, поэтому у него нет родителя, и действие останавливается здесь: так как это первый, это конец истории, в стиле Git, обращенном назад.)
Чтобы сделать новый коммит, Git записывает новый коммит с новым уникальным хеш-идентификатором - давайте просто назовем его D - и затем обновляет имя master для хранения D ' хэш-идентификатор D содержит хэш-идентификатор C, поэтому Git может найти C из D:
A--B--C--D <-- master
Как только коммит сделан, он может никогда не изменяться (вообще - при изменении чего-либо вы получаете новый коммит с новым уникальным хеш-идентификатором, поэтому старый коммит имеет не изменилось!). Мы знаем, что внутренние стрелки всегда указывают назад, поэтому их не нужно рисовать. Однако, когда мы создаем новую ветку name , мы получаем два имени, указывающих на один и тот же коммит:
A--B--C <-- master, develop (HEAD)
Теперь нам нужно присоединить HEAD к имени ветки, чтобы мы знали, на каком мы находимся! Если мы сделаем коммит D сейчас, то название ветви, которая перемещается, будет develop:
A--B--C <-- master
\
D <-- develop (HEAD)
Но мы можем использовать от git reset до перемещения названий веток в любое время. Например, если нам все-таки не нравится D и мы хотим, чтобы develop начинался с B, мы можем git reset сделать его и сделать так:
A--B <-- develop (HEAD)
\
C <-- master
\
D [abandoned, will go away in about a month]
Если мы сейчас сделаем новый коммит E, родительский элемент E будет B, а видимая часть будет выглядеть так:
A--B--E <-- develop (HEAD)
\
C <-- master
(Коммит D не может его найти - он недоступен в терминах Git - поэтому мы не можем увидеть его обычными средствами.)
Заключение
Имейте в виду, что каждая ветвь name является просто указателем, указывающим на один (1) коммит, как на рисунках выше. Git использует коммитов , чтобы найти своих родителей, следуя по цепочке от «куда указывает имя» вглубь истории. Но вы обнаружите, что когда люди говорят о «ветке» в Git, они часто имеют в виду не имя , а скорее коммиты, достигнутые, начиная с имени и двигаясь назад, Вы должны выяснить из контекста, означает ли кто-то «имя» или «набор коммитов». Подробнее об этом см. Что именно мы подразумеваем под «ветвью»?