Работаем по такой схеме.
мастер — прод
qa — тестовый стенд
в ветке фичаА разработчик меняет много кода в течение дней 3 и меняет файл "фф" и сливает в ветку qa
в ветке ФичаБ другой разработчик меняет много кода и меняет файл "фф", но пока сливать в qa не может, т.к. фича не готова и просто берет изменения из qa которые в себе
уже содержат ветку ФичаА и тут конфликт.
Здравствуйте, merge, Вы писали:
M>Привет
M>Работаем по такой схеме. M>мастер — прод M>qa — тестовый стенд
заведите еще одну ветку между qa и master, куда будете вливать только проверенные фичи
Здравствуйте, merge, Вы писали:
M>в ветке фичаА разработчик меняет много кода в течение дней 3 и меняет файл "фф" и сливает в ветку qa M>в ветке ФичаБ другой разработчик меняет много кода и меняет файл "фф", но пока сливать в qa не может, т.к. фича не готова и просто берет изменения из qa которые в себе M>уже содержат ветку ФичаА и тут конфликт.
Ну и что?
M>Вопрос, как такого избегать?
Не надо пытаться избегать. Конфликты неизбежны. Один файл или нет — неважно, но на одном файле на близких строках конфликты видны.
Надо по факту появления конфликта — лечить его. Как именно — определять по месту.
В общем случае для определения конфликтов есть компиляция и тесты.
Здравствуйте, merge, Вы писали:
M>мастер — прод M>qa — тестовый стенд
M>в ветке фичаА разработчик меняет много кода в течение дней 3 и меняет файл "фф" и сливает в ветку qa M>в ветке ФичаБ другой разработчик меняет много кода и меняет файл "фф", но пока сливать в qa не может, т.к. фича не готова и просто берет изменения из qa которые в себе M>уже содержат ветку ФичаА и тут конфликт.
M>Вопрос, как такого избегать?
Чего имено избежать? Конфликта? Так если в итоге редактирование файла нужно для обеих фич, то конфликт будет всё равно.
Как раз и хорошо, что конфликт будет устранён ещё в процессе реализации ФичаБ, а не позже, когда код ещё больше разойдётся.
Правильная организация кода позволяет уменьшать количество таких конфликтов. "Правильность" тут для каждого проекта своя, хотя есть и общие вещи, которые описаны в куче литературы (всякие SRP, LSP, low coupling/high cohesion и всё вот это вот).
Но конфликты всё равно могут быть, это неизбежно. Скажем, для фичаА нужно добавить к какой-то функции Параметр1, а для ФичаБ в ту же функцию нужно доавить Параметр2.
Такой конфликт будет неизбежен и может быть решён только вручную.
Здравствуйте, merge, Вы писали:
M>в ветке фичаА разработчик меняет много кода в течение дней 3 и меняет файл "фф" и сливает в ветку qa M>в ветке ФичаБ другой разработчик меняет много кода и меняет файл "фф", но пока сливать в qa не может, т.к. фича не готова и просто берет изменения из qa которые в себе M>уже содержат ветку ФичаА и тут конфликт.
M>Вопрос, как такого избегать?
Если я правильно понял что вы пишете, избегать тут получится только на уровне планирования — просто не работайте над задачами так, что несколько девелоперов лезут в один код, разнесите эту работу по времени. В том, что вы описали, никакой проблемы нет. Разработчик ФичаБ вытянул к себе правки из qa, увидел конфликт, починил его у себя в ветке, продолжает работу.
В ответах выше мне кажется ваш вопрос непраивльно поняли. При параллельной работе над одним кодом конфликты в любом случае будут, мёржить руками в любом случае придётся — хоть там gitflow, хоть что.
