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

Question

[Анатолий Равеский]

В общем хочу организовать работу лвл-дизайнеров. Но при этом не хотелось бы посвящать их в способы разрешения конфликтов слияния. Даже если получилось бы обучить их быстро, не хочется даже доверять это дело им, чтобы потом искать в чем причина странных ошибок)
Я хочу чтобы они просто использовали pull-push опции и на этом их роль окончилась. Конфликты хочу разрешать сам.

Есть идеи:

• Лвл-дизайнер работает в отдельной ветке, я делаю мердж их ветки в feature, а потом наоборот (я чувствую кринж).
  
• Вариант аналогичный предыдущему, но я прошу дизайнера не работать, перебазирую его ветку (-да, публичную) относительно feature. Ну а потом он вытягивает изменения и продолжает.
  

Что-нибудь из этого адекватно/есть еще какие-нибудь варианты?)

Comments

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

Конфликты возникают только при слиянии. Если хочется оградить дизайнера от разрешения конфликтов, значит нужно делать слияние самому. Только и всего.
Но дизайнер не сможет обойтись только лишь командами pull и push, понадобится цепочка подлинней: fetch branch add commit push.

1. Дизайнер загружает обновления с главного репозитория git fetch
2. Создаёт новую тематическую ветку на основе актуального состояния проекта
git checkout -b feature123 origin/main
3. Работает, коммитит, отправляет свою ветку в общий репо
4. Если общий репо на гитхабе, то создаёт там Pull Request и идёт курить.
5. Дальше в процесс вступаешь ты. Скачиваешь его ветку себе, разрешаешь конфликты, делаешь слияние в main в общем репо.

Всё. Если дизайнер хочет продолжить работу, то он повторит все пункты заново с созданием новой тематической ветки, так как старая уже не актуальна и её лучше сразу удалить.
Pull тоже не нужен, так как он эквивалентен fetch+merge, что чревато появлением конфликтов, а тебе этого не хочется)

[Анатолий Равеский]

Сергей Кузнецов, открыли для меня merge requestы)

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

Анатолий Равеский, в GitLab название адекватное, Мёрдж-реквесты понятней звучат чем пул-реквесты.

Answer 1

[Aetae]

Я не гуру git, мб есть способы и по-проще, но как бы я делал: создавал бы отдельную ветку под merge request(дизайнеру дать простенький скрипт для этого).

Т.е. есть ветка dev, дизайнер от неё делает свою ветку feature как обычно, потом когда пришло время делать MR - скриптом делается ещё одна ветка от feature условно вида feature_to_dev_<date>, и уже от неё делается MR в dev, далее:
а) есть конфликты - шлётся тебе уведомление, ты правишь конфликты и мержишь,
б) нет - автомержится и удаляется.
Дизайнер в любом случае в это время продолжает спокойно работать в своей feature.

Обратно dev в feature, если надо, дизайнер вливает через простой MR, и если есть конфликты - тыкает тебя, тут уж никак без остановки работы. Но, по идее, частых конфликтов быть не должно если регулярно вливали его работу в dev.