Моя организация рассматривает возможность перехода от SVN к Git. Один аргумент против переезда заключается в следующем:
Как мы делаем управление версиями?
У нас есть дистрибутив SDK, основанный на платформе NetBeans. Поскольку ревизии SVN являются простыми числами, мы можем использовать их для расширения номеров версий наших плагинов и сборок SDK. Как мы справимся с этим, когда переедем в Git?
Возможные решения:
- Использование номера сборки от Hudson (проблема: вы должны проверить Hudson, чтобы соотнести это с реальной версией Git)
- Ручное повышение версии до ночной и стабильной (проблема: кривая обучения, человеческая ошибка)
Если кто-то еще сталкивался с подобной проблемой и решил ее, мы хотели бы услышать, как.
version-control
git
svn
builds
versioning
Эрленд
источник
источник
git
тег после каждой успешной сборки? Это дает дополнительное преимущество, так как позволяет четкоgit
определить, какие коммиты имеют проблемы со сборкой или неудачные тесты, поскольку они остаются без тегов.Ответы:
Используйте теги, чтобы отметить коммиты с номерами версий:
Нажмите теги вверх по течению - это не сделано по умолчанию:
Затем с помощью описания команды:
Это дает вам строку в формате:
источник
git describe --long --tags --dirty --always
. «Грязный» скажет вам, были ли локальные изменения, когда «описать» было сделано (то есть он не может полностью описать состояние репо). «Всегда» означает, что вы не получите ошибку, если нет тегов. Это откатится на хеш коммита. Таким образом, вы можете получить76001f2-dirty
в качестве примера. Очевидно, что видеть «грязный» означает, что кто-то напутал.HEAD
какv2.5
, вы также можете интерпретировать это как начало цикла выпуска 2.5, затем пометитьv2.5-release
или что угодно.--match
опцию:git describe --long --tags --dirty --always --match 'v[0-9]\.[0-9]'
Это придумало несколько проектов для меня. Лучшее решение, которое у меня было до сих пор, - это создать номер версии, подобный этому:
xy <количество коммитов> .r <git-hash>
Как правило, он генерируется нашей системой сборки с использованием комбинации некоторого статического файла или тега для получения основных номеров ревизий
git rev-list HEAD | wc -l
(что было быстрее, чем при использованииgit log
), иgit rev-parse HEAD
. Рассуждение было следующим:Номер 2 невидим для большинства людей, но он действительно важен и действительно сложен с распределенным контролем версий. SVN помогает с этим, давая вам один номер ревизии. Оказывается, что количество коммитов настолько близко, насколько вы можете получить, и при этом волшебным образом решаете и №4. При наличии ветвей это все еще не уникально, и в этом случае мы добавляем хеш, который также аккуратно решает # 3.
Большая часть этого заключалась в размещении через пипс Python. Это гарантировало, что
pip install
это может быть немного странно во время параллельной разработки (то есть пакеты от людей из разных ветвей будут смешиваться, но детерминированным образом), но после слияний все будет разобрано. За исключением наличия открытой перебазировки или поправки, это работало довольно хорошо для вышеуказанных требований.Если вам интересно, мы решили поставить r перед хешем из-за некоторой странности с тем, как упаковка Python обрабатывает буквы в номерах версий (то есть ae меньше 0, что означает «1.3.10.a1234» < «1.3.10» <«1.3.10.1234»).
источник
Это может быть немного излишним, но я дам вам знать, как мы это делаем.
Мы используем ветвящуюся структуру, очень похожую на эту .
Хадсон строит наши ветки "разработка" и увеличивает номера сборки, начиная с 0. Номер сборки уникален для каждого проекта и помечается тегами в управлении версиями. Причина в том, что вы можете точно сказать, например, из какой сборки разработки произошла 42 ветка (каждый проект может иметь несколько параллельных ветвей разработки, поскольку в каждом проекте может быть несколько команд, работающих над различными аспектами проекта).
Когда мы решаем, что конкретная сборка достаточно хороша для выпуска, коммит, инициировавший эту сборку, помечается номером версии релиза, который определяется маркетингом. Это означает, что команда разработчиков не заботится о том, какой будет окончательный номер версии, и маркетинг может свободно перемещаться по номерам версий по своему усмотрению. Окончательный номер версии и номер сборки присутствуют в выпущенном продукте.
Пример: 2.1.0 сборка 1337
Это означает, что для конкретного выпуска продукта вы можете указать, какая из последних команд работала над ним, и вы можете запросить git для всех коммитов, которые были выпущены для диагностики проблемы, если вам нужно.
источник
Версии идентифицируются хэшированием SHA1-хэшей всех файлов в хранимом дереве каталогов во время регистрации. Этот хеш хранится вместе с хешами родительских проверок, чтобы можно было прочитать всю историю.
Взгляните на процесс использования 'git-description' с помощью GIT-VERSION-GEN и на то, как вы можете добавить это через процесс сборки, когда помечаете свой релиз.
Вот хороший блог, который дает пример того, как получить то, что вы хотите:
http://cd34.com/blog/programming/using-git-to-generate-an-automatic-version-number/
источник
У Джона Перди правильная идея.
git flow
также упрощает фактическое управление этими филиалами, а управление филиалами является аргументом для перехода кgit
.Давайте начнем с основным выбегом
git
, так как вы пришли сsvn
-До-git
точки зрения. Учтитеgit
следующее:Выше вы переходите
master
наdevelop
(обозначается\
) и переходитеdevelop
наfeature
ветку. Мы объединяем эти ветви обратно (обозначается/
) с помощью commits (-
) вдоль ветви. (Если коммита нет, но слияние направо, есть.
индикаторы, показывающие, что-
следующий коммит следующий).Достаточно просто. Что если у нас есть исправление в нашем основном выпуске?
Выше,
develop
разветвленный отmaster
. Обнаруженная ошибкаmaster
была исправлена путем ветвленияmaster
, исправления и слияния сmaster
. Затем мы слилисьmaster
вdevelop
, а затемdevelop
вfeature2
, который свернул новый код изhotfix
этих веток.При слиянии
feature2
обратноdevelop
, его история включает в себяdevelop
сhotfix
. Аналогично,develop
объединяетсяfeature2
с новым кодом изmaster
, так что объединение сdevelop
обратноmaster
будет происходить без проблем, так как оно основано на этом коммите вmaster
то время - как если бы вы разветвились сmaster
этого момента.Так вот еще один способ сделать это.
Ваши 1.0 релизы получить tagged-
1.0.1
,1.0.2
,1.0.3
и так далее.Теперь вот хитрость: вы обнаружили ошибку в 1.0, и она затрагивает 1.1, 1.2 и 1.3. Чем ты занимаешься?
Вы отключаете свой последний или самый ранний поддерживаемый выпуск и исправляете его. Затем слить свой новый
hotfix
филиал в1.3
й в1.2
,1.1
и1.0
. Не переходите от каждой ветки версии обслуживания; не сливаются1.0
вmaster
или сливатьсяmaster
обратно в1.0
. Возьмите однуhotfix
ветку и объедините ее со всеми ветками вашей версии. Если будут конфликты, это скажет вам; проверьте ваш код, чтобы убедиться, что изменения верны (git diff
это ваш друг).Теперь это конкретное изменение применяется везде. Род разветвленный, но все в порядке. Это не случайно. Тег в
1.3
голову, 1.3.17, объединить его в каждый прогресс особенность-в-разветвленного с1.3
, и двигаться дальше.git flow
Расширение помогает управлять этим обслуживание, функцией и ветвью исправлений для вас. Как только вы отключите рабочий процесс, это будет тривиально и избавит вас от проблем с управлением исходным кодом.Я видел, как это делалось в командах программистов, но я сам не работал так глубоко как программист, так что я все еще сам разбираюсь в повседневной работе.
источник
Pro Git в разделе 7.2 «Атрибуты Git» в «Ключевом слове» Часть расширения содержит хороший пример использования грязных и чистых фильтров для генерации ключевых слов в стиле RCS. Вы можете использовать ту же технику для встраивания some-version-string в код, отформатированный и рассчитанный в соответствии с вашими правилами . Вы все еще можете использовать
git describe
в качестве отправной точки, но у вас есть возможность преобразовать в любую более подходящую форму и получить из v2.5-14-feebdaed, например, clean 2.5.14.источник
git describe
выводит имя тега, если--long
оно не было передано или нет коммитов с момента последнего тега, так что он уже совершенно чистый. Если бы вы не меняли значения по умолчанию, это дало бы вам именно то, что вы хотели.