Короткий ответ - нет.
Длинный ответ поучителен: в Git ветка name - это просто указатель на коммит .Это означает, что независимо от того, что вы подразумеваете под «ветвью» - см. Что именно мы подразумеваем под «ветвью»? - вы не можете иметь ветку, в которой нет хотя бы одного коммита на нем.
Более того, этот чертеж в корне неверен:
v2.0(master) - o - o - ...
Это означает, что ветвь name находится наслева и новые коммиты растут, по одному, вправо.Это правда, что новые коммиты do растут, по одному, вправо, но ветвь name также находится справа!То есть имя master изначально указывает на самый первый сделанный вами коммит.Вы начинаете с полностью пустого хранилища:
master (HEAD)
Имя HEAD существует и присоединено к имени ветви master, но сама ветвь не существует , потому чтокоммитов нет! 1 Имя ветви должно указывать на существующий, действительный коммит, а их просто нет.
В конце концов, вы делаете свойпервый коммит, и Git сразу заставляет имя master указывать на него.У коммита есть какой-то большой уродливый хеш-идентификатор, который на самом деле является криптографической контрольной суммой содержимого этого коммита - он зависит от вашего имени и адреса электронной почты, всех файлов, которые хранятся в этом коммите, а также от даты и времени,делая невозможным предсказание, но давайте просто назовем это A:
A <-- master (HEAD)
Затем, через некоторое время, вы делаете новый коммит.Мы назовем это B здесь.Новый коммит B записывает фактический хэш-идентификатор коммита A, поэтому мы говорим, что B указывает на A:
A <-B
Что происходит с именем ветвина данный момент это ключ.Имя master останавливается , указывая на коммит A, потому что Git немедленно перезаписывает master новым хеш-идентификатором нового коммита B:
A <-B <-- master (HEAD)
На этом этапеесли вы создаете новое имя ветки, вы делаете это, устанавливая его так, чтобы он указывал на один из этих двух существующих коммитов.Затем вы можете прикрепить к нему имя HEAD:
A <-B <-- master, xyz (HEAD)
и теперь, если вы сделаете новый коммит - назовем его C - новый коммит укажет на B и Git будетзапишите хэш-идентификатор C в любое имя, к которому прикреплено HEAD:
A <-B <-- master
\
C <-- xyz (HEAD)
Обратите внимание, что commit A никогда не будет указывать на какой-либо другой коммит: коммиты после их выполнения считываютсятолько.Коммит A не имеет родительского , и он останется таким навсегда.
(Вы можете в любое время создать целый ряд новых и различных коммитови Git позволит вам изменить все имена веток, чтобы они указывали на совершенно новый и другой набор коммитов, так что вы можете войти и создать:
G--H--I <-- branch-for-v1
\
J--K--L <-- master (HEAD)
оставляя коммиты A-B-C позади навсегда, и в конечном итоге эти три коммита истекают и удаляются - но это не изменение коммитов A-B-C, которые все еще идентифицируются по их фактическим хеш-идентификаторам, какими бы они ни былиОбщий термин для этой идеи - создание целых новых цепочек коммитов, а затем присвоение имен ветвям указателей на новые цепочки вместо старых цепочек - называется переписывание истории . Еслии когда концепция работает, она делает это, потому что мы, люди, начинаем с того, что фиксируем имя , на которое указывает, и, подобно Git, продвигаемся назад, через эти обращенные назад внутренние коммюнике.это стрелки.)
1 Tэто означает, что если вы спросите Git, в какой ветке вы находитесь (например, git status), он ответит master, но если вы спросите Git, какие ветви существуют, он скажет, что no филиалов существуют.Вы буквально находитесь на ветке, которой не существует.Git по-разному называет это нерожденная ветвь или сиротская ветвь .Первое, по крайней мере, на мой взгляд, на самом деле лучшее название для него;название "сиротская ветвь" является ошибкой, с которой мы застряли, потому что кто-то наделал глупостей на ранних этапах разработки Git.