Как разрешить конфликты слияния в монорепозитории?

Есть пара типичных подходов к этой проблеме:

• Часто объединяйте изменения и используйте систему пометки функций, чтобы новые изменения можно было интегрировать, не становясь активными. Это позволяет отдельным разработчикам работать над различными аспектами функции и постепенно объединять ее, поэтому ветвь функции ограничена одним или небольшим числом разработчиков, способных разрешать конфликты по отдельности.
• Сделайте так, чтобы ветки функций работали как комбинация веток функций отдельных разработчиков, и заставьте каждого разработчика перебазировать свои собственные изменения, разрешая конфликты, а затем повторно интегрировать эти отдельные ветки разработчиков обратно в ветку функций.
• Попросите разработчиков из каждой области объединиться для работы над разрешением конфликтов.

Я лично испытал первый и последний из них, и я предпочитаю первый, но в зависимости от вашего рабочего процесса это может быть невозможно. Например, если у вас есть несколько направлений разработки (например, обслуживание и развитие), первое решение не решит всех ваших проблем, но может уменьшить их.

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

Возможный технический подход заключается в использовании git imerge и сохранении инкрементных продуктов где-нибудь в качестве ссылки, а затем разработчик возобновляет спрятанное состояние. Это, вероятно, будет сложно, хотя и возможно, но не рекомендуется.

Вот грубый, технический способ разделить разрешение конфликта слияния на две отдельные части:

1. из ветки master создайте два фальшивых коммита, один из которых содержит только изменения в backend, а другой - только изменения в frontend

2. пусть два разработчика объединят каждую ветку в feature

3. объединить feature в master

1. разделить изменения на два:

# starting situation :
*--X--*--*--Z <- master      # X is the fork point
    \                        # Z is the tip of branch master
     \
      *--*--*--T <- feature   # T is the tip of branch feature

Выполните следующие команды:

# from master, create a phony branch for backend :
$ git checkout -b backend master
$ git checkout X -- frontend/   # reset the content of 'frontend/' to its state in commit X 
$ git commit

# similarly for fontend :
$ git checkout -b frontend master
$ git checkout X -- backend/
$ git commit

Теперь у вас есть:

*--X--*--*--Z------
    \           \  \
     \           B  F  # B: tip of backend, F: tip of frontend
      \
       *--*--*--T

2. объединить две части в feature :

$ git checkout feature
# have one developper fix conflicts on :
$ git merge backend
# and a second one on :
$ git merge frontend

Примечание: слияния могут происходить в любом порядке.

Ситуация сейчас такая:

*--X--*--*--Z------
    \           \  \
     \           B  F
      \           \  \
       *--*--*--T--*--M <- feature

3. теперь вы можете объединить feature в master

Что касается ваших рабочих процессов, если работа над backend и frontend должна выполняться отдельно, вам нужно иметь какое-то правило, чтобы отразить это в ветках, управляемых вашими разработчиками.

@ bk2204 в своем ответе дает несколько указаний по этому поводу: отделите работу над бэкэндом от работы над внешним интерфейсом, объедините как можно скорее.