Как правильно решить конфликты в dev ветке для двух веток в разработке?
Работаем над проектом по схеме master+dev. Разработка любой задачи начинается с создания ветки от master . После того, как разработка завершена, ветка заливается в dev для тестирования. Если всё хорошо, то эта же ветка (не dev) заливается в master.
Из-за этой схемы dev постепенно отстаёт от master и опережает его по своим каким-то коммитам. Работа ведётся на GitLab.
Иногда возникают ситуации, что ведётся разработка в одной ветке одним разработчиком, в другой другим. К примеру, получилось так, что был затронут один и тот же файл, тогда производится решение конфликта, но решение конфликта создаёт Merge ветки dev в конфликтующую ветку. Соответственно, при попытке в дальнейшем слить эту ветку с master подтягиваются куча не нужных коммитов из dev, которые на мастере не нужны. Возможно ли как-то избегать таких ситуаций? Как решать такие ситуации, если был таким образом решён конфликт и ветка ускакала вперёд на 10-20 коммитов?
у вас плохая система (хотя я сам в таком проекте 4 месяца просидел)
дев - это для разработки, а не для тестирования . один разраб - один дев . чужие девы никто себе не мержит, если уж очень надо - через временную ветку с нужными коммитами
а мастер разделить на две части - staging и production
Круто, у каждого разработчика кроме ветки с фичей еще и ветка dev. Ну ок, но дальше ведь опять тоже самое, только теперь проблемная ветка называется staging, а не dev.
Gitflow вроде не плохая система, повсеместно используемая, чуть ли не стандарт, где dev - общая ветка для интеграции всех разработчиков и соответственно интеграционные тесты запускаются именно на ней.
Vitsliputsli, как называть без разницы, важно разделение рабочего кода, и кода который уже идет в интеграцию. то что в staging - это уже код с нужными фичами, который только багфиксится
Antonio Solo, правильно. Только эту функцию уже выполняет dev, поэтому важно как автор с ней работает, просто ввод новой ветки ничего не даст, если он с ней будет работать как привык.
1. Работая над долгоживущей веткой, разработчик просто должен периодически из мастера мержить в свою ветку изменения (можно использовать ребейз или мерж). Тогда при пуше назад в мастер конфликтов либо не будет, либо будут минимальны.
2. Правильная архитектура проекта позволяет уменьшить конфликты, так как код должен быть разделен функционально, и две фичи с разным функционалом конфликтовать не должны
3. Почитайте про гит-флоу, оно не совсем об этом, но позволяет значительно улучшить вид репозитория и истории коммитов
Ответвляйте всегда от ветки dev. И туда же заливайте написанные фичи. После тестирования лейте dev в master. В мастер всегда только протестированный dev и ничего более.
По сути у вас будет dev будет веткой staging (как посоветовал Antonio Solo )
при попытке в дальнейшем слить эту ветку с master подтягиваются куча не нужных коммитов из dev, которые на мастере не нужны
А не лейте туда лишнее. Разраб отпочковался от dev/staging и работает. Он может десяток подветок у себя сделать и сотни коммитов, но заливать обратно пусть будет добр аккуратные коммиты.
Первый способ как раз у нас был, как Вы описали. Ветки создавались от dev, потом dev заливался в мастер, но с ростом команды такой способ перестал подходить, потому что в dev мог оказаться не протестированный функционал другого разработчика и мог попасть в прод. После этого перешли на работу с ветками от мастера, и каждый заливает свой функционал в дев для тестирования, потом после теста эту же ветку заливаем в мастер. Судя по-всему действительно, этот способ тоже уже переросли и пора переходить, как написал выше Antonio Solo, на мастер staging и production, и чтобы у каждого разработчика была своя dev ветка.
был затронут один и тот же файл, тогда производится решение конфликта, но решение конфликта создаёт Merge ветки dev в конфликтующую ветку.
Не создает, конфликтующие ветки сами по себе, а конфликт решайте в ветке dev. При создании веток релизов из dev, этого было бы достаточно. Но, в вашем случае: сливаете первую ветку в master - тут все ок, а вот вторая будет опять конфликтовать, но уже с master, это решается мержем обновленного master в эту ветку. И да, вполне возможны расхождения dev и master, если 2 мержа были выполнены по-разному, поэтому мержите master в dev после таких манипуляций.
Сложный
