Проблем при необходимости внесения небольших изменений нет. Делается обычно 3 коммитами
* от тега с версий отцепляется ветка, изменяются номера версий на следующую младшую + SNAPSHOT (мы используем Maven)
* в этой ветке делается исправляющий коммит (или он забирается из ветки develop с помощью git cherry-pick)
* убирается из версий слово SNAPSHOT,
Работа по изменению номеров версий выделена в отдельные задачи Jenkins, разработчику надо лишь сделать исправляющий коммит.
git rebase делается в рамках работы над задачей
* разрабтчик отцепляет ветку от develop
* делает коммит
* тесты, тесты, тесты
* перед слиянием в ветку develop выполняется git rebase develop для получения изменений от других разработчиков, разрешаются конфликты.
* выполняется git merge в ветке develop
По проблемам автора статьи habrahabr.ru/post/123700/
1. Мне нужно знать на какой ветке было зафиксировано ab3e2afd для того, чтобы знать, включать ли его в описание изменений будущего релиза.
Мы описываем изменения по задачам. Все изменения всегда фиксируются лишь в ветке develop. Лишь багофиксовые изменения фиксируются в несколько веток, тогда задачу привязываем к нескольким версиям.
2. Мне нужно знать какое изменение было первым в ветке «release», потому что я хочу начать новую тематическую ветку с этого изменения в качестве начальной точки так, чтобы я всегда был в курсе происходящего в главной ветке насколько это возможно, и быть уверенным, что смогу выполнить чистое слияние в главную ветку и выпустить релиз.
У нас главная ветка — develop, мы постоянно делаем в нее слияние. Релиз выпускается не слиянием в главную ветку кучи коммитов и последующим разгребанием проблем, а отцеплением от всегда стабильной (ну почти :)) develop. Выпуск версии — посмотреть, что все тесты проходят и запустить задачу в Jenkins. которая проставит версию.
3. Мне нужно знать где началась ветка «topic» для того, чтобы я мог сложить все патчи вместе и отослать их своим коллегам для рецензии.
Для выполнения отдельной задачи создается патч и коллегам высылается ветка, которую надо сравнивать лишь с develop. Тем более мы пользуемся gitlab для рецензирования, достаточно указать ветку с изменениями и ветку, изменения относительно которой надо посчитать.
Изначально мы вообще на Subversion начинали.
Рассматривали Git vs Mercurial, победил Git в силу большей распространенности в нашей компании и того, что не нашли ни одного аргумента против Git
Прокомментирую за wolonter насчет настоящей параллельности (я также работаю в этой компании):
Приближенно: Время выполнения тестов=Общее время тестов / Количество серверов
Сейчас у нас Время выполнения тестов 2 ч.
Чтобы сделать прохождение тестов за 15 минут надо всего лишь увеличить количество серверов в 8 раз.
Также для тестов на Selenium основная загрузка не из-за серверной части приложения, а из-за браузера, который очень интенсивно потребяет память и CPU.
Предвосхищая вопрос о headless браузере, скажу, что у нас динамическое приложение со сложной клиентской логикой на JavaScript.
Я также причастен к этой системе, могу прокомментировать:
* В сборке для develop константа «develop» зашита в настройке job, сборка инициируется по коммиту.
* В сборках веток используется параметр с нетривиальным именем BRANCH :), сборка запускается вручную.
Полный ответ —
Мы используем модель git flow (можно посмотреть nvie.com/posts/a-successful-git-branching-model/)
Проблем при необходимости внесения небольших изменений нет. Делается обычно 3 коммитами
* от тега с версий отцепляется ветка, изменяются номера версий на следующую младшую + SNAPSHOT (мы используем Maven)
* в этой ветке делается исправляющий коммит (или он забирается из ветки develop с помощью git cherry-pick)
* убирается из версий слово SNAPSHOT,
Работа по изменению номеров версий выделена в отдельные задачи Jenkins, разработчику надо лишь сделать исправляющий коммит.
git rebase делается в рамках работы над задачей
* разрабтчик отцепляет ветку от develop
* делает коммит
* тесты, тесты, тесты
* перед слиянием в ветку develop выполняется git rebase develop для получения изменений от других разработчиков, разрешаются конфликты.
* выполняется git merge в ветке develop
По проблемам автора статьи habrahabr.ru/post/123700/
1. Мне нужно знать на какой ветке было зафиксировано ab3e2afd для того, чтобы знать, включать ли его в описание изменений будущего релиза.
Мы описываем изменения по задачам. Все изменения всегда фиксируются лишь в ветке develop. Лишь багофиксовые изменения фиксируются в несколько веток, тогда задачу привязываем к нескольким версиям.
2. Мне нужно знать какое изменение было первым в ветке «release», потому что я хочу начать новую тематическую ветку с этого изменения в качестве начальной точки так, чтобы я всегда был в курсе происходящего в главной ветке насколько это возможно, и быть уверенным, что смогу выполнить чистое слияние в главную ветку и выпустить релиз.
У нас главная ветка — develop, мы постоянно делаем в нее слияние. Релиз выпускается не слиянием в главную ветку кучи коммитов и последующим разгребанием проблем, а отцеплением от всегда стабильной (ну почти :)) develop. Выпуск версии — посмотреть, что все тесты проходят и запустить задачу в Jenkins. которая проставит версию.
3. Мне нужно знать где началась ветка «topic» для того, чтобы я мог сложить все патчи вместе и отослать их своим коллегам для рецензии.
Для выполнения отдельной задачи создается патч и коллегам высылается ветка, которую надо сравнивать лишь с develop. Тем более мы пользуемся gitlab для рецензирования, достаточно указать ветку с изменениями и ветку, изменения относительно которой надо посчитать.
Рассматривали Git vs Mercurial, победил Git в силу большей распространенности в нашей компании и того, что не нашли ни одного аргумента против Git
Приближенно: Время выполнения тестов=Общее время тестов / Количество серверов
Сейчас у нас Время выполнения тестов 2 ч.
Чтобы сделать прохождение тестов за 15 минут надо всего лишь увеличить количество серверов в 8 раз.
Также для тестов на Selenium основная загрузка не из-за серверной части приложения, а из-за браузера, который очень интенсивно потребяет память и CPU.
Предвосхищая вопрос о headless браузере, скажу, что у нас динамическое приложение со сложной клиентской логикой на JavaScript.
* В сборке для develop константа «develop» зашита в настройке job, сборка инициируется по коммиту.
* В сборках веток используется параметр с нетривиальным именем BRANCH :), сборка запускается вручную.