с дополнительными ветвями
После того, как 0,59 отклонится от 0,58, вы можете использовать отдельную ветку «release» для изменения номера версии в 0,58. Каждая версия (кроме самой последней) будет иметь свою собственную ветку «релиз», которая содержит только слияния из базовой ветки и изменения, которые обновляют внешний номер версии. Структура ветки может выглядеть примерно так:
A--------o--B 0.58-release
/ /
...--o--o--o--o--o--o--o--o 0.58
\ \ \ \
\ \ \ \ C 0.59-release
\ \ \ \ /
o--o--o--o--o--o--o--o--o--o--o--o 0.59
\ \
o--o--o 0.60
- A обозначает программное обеспечение «0.58 beta9»
- B обозначает программное обеспечение «0.58 rc1»
- 0.58 содержит изменения, которые еще не были выпущены
- C обозначает программное обеспечение «0.59 beta1»
- 0.59 содержит изменения, которые еще не были выпущены
- 0,60 еще не полностью обновлен с 0,59
Или, если вы очень строги в том, чтобы вносить изменения только в A, B, C и т. Д., Которые изменяют внешний номер версии (без существенных изменений кода, они относятся к «базовым» ветвям: 0,58, 0,59 и т. Д.) ), тогда можно было бы обойтись без «релизных» веток. Вместо этого вы можете использовать отдельную HEAD или временную ветвь (удаляемую после того, как релиз версионирован), чтобы зафиксировать обновление внешней версии и сохранить его в теге.
A B
/ /
...--o--o--o--o--o--o--o--o 0.58
\ \ \ \
\ \ \ \ C
\ \ \ \ /
o--o--o--o--o--o--o--o--o--o--o--o 0.59
\ \
o--o--o 0.60
- A обозначает программное обеспечение «0.58 beta9» и является тегом 0.58-beta9
- B обозначает программное обеспечение «0.58 rc1» и является тегом 0.58-rc1
- C обозначает программное обеспечение «0.59 beta1» и является тегом 0.59-beta1
Как Git делает это
Вы также можете посмотреть, как Git выполняет собственные версии.
Для сборок, сделанных из рабочего дерева Git, номер версии генерируется из вывода git describe HEAD. Makefile знает, какие файлы необходимо перекомпилировать / перестроить, если номер версии изменяется, и он всегда запускает сценарий GIT-VERSION-GEN , чтобы убедиться, что он имеет самый последний номер версии. Номер версии доступен в Makefile путем включения сгенерированного файла версии. Он передается в файлы C по аргументу компилятору (-DGIT_VERSION=…) и подставляется в сценарии с помощью sed .
Существуют некоторые положения для переопределения номера версии, «записанного» в сборке, но обычно они существуют только для сборок, выполненных вне рабочего дерева (например, сборка, сделанная из дерева, извлеченного из файла tar).
Смешивание изменений версии-строки с другими изменениями
В своем приложении к вашему вопросу вы утверждаете, что вам нужно изменить номер версии во время разработки. Во-первых, я думаю, что описанная мной и seh схема ветки «0.58-release» все еще может работать для вас. Просто потребуется больше дисциплины, чтобы отделить ваши изменения. Если вы думаете о * -релизных ветках как «выпущенных для внутреннего тестирования», а не просто «выпущенных для клиентов (или для внешнего тестирования)», то это все равно имеет смысл. Всегда выполняйте разработку в базовой ветке (например, «0.58») и всегда объединяйте базовую ветвь с веткой релиза (например, «0.58-релиз») перед выполнением сборки, для которой потребуется определенный номер версии (всегда собирайте из такой объединенная ветка выпуска).
Если вы настаиваете на внесении изменений номера версии и (не-слияния) изменений кода в одну и ту же строку истории, то мне кажется, что у вас не будет иного выбора, кроме как иметь дело с конфликтом при слиянии (если вы не идете с git cherry-pick (для Дэмиена Уилсона или сценарием автоматического редактирования, нацеленным на git rebase -i).
Если ваши «файлы версий» только содержат информацию о версиях, вы можете упростить разрешение конфликтов, используя .gitattributes, чтобы пометить файл Version.cpp как неотключаемый.
.gitattributes в каталоге, который содержит Version.cpp
/Version.cpp -merge
Пометка (как и merge=binary) всегда будет вызывать конфLict, если файл отличается между объединенными ветвями. Версия рабочего дерева после слияния будет по умолчанию версией из ветви, которую вы извлекли (а не из ветви, которую вы объединяете), так что вы можете просто git add Version.cpp && git commit завершить объединение (при условии, что все остальные конфликты также разрешаются).