Задать вопрос

Поддержка production branch и merge отдельных коммитов в GIT?

Здравствуйте!


Наша команда немного в вынужденном режиме переходит на Git с SVN («спасибо» Atlassian!). В целом со всем в процессе миграции мы разобрались и продолжим работу в Git с понедельника. Но, как обычно, есть один нюанс.


В SVN у нас в trunk содержалась почти промышленная версия. Разработку фич вели в отдельных ветках (branches) и после тестирования интегрировали в транк, большинство ошибок правили в 1-2 коммита в транке (кроме нетривиальных). Багфиксы проверялись на основе сборок из транка. Также у нас была промышленная ветка, отпочкованная от trunk в которую мержились багфиксы и фичи по мере их готовности и созревания в trunk. Как правило, исправления ошибок мержились в течение 0-2 дней, фичи обычно отстаивали подольше до недели, чтобы выявлять всякие интеграционные моменты.


Возможно это было благодаря выборочному мерджу коммитов из транка в продакшн ветку. В TortoiseSVN можно было легко посмотреть незамерженные коммиты, выбрать готовые и замерджить. Естественно мы старались максимально сохранять естественный порядок, но не всегда это возможно и целесообразно.


Проблема в том, что в Git нет по сути нормального механизма для такого ведения продакшн бранча. Простой merge или rebase вливает все коммиты. Это идеально для фич, но не для поддержания промышленной ветки где необходимы вливания выборочных коммитов. Есть конечно git cherry-pick, но создается ощущение что это второсортный механизм. По нему не очень много информации и я нигде не встретил его упоминания в различных популярных туториалах.


Какие у кого есть соображения по данному поводу? Просьба комментировать только по сути, менять стратегию работы с ветками на ходу мы не готовы.
  • Вопрос задан
  • 3682 просмотра
Подписаться 3 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 3
Mendel
@Mendel
PHP-developer
Обычная стратегия это: «одна фича — одна ветка». Ну или группировать их осмысленными блоками, которые деплоятся одновременно.

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

Вот здесь есть немного по переупорядывачиванию коммитов. Может что-то придумаете более удобное для Вас.
git-scm.com/book/ru/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D0%B5%D1%80%D0%B5%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8
Ответ написан
Комментировать
webus
@webus
Golang | Python | NodeJS | Java
Сделайте ветку production, или master, ну или trunk уж тогда :)
Ответ написан
mrakolice
@mrakolice
Посмотрите в сторону Mercurial. На мой взгляд, он более удобен, чем Гит и позволяет делать как раз именно то, что Вы желаете.
Для хостинга можно использовать bitbucket.org, в качестве клиента советую TortoiseHg, потому что клиент от Atlasian ИМХО недоработан.
Однако будьте готовы к распространенным неочевидным проблемам.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы