Git: Когда вы нажимаете тег signle на удаленный, как я могу нажать ветку, содержащую этот тег?

Question

Использование git push origin <tag_name> может нажимать тег на удаленный сервер, как показано в This Question. Однако, если локальная ветвь, содержащая этот тег, опережает удаленный сервер, это push-действие создаст анонимную ветку, содержащую этот тег.

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

Таким образом, вопросы: Как я могу нажать ветку (лучше всего на тег только), когда я хочу нажать тег?

Поскольку я еще не уверен, что нужно нажимать всю историю ветки (но я уверен, что нужно нажать до точки тега, так как я хочу нажать тег), удобнее нажимать ветвь только на точки тега.

Какие-либо решения?

Answer 1

По умолчанию git fetch (или git pull) не извлекает теги.

Если вы хотите получать удаленные теги: git fetch --tags

Answer 2

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

Анонимные ветви проблематичны. Части Git считают, что это ветви, а части нет. Если они существуют, то каждая фиксация является ее собственной анонимной ветвью. Для большинства целей, вероятно, лучше всего подумать о выборе фиксации с или без выбора некоторых или всех его предков. Выбор фиксации bacacabбез родословная получает от вас одну фиксацию, и ее выбор с ancestry заставляет ее действовать как анонимная ветка.

В любом случае, то, что git fetch всегда копирует без изменений, потому что оно должно состоять из самих объектов-коммитов и того, что относится к ним: любые деревья или капли требуются, и требуются любые ранее требуемые коммиты. Для объектов с аннотированными тегами Git копирует сам объект тега без изменений и добавляет целевой объект тега к набору требуемых объектов (для копирования, если он еще не присутствует). Как это находит те идентификаторы объектов по именам - любые имена ссылок, а не только названия ветвей или тегов, представленные другим Git, тот, который Git извлекает из. Таким образом, это означает, что должно быть. Но это имя в другом Git, в другом репозитории; имя, если оно есть, использовать в ваш репозиторий - это что-то под вашим контролем.

Как выясняется, существует некоторая ошибка, когда Git извлекает только имя тега и не дает инструкции скопировать имя тега явно, он вообще ничего не пишет (кроме файла FETCH_HEAD) в некоторых случаях. См. my answer - Why is git fetch not fetching any tags? Короче говоря, если вы git fetch --tags, вы получите их - другое имя тега Git's, скопированное в тег с тем же именем в вашем собственном репозитории, и затем вы можете использовать это имя тега для поиска фиксации (и его предков).

---

В этом отношении, один фиксации может быть кончик фиксации бесконечного числа анонимных ветвей. Кто скажет, если отсутствие имени совпадает с именем второго имени? Ясно, что анонимная ветка, заканчивающаяся на фиксации dadf00d, отличается от анонимной ветки, заканчивающейся на bl00de1f, поэтому no-name определенно не соответствует no-name. Так почему же или нет, нет-имя для ac0ffee соответствует нет-имени для ac0ffee? (Это риторический/философский вопрос, призванный задуматься о характере суждений и названий ветвей в Git, а не о конкретном ответе, хотя у меня есть свой собственный конкретный ответ. :-))

Это модифицировано для мелких клонов. Здесь коммиты скопируются до некоторого значения «глубины», а затем Git вставляет мелкий графт, искусственно притворяясь, что у фиксации нет родителей (путем записи идентификатора фиксации до .git/shallow). Но фиксация фактически копируется нетронутой; это просто графовая прогулка, которая усекается.