Как провести решение конфликтов в двух ветках при слиянии посредством через Pull Request?

Question

[Ку куруза]

Ситуация: есть ветка master, есть ветка dev, в которые изменения добавляются путем pull request. Напрямую пушить нельзя.
Каждый программист создает свою новую ветку от ветки develop. Пусть ветка программиста называется feature.

Решив задачу, программист пушит ее в origin/feature и создает pull request из origin/feature в origin/dev. При открытии PR могут быть конфликты веток dev и feature.

Чтобы таких конфликтов не было. Перед отправкой в origin/feature программист мерджит dev в feature и решает конфликты. После пушит в origin/feature и создает PR origin/feature -> origin/dev.

При PR из orgin/dev в origin/master возникают конфликты, которые решили раньше (при PR feature->dev)
Как такие конфликты решить? Нельзя смерджить в dev master и запушить в origin/dev и повторить PR.

Comments

[Lynn «Кофеман»]

Выкинуть такое странное воркфлоу и взять нормальное git flow или github flow

Ну непонятно откуда взялась ветка develop

[Ку куруза]

Lynn «Кофеман», опечатался, исправил develop -> dev

[Lynn «Кофеман»]

> При открытии PR могут быть конфликты веток dev и feature.
rebase

> При PR из orgin/dev в origin/master возникают конфликты
Что-то вы делаете не так. Откуда в мастере взялись изменения?

[Ку куруза]

Lynn «Кофеман», в мастере нет изменений, есть изменения в dev (после feature -> dev).
До PR из feature в dev ветки dev и master были идентичны.

[Lynn «Кофеман»]

Ку куруза, тогда там не может быть конфликтов

[Сергей Кузнецов]

Ку куруза, чтобы не было конфликтов с мастером, вы должны подгружать из него изменения тоже, а не только из dev

Answer 1

[Дмитрий]

Странно что вам в master еще не прилетела какая-нибудь недоделанная фича... ;)

Давайте ответим на вопрос: Для чего вам нужен dev? На самом деле не для разработки, как вы думаете, а для тестирования фич. Правильно?
В связи с этим ваша проблема решается следующими шагами:
1. Переименовать dev в stage (test и т.п.) и забыть что там ведется разработка.
2. Все фича-ветки должны создаваться от master.
3. После завершения фичи она мержится в stage и проверяется. Можно даже без PR, т.к. теперь никакой хлам принципиально не может попасть в master.
4. Если все в порядке, из фича-ветки делаете PR в master.
5. stage можно иногда просто сносить и пересоздавать с головы master, чтобы история была красивее. ;)

PS: Это какая-то мания у команд - иметь ветку dev... "Мы же разработкой занимаемся - у нас должна быть ветка dev!". Так что ли?
Не всякому проекту нужна ветка dev! Точнее так - если у вас есть ветка dev, то у вас должна быть и ветка release и вы должны обновлять приложение большими релизами с определенной подготовкой к ним.