Осваиваю git, решил поиграться с ветками и создать для отдельной логики в приложении свои ветки. Удаленный репозиторий хранится на Bitbucket. Собственно, проблема вот в чем: с каждой ветки я делаю pull request на master, далее на одной любой ветке merge и после этого на других ветках начинаются конфликты, потому что на них висит прошлая версия репозитория.
Понятно, что конфликты можно решить руками, но проблема в том, что чем больше веток, тем больше конфликтов, а значит на каждый релиз будет уходить достаточно много времени только на решение конфликтов.
Как такие проблемы обходят в командной работе? Возможно есть какие-либо структуры веток?
После того как определенная логика будет реализована, делаете merge с мастером, а ветку по сути можно удалять. Не пойму какие у Вас конфликты возникают, Вы постоянно переключаетесь между ветками что ли?
el_script: конечно.
Что у нас было: gitflow, 5 разработчиков. Пул-реквесты, тянущиеся до недели. Деплой раз в неделю.
Что мы сделали: покрыли самые рискованные/важные классы юнит-тестами.
Как сейчас: все работают в одной ветке, назовем её mainline. Перед написанием когда желательно удостовериться что этот кусок кода покрыт тестами. Вместо feature-branch у нас feature-bits/feature toggle. То есть любое изменение оборачивается в условие "если этот флаг включен в файле, тогда выполняй новый код". Соответственно если проходят все тесты, изменение становится сразу доступным на DEV и STG. Релизиться можно от любого состояния этой главной метк, прошедшего тесты (у нас – ежедневно). По-умолчанию флаг выключен на PRD. Как только QA скажут, что все работает хорошо (а они могут посмотреть как код работает с включенным флагом и без и сравнить), то мы включаем флаг на PRD, где он живет неделю, затем мы вычищаем код. Ревью проходит перед релизом на прод двумя релиз инженерами которые проверяют что все условия соблюдены: флаг можно выключить, новый код покрыт тестами. Если что-то пошло не так на проде, флаг выключается (а не версия откатывается) за секунды.
Ну и ссылки:
* paulhammant.com/2013/04/05/what-is-trunk-based-dev...
* www.amazon.com/dp/0321601912?tag=contindelive-20
* martinfowler.com/articles/continuousIntegration.html
* martinfowler.com/bliki/FeatureToggle.html
