Изменения редакции ветки / главного тега с помощью Git - PullRequest
6 голосов
/ 06 августа 2009

Я пытаюсь придумать хорошую систему управления выпусками в сочетании с практикой пометки тегами с номерами версий - например, 1.0. Любые изменения после этого тега будут увеличиваться, например, 1,0-1, 1,0-2 и т. Д.

Однако, если я создаю новую ветку из master для версии 1.0, а затем переключаюсь на эту ветку и отмечаю ее 1.0, система, как упомянуто выше, работает нормально. Дополнительные исправления ошибок в этой ветке показывают, как и ожидалось, 1.0-1, 1.0-2

Тем не менее, любая работа над мастером, если только я не добавлю метку мастера после первого коммита после создания ветки 1.0, также будет показывать тот же прирост: 1,0-1, 1,0-2

Конечно, хэши sha1 будут уникальными, но в итоге я получу одинаковые ревизии / приращения как от master, так и от branch.

Есть ли способ вообще не помечать мастера, когда я просто помечаю ветки? Есть ли лучший способ сделать это? Прямо сейчас мой единственный вариант после создания ветки 1.0 - сделать один незначительный коммит на master, а затем повторно пометить его для 1.1-dev или что-то в этом роде.

Затем повторите для каждого выпуска.

Однако, если ветвь затем будет помечена снова, скажем, для версии 1.0.1, это также похоже на то, что она также пометит master, так как это произошло в первую очередь?

Ответы [ 3 ]

5 голосов
/ 06 августа 2009

В Git вы не отмечаете ветви. Вы помечаете коммиты. Если вы хотите «пометить» ветку, вы уже получили это: название ветви. :)

Да, git describe дает вам идентификаторы фиксации, такие как 1.0-2-g1ab3183, но это не теги! Тегирование выполняется с помощью git tag (кто бы мог догадаться), а теги, созданные с помощью git tag, являются основой для идентификаторов фиксации, которые создает git describe.

4 голосов
/ 07 августа 2009

В Git вы не можете сказать, что некоторый коммит принадлежит какой-то ветви. Одиночный коммит может быть на нескольких ветках; если коммит А является одним из предков кончика ветви, мы говорим, что он находится на данной ветви.

Как сказал Bombe в Git, вы не помечаете ветки. Вы помечаете коммиты. В теге Git есть просто (аннотированный) указатель на коммит.

В вашем случае, я думаю, что-то вроде следующего

                        /-- [v1.0]
                       v
---.---.---.---X---.---A     <-- master
                         \ 
                           \-.---B     <-- maint

Давайте зафиксируем 'X', указав тег 'v1.0'. Этот коммит как на ветке 'master', так и на ветке 'maint'. Если вы запустите " git description " поверх коммита 'A' (верхняя часть ветки 'master'), вы получите нечто вроде v1.0-2-g9c116e9. Если вы запустите «git description» поверх коммита 'A' (ветка 'maint'), вы получите что-то вроде v1.0-2-g3f55e41 (по крайней мере, с конфигурацией git-description по умолчанию). Обратите внимание, что этот результат немного отличается. v1.0-2-g9c116e9 означает, что мы выполняем коммит с отсортированным идентификатором SHA-1 9c116e9, 2 коммита после тега v1.0. Нет тега v1.0-2!

Если вы хотите, чтобы тег отображался только в ветви 'master', вы можете создать новый коммит (например, только обновить информацию о версии по умолчанию / резервной версии в GIT-VERSION-FILE) после точки ветвления ветви 'maint'. Если вы помечаете коммит в ветке 'maint', например, 'v1.0.3`, он будет виден только из' maint '.

НТН

2 голосов
/ 06 августа 2009

В git тег - это псевдоним для определенного коммита, а не для ветви.

Теги и ветки независимы.

Так что, если вы хотите оформить небольшую версию на определенную версию, вы можете сделать:

git checkout -b new_branch_name commit_id

Или,

git checkout -b new_branch_name tag_name

Оба являются просто эквивалентными способами ссылки на конкретный коммит.

Внесите свои изменения, зафиксируйте их и пометьте коммит второстепенной рев.

Затем вы можете даже удалить ветку, которую вы отметили.

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