Разрешение части конфликта в файле в GIT

Question

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

1. В одном может быть 2 или более конфликтовфайл.
2. каждый конфликт должен быть разрешен разным пользователем.
3. каждый разработчик должен войти в этот репозиторий для разрешения конфликта слияния.
4. скажем, foo.c имеет 3 конфликта слияния
5. один пользователь разрешает один конфликт в foo.c и сохраняет в графическом инструменте слияния

Теперь GIT распознает это как «git add», хотя в других частях по-прежнему существуют конфликтыфайл.Затем, если другой разработчик делает «git mergetool foo.c», он не вызывает foo.c для конфликтов.

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

Answer 1

Этот сценарий на самом деле не имеет смысла ...

Во-первых, если есть конфликт, то этот конфликт существует только для одного коммита слияния, который еще не существует! (Он все еще находится на компьютере пользователя, возможно, в индексе, но, конечно, даже не в его локальном дереве).

У других пользователей вообще нет конфликта, пока они не произойдут слияние или перебазирование.

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

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

Другими словами, ситуация, которую вы, похоже, описываете, выглядит следующим образом: (Поправьте меня, если я ошибаюсь):

1. У нас есть три разработчика, Чарли, Джон и Мэтт, которые все работают над основной ветвью, которая находится в коммите aaaaaaa.
2. Все они также работают в «нестабильной» ветке, которая находится в коммите bbbbbbbb, который отличается от «master».
3. Все они, одновременно , решают, что они должны объединить 'нестабильную' ветку в 'master', по отдельности.
4. Все они, одновременно , осознают, что у них есть коммиты, которые они не могут согласовать.

В идеале, что должно быть сделано в этой ситуации, это то, что «нестабильный» должен быть объединен любым разработчиком, который знает, как сделать слияние. Возможно, они решат объединить несколько коммитов за раз, вместо того, чтобы напрямую объединить две головы, или, возможно, они решат перебазировать всю вещь - что угодно, но только один разработчик должен сделать это.

The more frequently this is done, the easier the merge/rebase operation will be.

Оставшиеся разработчики смогут использовать коммит слияния.