Что действительно делает git push, так это вызывает некоторый другой Git, снабжает его коммитами (и любыми другими необходимыми объектами), если / при необходимости, и затем просит этот другой Git установить - возможно, создавая или удаляя, в процессе -некоторые имена веток и / или тегов для некоторых хеш-идентификаторов коммитов.
Содержимое вашего хранилища практически не имеет отношения к этому процессу.Единственное реальное ограничение, которое накладывает ваш собственный Git, заключается в том, что идентификаторы хеша, которые он собирается предоставить другому Git, в конце, когда он запрашивает у них обновление их имен, должны быть действительными идентификаторами хеша в вашем хранилище.,Вы можете и обычно делаете эти действительные хэш-идентификаторы, предоставляя свои имена для веток или тегов, но это не обязательно.
Как Неманья Глумак отметил вкомментарий , вы можете использовать HEAD в качестве имени на вашей стороне.Если вы в данный момент находитесь в одной из ваших собственных веток, ваш Git находит имя вашей ветки, знает, что это ветка, и находит его tip commit, и использует его в качестве хеш-идентификатора коммита, который он попросит использовать другой Git.Затем, прежде чем он попросит другого Git установить что-либо, он удостоверится, что другой Git имеет этот коммит и любые предшествующие коммиты, необходимые для завершения истории этого коммита.Затем он просит другой Git установить одно из его имен веток или тегов для идентификатора хеша.
По умолчанию обычно запрашивается другой Git с тем же именем, которое вы использовали наваша сторона, но вы можете изменить это с настройкой push.default.Итак:
git push origin branch1 branch2:newbranch tag3 a123456:refs/heads/tag4 :del
заставляет ваш Git вызывать другой Git на origin, переводить любые коммиты (и все остальное), необходимые для этого Git, если необходимо, затем попросить их Git:
- установите их
branch1 имя ветки, чтобы соответствовать вашему; - установите их
newbranch имя ветки, чтобы соответствовать вашему branch2 фирменному названию; - установите их
tag3 тег, чтобы соответствовать вашемуТег tag3 (при условии, что tag3 является тегом); - устанавливает свой тег
tag4 так, чтобы он указывал на фиксацию (или другой объект), чей идентификатор хеша a123456...;и - удалить их имя
del (будь то ветка или тег).
Каждое имя после origin здесь представляет собой refspec , чтоэто примерно «два имени, разделенных двоеточием», за исключением того, что вы можете опустить двоеточие и второе имя, что означает «повторное использование имени».
Им разрешено отклонять любые или все эти запросы,по любой причине они могут выбрать.Если они делают отклоняют запросы, вы можете повторить попытку с более принудительным запросом, используя --force или префикс со знаком плюс в одной или нескольких ссылочных спецификациях.Они могут все еще отклонить эти более сильные команды;Опять же, это их Git, чтобы принять решение.
По умолчанию, как правило, обычно принимают вежливые запросы на обновление ветки, когда эти обновления:
- создают новая ветвь на их конце;
- удалить ветвь на их конце;или
- переместите существующее имя ветки в то, что Git называет быстрой перемоткой вперед .
В современном Git обновления тегов по умолчанию отклоняются, но оченьстарый получающий Гитс случайно применил здесь правила ветки.