Git. Создание тэгов и работа с ними.

-a

В тэги не коммитят - это не свн. Тэг - только лишь метка. git tag «name»

Создание «легковесного» тега:

git tag tag-label

Создание «аннотированного» тега

git tag -a tag-label -m message

http://git-scm.com/book/en/Git-Basics-Tagging

хм.. ну я в общем-то полагал что и с git, тэги остаются тэгами.

хорошо, перефразирую вопрос: есть master. я хочу на его основе создать ветку под именем 'release-0.1.0', с которой будут работать. т.е. на основе 0.1.0 потом создам в 0.1.1, 0.1.2, итд..

подскажите, как такое проделывается?

git checkout -b release-0.1 вероятно

Это назывется бранч. man git branch.

спасибо. ушел читать.

http://git-scm.com/book/ru - очень советую.

спасибо огромное!

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

позвольте последний вопрос, чтоб не создавать еще одну тему..

из того что я прочел, я понял следующее: для того чтоб создать branch 'release-0.1.0', я должен создать его на основе 'master'. далее, специфичные для 'release-0.1.0' изменение я провожу именно в этом branch`е. далее, когда я захочу создать 'release-0.1.1', я должен его именно на основе 'release-0.1.0' ? так?

но я что-то запутался между branch`ами и tag`ами %)

или для релизов, мне достаточно создавать tag`и на основе branch`а в текущий момент?

спасибо.

Погугли «Магия Git»

как задать имя создаваемому тегу?

git tag NAME

Как коммитить в конкретный тэг?

никак. метка присваивается коммиту, а не наоборот.

все добровольно. для релизов не обязательно создавать бренчи, достаточно тегов. бренчи нужны если ты хочешь развивать две ветки релизов параллельно например, в одной ветке ты делаешь релизы 0.1.1, 0.1.2, 0.1.3, а в другой уже работаешь над 0.2.x

p.s. внутри бренчей можно сколько угодно тегов создавать. например, в ветке 0.1 можно наделать теги 0.1.1, 0.1.2, 0.1.3 потом в ветке 0.2 можно наделать тегов 0.2.1, 0.2.2, ...

далее, когда я захочу создать 'release-0.1.1', я должен его именно на основе 'release-0.1.0' ? так?

да

но я что-то запутался между branch`ами и tag`ами %)

branch — это ветвь дерева коммитов. tag — это некоторая метка, которой можно обозначить отдельный коммит, к примеру, для удобства его поиска

не надо ветки создавать. тегуй отдельные коммиты в master.

Вот еще неплохая статья про теги: http://gitready.com/beginner/2009/02/03/tagging.html. С наглядной схемой.

А книжку http://git-scm.com/book уже посоветовали

а как же тогда мне одновременно работать над 0.1.1 и 0.2.1 ? ведь это разные ветки.

а как же тогда мне одновременно работать над 0.1.1 и 0.2.1 ? ведь это разные ветки.

Одновременно никак. Надо переключаться между ветками с «git checkout ветка». Переключаться можно только если в текущей ветке нет изменений. Поэтому перед переключением изменения придётся или комитить или прятать (git stash)

git help tag

//KO

У меня другой вопрос, если я сделал комит и у меня мастер этот коммит, могу ли я подвинуть мастер назад не удалив коммит?

Можешь.

Всё упирается в то, что ты подразумеваешь под словом «работать». Если тебе их компилировать надо, тогда смотришь хеш коммита и его чекаутишь, дальше у тебя в дереве твой коммит, который соответствует тегу. Если ты будешь что-то менять и коммитить, тогда, вроде как ветки нужны, но мне не понятно нафига такое нужно. Зачем менять 0.1.1 если уже есть 0.2.1? 0.1.1 старая версия тогда, нафига фиксить в ней, если можно зафиксить в 0.2.1 и выпустить 0.2.2?

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

• Например, старая версия может быть сертифицирована, а новая - еще нет.
• Более того, новая версия может вообще не запуститься на старом наборе библиотек. Никто не станет обновлять весь тулчейн ради какого-то фикса.

А так как пользователи обычно платят деньги, то в интересах программиста фиксить не только в мастере, но и в ветках старых релизов.

то в интересах программиста фиксить не только в мастере, но и в ветках старых релизов.

ЧТД. Бранчи создаются по факту поддержки, а не изначально. То есть, ТС'у нужны просто теги.

В гите не принято думать о релизах. Вместо этого думайте о фичах и багах.

Под каждый баг/каждую фичу - своя ветка. Как работа над ними заканчивается - ветки вливаются в основную.

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

Вот на мой взгляд маст-рид статья - http://habrahabr.ru/post/106912/

Есть такая вещь как профессиональное программирование.

дальше не читал.