Ситуация - в команде какая то ее часть - пусть это для примера будут 2 человека - назовем их Девелопер 1 и Девелопер 2 - работают в проекте одновременно с одними файлами, но задачи при этом разные. Оба на фронтенде, но у одного может быть множество мелких задач, у другого одна большая, или как угодно, как будут эти задачи поставлены в соотв-и с тикетами.
Есть ветка master и ветка dev. Девелопер 1 ведет свою ветку - пусть так и наз-ся dev-1, Девелопер 2 соот-но ведет ветку dev-2. Версии для dev- веток все обязательно с альфа- суффиксами. Когда выкатывается версия на тестирование, она получает версию бета, а ветка данного девелопера сливается с dev веткой, тикет получает статус UAT и изменения применяются на developer сервере.
Как только тестеры оттестировали, и поменяли статус тикета на UAT-Done, изменения должны быть как можно скорее пойти в продакшн. Т.е. ветка dev сливается с master, присваивается стабильная версия, без бета, и идет в прод.
В этой схеме - как я уже сказал, задачи бывают слишком различны, и девелоперы не должны и не ждут один одного, чтобы слить ветки, и это постоянно приводит к конфликтным ситуациям, как в смысле с гит так и с коллективом.
Дело в том, что только что вот начали так работать, до этого все было в мастере, бета и альфы так и так не заливались в прод.
Кто опытный и проходил через эти проблемы, как решили, как работаете сейчас?
UAT - User Acceptance Testing. Причем здесь тестирование в QA?
Пока разработчики "работают в проекте одновременно с одними файлами" конфликты будут всегда, как бы вы не работали с git (но разумеется лучше взять какой-то стандартный workflow, а не изобретать велосипеды).
Можно попробовать следующее: правильно распределяйте задачи, чтобы снизить кол-во конфликтов; попробуйте правильно организовать проект, скорее всего в нем нарушение принципов SP. И, отлаживайте интеграцию, внедряйте Continuous Integration, разработчики должны как можно чаще интегрироваться, а если заранее известно, что будут правки на одном и том же поле, то они должны договариваться заранее.
