Я использую git около года и хотел бы использовать теги, ну, теги коммитов в разных версиях. Я нашел много информации о командах, которые нужно использовать для работы с тегами, но я хотел бы знать, зачем вообще использовать теги, если я могу просто создать новую ветку с именем, 1.1.0и мне не придется затуманивать свой разум целым новый набор команд git?
Должно быть много веских причин для тегирования, а не для ветвления, но я хотел бы знать, в чем заключаются эти преимущества.
Ответы:
Теги в основном используются для будущих ссылок на конкретную версию проекта путем добавления тегов к фиксации. Конечно, вы всегда можете использовать ветки, но если вы сильно меняете версии, у вас останется много неиспользуемых или редко используемых веток.
Фактически, теги в любом случае являются ветвями без ветвей, просто добавляя способ ссылки на конкретную версию проекта для уменьшения сложности.
Изменить: вот хороший способ использовать git, который я использую для всех своих проектов.
Принимая во внимание, что вы можете создать ветку с именем «1.0.0» - вы или кто-либо с правами на фиксацию также можете просто нажать на эту ветку (намеренно или нет) и изменить значение 1.0.0.
Вы не можете сделать это с тегом, если вы его создали - вот и все; Тег 1.0.0 означает именно это и не может быть изменен * .
Это основное практическое различие между тегом и веткой.
* Вы можете удалить и воссоздать тег, тем самым изменив тег, но, конечно, не случайно.
Я обычно использую рабочий процесс, включающий как теги, так и ветки. Теги хороши для маркировки выпущенного кода или заметных сборок разработки. Филиалы удобны для отслеживания всех изменений, относящихся к конкретной версии.
Вот хорошая запись об этом типе рабочего процесса: http://nvie.com/posts/a-successful-git-branching-model/
Ветвь и тег - это одно и то же (указатель на фиксацию, также известную как «ref» ), за исключением того, что ветвь автоматически перемещается к следующей фиксации, в то время как метка всегда остается 1 в той же фиксации.
При создании релиза вы обычно хотите отметить «снимок» кода, из которого он был создан, и вы хотите, чтобы он оставался отмеченным таким образом, даже когда вы продолжаете развивать код, поэтому вы должны использовать тег.
Если вы попытаетесь использовать для этого ветку, она может непреднамеренно перейти в другую фиксацию, из которой не был собран релиз .
+1 Если, конечно, тег не удалите.
ПРИМЕЧАНИЕ. Я понимаю, что это старый вопрос, но я чувствовал, что сходство (и одно важное различие) между ветвями и тегами не было отражено в других ответах так четко, как могло бы быть.
git commitобновляет заголовок извлеченной ветки, чтобы ссылаться на новую фиксацию, да, но никакая другая ветка «автоматически» не переходит к следующей фиксации. Вы должны пояснить первый абзац своего ответа.
.git\refs\heads, содержащий хеш фиксации. Сами коммиты не «помнят», какая ветвь их создала. Это отличается, например, от Mercurial, где информация о ветке может быть записана в метаданные фиксации.
Вы используете теги, чтобы отмечать важные коммиты в истории. «Это была точная фиксация, которую мы использовали для этой версии в тот дождливый четверг, когда сломался сервер сборки». Если вы используете ветку вместо тега, вы никогда не узнаете, какую именно фиксацию вы использовали. Вы знаете только «Мы выпустили версию 1.1.0 где-то в этой ветке», если вы вручную не запишите точный хеш для этого коммита, поэтому вы в первую очередь используете теги :)
В дополнение к другим ответам вот мои 2 цента.
Краткий ответ: используйте теги для версий выпуска
Длинный ответ: я считаю, что использование тегов специально для управления версиями лучше, чем использование веток. Если вам нужно обновить релиз, просто отойдите от помеченного коммита и после того, как вы закончите работу над этой веткой (скорее всего, с веткой исправления), создайте новый тег во главе этой новой ветки с новой версией. Затем слейте эту ветку обратно в master / develop, потому что вам действительно не следует менять версию выпуска, если только это не исправление, которое, вероятно, следует объединить обратно в исходный код. Затем удалите эту ветку, так как она больше не нужна. Если вам нужно применить другое исправление к этой новой версии, повторите те же действия.
Обратитесь к разделу следующей статьи, в котором показано, как объединить исправление с рабочим процессом Git автора - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2