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

Ответ 1

У меня была аналогичная проблема. Вот что я нашел полезным:

• Ответ VonC для моего аналогичного вопроса

Ответ 2

Но как я могу снова использовать тег? Если я передам больше кода в мой локальный репозиторий и хочу, чтобы он был версией 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, чтобы пометить коммиты.

Вы должны нажать теги после того, как вы нажмете коммиты. Вы не можете делать оба одновременно (git push --tags не нажимает коммиты, только теги). Если вы сначала нажимаете теги, на пульте дистанционного управления будут висячие ссылки, пока вы не нажмете фиксации. Поэтому вы должны делать

git push origin master
git push origin --tags

или аналогичный, в зависимости от вашей ситуации.

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

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

Ответ 3

Отличный ресурс для информации тега находится на gitref.org

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

По вашему вопросу:

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

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

git tag 1.1 HEAD~3

Ответ 4

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

Высокий уровень, это следующие шаги:

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

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

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

Подробнее:

Script

В настоящее время я использую 3-мерную схему управления версиями: 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

Файл make

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

Код

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

#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 - файл, и я получаю правильный номер версии без какой-либо ручной работы. Обратите внимание, что это не просто работает для последней версии, если вы проверите старый тег, это тоже будет работать (при условии, конечно, изменения, которые были реализованы в этой версии).

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

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