Как вы используете теги в Git для управления версиями программного обеспечения

Question

Мы используем git для управления нашим проектом, у нас есть ветка для каждого: DEV инсценировка производство

Я хочу использовать теги git для управления версиями программного обеспечения. Насколько я вижу, если я нахожусь на ветке и добавляю несколько коммитов, мне нужно запустить: git tag 1.0

Замена 1.0 на любой номер версии, до которой мы дошли, тогда я могу вставить тег, используя: git push origin 1.0

И я могу обновить ветку: git push --tags

Но как мне теперь повторно использовать тег? Если я добавлю больше кода в мой локальный репозиторий и хочу, чтобы он был версии 1.0 легко? Или вы просто добавляете новый тег вроде 1.1?

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

Наконец, что произойдет, если мы случайно нажмем наш код, не запустив git tag, чтобы пометить коммиты.

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

Answer 1

Но как мне теперь повторно использовать тег?Если я добавлю больше кода в мой локальный репозиторий и хочу, чтобы он был версии 1.0 легко?Или вы просто добавляете новый тег вроде 1.1?

Вы можете удалить тег с помощью git tag -d 1.0, а затем удалить его на сервере с помощью git push origin :refs/tags/1.0.

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

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

Я почти уверен, что второй из вас, кто нажмет тег, получит ошибку.Попробуйте сами, чтобы увидеть, что происходит:

git checkout -b testbranch
git tag test1
git push origin tag test1
git tag -d test1
touch testfile
git add testfile
git commit -m "Added testfile"
git push origin testbranch
git tag test1
git push origin tag test1

Наконец, что произойдет, если мы случайно нажмем наш код без запуска git tag, чтобы пометить коммиты.

Вы должнынажмите ваши теги после того, как вы нажали коммитов.Вы не можете делать и то и другое одновременно (git push --tags не выдвигает коммиты, только теги).Если вы сначала нажмете метки, пульт будет иметь свисающие ссылки, пока вы не нажмете коммиты.Таким образом, вы должны делать

git push origin master
git push origin --tags

или подобное, в зависимости от вашей ситуации.

Я не совсем понимаю, как работают теги, я думал, что они будут работать, как тегипост в блоге или что-то в этом роде - вы можете пометить множество разных коммитов одним и тем же тегом, использовать тег и т. д. вроде как ветка.пометить некоторые коммиты как «специальные».Чаще всего это используется для обозначения выпусков, поэтому вы всегда можете вернуться назад и посмотреть, что именно было в этом выпуске, если клиент сообщит об ошибке.

Answer 2

У меня раньше была похожая проблема.Вот что я нашел полезным:

• Ответ VonC на мой похожий вопрос

Answer 3

Просто отвечая на заглавный вопрос, я придумала полупрофессиональное решение (которое может быть полезно некоторым людям), которое автоматически помечает мой код тегом git version, на который я указываю, поэтому я не приходится (не забывать) вручную обновлять номер версии при каждой сборке. В настоящее время я работаю в небольшой группе (<5 разработчиков), и наше управление конфигурациями все еще находится в стадии разработки. Но пока это не созреет, это решение, которое работает для меня. </p>

Вид высокого уровня, это шаги:

• Я написал скрипт, который запрашивает git для моего текущего тега версии (, используя начальные части этого ответа ).

• Автоматически генерировать заголовочный файл, который #define содержит извлеченную версию и ее части.

• Сначала поместите команду оболочки в мой make-файл верхнего уровня, который запускает этот скрипт (поэтому файл заголовка генерируется каждый раз, когда я что-то строю).
• Соответствующий код #include s этого заголовочного файла (который является , а не частью хранилища), и вуаля, версия автоматически включается без какого-либо ручного ввода от меня.

Более подробно:

Сценарий

В настоящее время я использую схему управления версиями из трех чисел, major.minor.build , где build может быть строкой (например, v1.8.3b). Обратите внимание, что использование echo -e для печати новых строк работает для меня, но, возможно, printf является лучшим вариантом

# queries git for the version tag I'm currently pointed at. Throughout SO there
# are different versions of this command, but this one works for me. And in fact
# all my tags are annotated, so I could just use "git describe"
VERSION=`git describe --tags`

# replace all the '.' with ' ', then split the array based on the spaces.
# Obviously this will have its limitations if there are spaces in your
# version tag, or maybe even wildcard characters, but that should never
# be the case for me
VER_ARRAY=(${VERSION//./ })
# pull out the major, minor, and build components. These can be used to
# pre-processor check different versions of my code for certain compatibility,
# should the need arise
V_MAJOR=${VER_ARRAY[0]}
V_MINOR=$(VER_ARRAY[1]}
V_BUILD=${VER_ARRAY[2]}

# all of my build tags are preceded by a 'v', so remove that simply by taking
# the substring starting at position 1
V_MAJOR=${V_MAJOR:1}

# define the path and header file
VERSION_HEADER=./path/to/codeVer.h

# write these to file. > creates the file and >> appends to the file
echo -e "// Auto-generated version header on " `date` "\n\n" > $VERSION_HEADER
echo -e "#define MY_CODE_VERSION \""$VERSION"\"\n\n" >> $VERSION_HEADER
echo -e "#define MY_CODE_MAJOR "$V_MAJOR >> $VERSION_HEADER
echo -e "#define MY_CODE_MINOR "$V_MINOR >> $VERSION_HEADER
echo -e "#define MY_CODE_BUILD \""$V_BUILD"\"\n\n" >> $VERSION_HEADER

Makefile

В верхней части моего make-файла у меня есть $(shell ./genVer.sh). Это говорит make для запуска команды оболочки, ./genVer.sh - это путь и имя скрипта. Лучшим способом сделать это было бы сделать цель для сценария .PHONY, а затем поместить эту цель в качестве необходимого условия для соответствующих целей, но у меня есть много целей, и это было одним ударом.

код

Теперь во всех соответствующих исходных / заголовочных файлах у меня просто есть

#include "codeVer.h"
....
#ifndef MY_CODE_VERSION
  // although if codeVer.h cannot be found we will get a fatal error before
  // this warning
  #warning "Unable to find code version, defaulting to v0.0.0"
  #define MY_CODE_VERSION "v0.0.0"
#endif

Теперь, когда я make извлекаю текущую версию, генерируется заголовок, мой код #include с файлом, и я получаю правильный номер версии, не выполняя никакой ручной работы. Обратите внимание, что это работает не только для последней версии, если вы извлечете старый тег, это также будет работать (если, конечно, изменения, реализующие это, были в этой версии).

У этого есть свои недостатки. Наиболее заметно

1. Вы должны собрать что-то , чтобы получить версию. На самом деле я добавил codeVer.h в список .gitignore, так как не хочу, чтобы он отслеживался в репо. Это означает, что вы можете передать свой код кому-то, у кого этот файл отсутствует, и они не будут знать, какая это версия. Но если они используют git (как они должны делать!), И они git pull/clone ваши вещи, все теги все равно будут с ним.
2. make clean также генерирует этот файл (который кажется нелогичным), но если вы сделали это правильно и использовали цель .PHONY, как описано выше, это не будет проблемой.
3. Вероятно, о других, о которых я сейчас не думаю.

Answer 4

Большой источник информации о тегах находится на gitref.org

Не пытайтесь повторно использовать номера версий. Лучше всего просто перейти на 1.1 или 1.0a. Это подробно обсуждается на справочной странице .

На ваш вопрос:

Наконец, что произойдет, если мы случайно нажать наш код без запуск тега git для коммитов?

Вы можете пометить старые коммиты, добавив ссылку на команду в команду:

git tag 1.1 HEAD~3