Git-теги тоже выдвигаются?


190

С тех пор, как я создал свой репозиторий, создается впечатление, что созданные мной теги не помещаются в репозиторий. Когда я делаю git tagв локальном каталоге все теги присутствуют, но когда я вхожу в удаленный репозиторий и делаю a git tag, появляются только первые несколько.

В чем может быть проблема?


3
git push --follow-tagsТеперь может быть полезным, см. мой ответ ниже
VonC


1
Согласитесь с дубликатом: хотя это старше, другой вопрос лучше поставить.
Сиро Сантилли 郝海东 冠状 病 六四 事件 法轮功

Ответы:


247

Вы могли бы сделать это:

git push --tags

27
Я почти уверен, что это означает, что ссылки на HEAD не будут выдвинуты, а это означает, что вы ТОЛЬКО нажимаете на теги.
Дэн Розенстарк

47
«Я рекомендую не использовать и не обучать других использовать, git push --tagsпоскольку избавиться от плохих тегов может быть очень и очень трудно, когда ваши коллеги обучены нажимать на все теги, поскольку люди продолжают нажимать старые плохие теги, которые они имеют локально, каждый раз, когда они хочу добавить новый тег. Из-за этого я буду рекомендовать использовать его только каждому git push origin <tag_name>». - скопировано с stackoverflow.com/a/5195913/4130619
снижение активности

Я думаю, что другой ответ, stackoverflow.com/a/16164809/11635 должен быть принят. Даже если это не так, его обязательно нужно прочитать - он предоставляет плюсы и минусы и, в конечном счете, более практичный и правильный ответ на сегодняшний день
Рубен Бартелинк

140

В стандартной конфигурации git remote вы должны явно указывать теги (в то время как они выбираются автоматически вместе с коммитами, на которые они указывают). Вам нужно использовать

$ git push <remote> tag <tagname>

нажать одну метку, или

$ git push <remote> --tags

нажать на все теги (или git push --tags, как правило, нажать на удаленный по умолчанию origin).

Это очень предназначенное поведение, чтобы сделать push-теги явными. Нажатие тегов должно быть обычно осознанным выбором.


Подводя итог тому, что написал Хунио С. Хамано (в комментариях @Andre Miras)

При получении вы взаимодействуете с удаленным репозиторием, который кто-то опубликовал, что означает:

  1. набор существующих тегов - это все, что издатель хотел, чтобы люди видели, и
  2. не только вы, но и другие люди будут видеть те же теги.

Другими словами, теги в репозиториях, из которых вы выбираете, предназначены для публичного использования и общего доступа. Это облегчит общение между разработчиками, если всем будет легко получить те же теги.

Вот почему git fetchавтоматически «следит» за тегами, то есть он загружает теги при загрузке ревизий, на которые они указывают - другими словами, загружает все соответствующие опубликованные теги.

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

Вот почему вам нужно явно указать тег, чтобы пометить тег как открытый.


В качестве альтернативы вы можете настроить пульт, на который вы нажимаете, чтобы всегда выдвигать все теги, например, поместить что-то подобное в ваш .git/config:

[remote "publish"] # или как его там
    URL = ...
    нажать = + ссылки / головы / *: ссылки / головы / *
    push = + refs / tags / *: refs / tags / *

Это означает принудительное нажатие всех головок (всех ветвей) и всех тегов (если вы не хотите принудительного толкания головок, удалите префикс «+» из refspec).


Разве это не всегда делает «силовой толчок» всех голов?
Stefan Näwe

@ Стефан: Да, это так. Обновлено.
Якуб Наребски

19
«Это очень намеренное поведение, чтобы сделать push-теги явными. Push-теги обычно должны быть осознанным выбором». Я не понимаю обоснование. Можете ли вы объяснить, почему было бы плохо, если бы Git автоматически выдвигал теги?
Райан Ланди

13
@Kyralessa, в этом посте git.661346.n2.nabble.com/… Джунио С. Хамано (текущий сопровождающий Git) объясняет, почему плохо автоматически нажимать на теги.
Андре Мирас

@AndreMiras Спасибо за эту замечательную ссылку. Было бы хорошо, если бы мы могли интегрировать пост Джунио в этот ответ.
Homer6

67

Обратите внимание, что начиная с git 1.8.3 (22 апреля 2013 г.) вам больше не нужно делать 2 команды для добавления веток и затем для добавления тегов:

Новая --follow-tagsопция " " сообщает " git push" выдвигать соответствующие аннотированные теги при выталкивании веток .

Теперь вы можете попробовать при нажатии новых коммитов:

git push --follow-tags

Это не вытеснит все локальные теги, только аннотированные, на которые ссылаются коммиты, которые передаются с помощью git push.


Это было введено в фиксации c2aba15 с помощью Junio C Hamano ( gitster) :

Новая опция " --follow-tags" говорит " git push" выдвигает аннотированные теги, которые отсутствуют с другой стороны и которые могут быть достигнуты историей, которая в противном случае выталкивается.

Например, если вы используете push « simple», « current» или « upstream», вы обычно отправляете историю, ведущую к коммиту, в вашем текущем состоянии HEADи ничего больше.
С помощью этой опции вы также отправляете все аннотированные теги, которые могут быть доступны из этого коммита, на другую сторону.


Конфиг push.followTagsпозволяет включить --follow-tagsпо умолчанию (Git 2.4.1+, Q2 2015). Смотрите " Push git commits & tags одновременно "


3
Это только подталкивает все аннотированные теги. Большинство людей / проектов используют легкие теги. Таким образом, в большинстве случаев git push --follow-tagsне толкает больше, чемgit push
Ярл

3
@ Ярл да, я упомянул «аннотированный» в своем ответе. Но я действительно использовал только аннотированные теги, резервируя легкие теги для чисто внутреннего использования (то есть никогда не предназначалось для толкания в любом случае).
VonC

@VonC: Теперь есть также опция конфигурации, которая делает это значением по умолчанию, как вы отметили здесь: stackoverflow.com/a/3745250/946850
krlmlr

19

Что я обычно делаю, это:

[remote "publish"] # или как его там
    URL = ...
    нажать =:
    push = + refs / tags / *: refs / tags / *

Это означает, что это подталкивает каждую ветку, которая уже есть, плюс теги. Это не заставляет толкать, и это не толкает ветку, которую вы не нажимали вручную.


Могу ли я также поместить это в глобальный конфиг git моего пользователя? Если да, то как? Спасибо! :)
Gucki

Похоже, вы заставляете теги, но не ветки.
Адриан Ратнапала

Ну, да, и нет, я написал, что он будет выдвигать новые теги, он не будет принудительно выдвигать их, и он не будет выдвигать ветви, которые вы сами еще не выдвинули.
мат

Я попробовал предложение Якуба, но оно выдвигало ветви, которые я хотел только локально. Это предложение, мат, работает отлично. Он синхронизирует теги, но не синхронизирует ветви, если они не являются удаленными отслеживающими ветвями (т.е. он не будет выдвигать новые ветви на удаленный, но обновит их, если они уже находятся на удаленном компьютере). ПРИМЕЧАНИЕ: если у вас есть тег и ветвь с одним и тем же именем, вы получаете сообщение «соответствует более чем одной». Обратитесь к lostechies.com/jasonmeridth/2010/02/27/refspec-matches-more-than-one/ .
josephdpurcell

5

И если вы хотите принудительно извлечь все теги, вы можете установить его в конфигурации:

git config remote.origin.tagopt --tags

Из документов:

Установка этого значения в --no-tags отключает автоматическое отслеживание тегов при извлечении с удаленного компьютера. Установка этого параметра в --tags приведет к извлечению каждого тега с удаленного компьютера, даже если он недоступен с удаленных руководителей филиалов. Передача этих флагов непосредственно в git-fetch (1) может переопределить этот параметр. Смотрите опции --tags и --no-tags для git-fetch (1).


1
Вопрос был в большей степени ориентирован на «толчок», а также применим ли ваш ответ при нажатии на пульт?
A1An
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.