Почему я должен использовать теги вместо веток выпуска / бета для управления версиями?


114

Я использую git около года и хотел бы использовать теги, ну, теги коммитов в разных версиях. Я нашел много информации о командах, которые нужно использовать для работы с тегами, но я хотел бы знать, зачем вообще использовать теги, если я могу просто создать новую ветку с именем, 1.1.0и мне не придется затуманивать свой разум целым новый набор команд git?

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

Ответы:


96

Теги в основном используются для будущих ссылок на конкретную версию проекта путем добавления тегов к фиксации. Конечно, вы всегда можете использовать ветки, но если вы сильно меняете версии, у вас останется много неиспользуемых или редко используемых веток.

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

Изменить: вот хороший способ использовать git, который я использую для всех своих проектов.


Хех (: Это действительно отличный рабочий процесс, охватывающий все возможные решения.
Хакан Дерьял,

да, я видел метод nvie раньше и был весьма сбит с толку. Тем не менее, я стремлюсь реализовать его, как только пойму. Я думаю, что с тегом вы не можете случайно изменить код, зафиксировать и при этом остаться в той же версии. С ветками это может случиться непреднамеренно. Теги кажутся более безопасным способом пометки релизов.
wufoo

2
Для меня красота метода nvie заключалась в том, что мне не нужно было изначально его понимать. Я мог просто найти раздел о том, что я хотел сделать, и ввести команды. Через несколько раз это стало естественным, и в течение нескольких дней я танцевал вокруг веток как профессионал!
Киллрой

Надеясь понять подход gitflow, просто применяя его вслепую, вы упустите все упрощения, которые вы могли бы применить к нему в своей ситуации. И gitflow действительно не подходит для большинства команд: либо слишком сложный, либо слишком простой.
toolforger

151

Тег неизменен .

Принимая во внимание, что вы можете создать ветку с именем «1.0.0» - вы или кто-либо с правами на фиксацию также можете просто нажать на эту ветку (намеренно или нет) и изменить значение 1.0.0.

Вы не можете сделать это с тегом, если вы его создали - вот и все; Тег 1.0.0 означает именно это и не может быть изменен * .

Это основное практическое различие между тегом и веткой.

* Вы можете удалить и воссоздать тег, тем самым изменив тег, но, конечно, не случайно.


18

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

Вот хорошая запись об этом типе рабочего процесса: http://nvie.com/posts/a-successful-git-branching-model/


18

Ветвь и тег - это одно и то же (указатель на фиксацию, также известную как «ref» ), за исключением того, что ветвь автоматически перемещается к следующей фиксации, в то время как метка всегда остается 1 в той же фиксации.

При создании релиза вы обычно хотите отметить «снимок» кода, из которого он был создан, и вы хотите, чтобы он оставался отмеченным таким образом, даже когда вы продолжаете развивать код, поэтому вы должны использовать тег.

Если вы попытаетесь использовать для этого ветку, она может непреднамеренно перейти в другую фиксацию, из которой не был собран релиз .


+1 Если, конечно, тег не удалите.

ПРИМЕЧАНИЕ. Я понимаю, что это старый вопрос, но я чувствовал, что сходство (и одно важное различие) между ветвями и тегами не было отражено в других ответах так четко, как могло бы быть.


Уважаемый @downvoter, есть ли конкретная причина для голосования против?
Бранко Димитриевич

Я не отрицал ваш ответ, но что вы имеете в виду, говоря «ветка автоматически переходит к следующей фиксации»? Ветви автоматически не переходят ни в одну фиксацию. Запуск git commitобновляет заголовок извлеченной ветки, чтобы ссылаться на новую фиксацию, да, но никакая другая ветка «автоматически» не переходит к следующей фиксации. Вы должны пояснить первый абзац своего ответа.
Зубная щетка

1
@Toothbrush Конечно, это то, что я имел в виду под "автоматически перемещается". Однако ветка на самом деле не «владеет» никакими коммитами, она даже не указывает на набор коммитов, она просто указывает на одну фиксацию (а остальные могут подразумеваться, иногда неточно, путем обхода графика фиксации). В git ветка - это просто однострочный файл .git\refs\heads, содержащий хеш фиксации. Сами коммиты не «помнят», какая ветвь их создала. Это отличается, например, от Mercurial, где информация о ветке может быть записана в метаданные фиксации.
Бранко Димитриевич

Да, но многие люди этого не знают - особенно новички, которые не понимают, что существует множество способов, которые предлагаются в Интернете для работы с Git.
Зубная щетка

6

Вы используете теги, чтобы отмечать важные коммиты в истории. «Это была точная фиксация, которую мы использовали для этой версии в тот дождливый четверг, когда сломался сервер сборки». Если вы используете ветку вместо тега, вы никогда не узнаете, какую именно фиксацию вы использовали. Вы знаете только «Мы выпустили версию 1.1.0 где-то в этой ветке», если вы вручную не запишите точный хеш для этого коммита, поэтому вы в первую очередь используете теги :)


4
Я думаю, он имел в виду создать ветку с именем 1.1.0 и больше ее не использовать, поэтому она будет представлять проект в указанной версии.
Hakan Deryal

2

В дополнение к другим ответам вот мои 2 цента.

Краткий ответ: используйте теги для версий выпуска

Длинный ответ: я считаю, что использование тегов специально для управления версиями лучше, чем использование веток. Если вам нужно обновить релиз, просто отойдите от помеченного коммита и после того, как вы закончите работу над этой веткой (скорее всего, с веткой исправления), создайте новый тег во главе этой новой ветки с новой версией. Затем слейте эту ветку обратно в master / develop, потому что вам действительно не следует менять версию выпуска, если только это не исправление, которое, вероятно, следует объединить обратно в исходный код. Затем удалите эту ветку, так как она больше не нужна. Если вам нужно применить другое исправление к этой новой версии, повторите те же действия.

Обратитесь к разделу следующей статьи, в котором показано, как объединить исправление с рабочим процессом Git автора - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

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