Удалить / минимизировать конфликты Git слияния

Question

Я пытаюсь найти способ полностью удалить или минимизировать конфликты слияний в Git для следующего сценария:

switch(value)
{
    case OLD_CASE_1:
    case OLD_CASE_2:
    case NEW_CASE_1:
    case NEW_CASE_2:
    case NEW_CASE_3:
    case NEW_CASE_4:
        return true;
    default:
        return false;
}

Для каждого нового случая я создаю ветку, в которую добавляю только случай, относящийся к этой ветке. (Например, feature/new-case-x содержит только case NEW_CASE_X:).

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

Answer 1

Короткий ответ - нет.Как отметил R Саху в комментарии , Git не имеет представления о семантике текста, который он объединяет.Он просто рассматривает это как набор строк.Если при объединении двух разных наборов изменений линии перекрываются или примыкают, возникает конфликт слияния.Например, учитывая:

      case OLD_CASE_1:
      case OLD_CASE_2:
+     case NEW_CASE_1:
          return true;

против

      case OLD_CASE_1:
      case OLD_CASE_2:
+     case NEW_CASE_2:
          return true;

Git обычно объявляет конфликт здесь.Если бы этот код Go, а не C ++, Git был бы «более прав» в том, что это настоящий конфликт, поскольку Go не имеет автоматического провала (или, что эквивалентно, имеет эквивалент C ++ по умолчанию break; перед каждым *).1012 *), то есть в C ++ семантика должна была бы возвращать true only для одного нового случая, и больше не для OLD_CASE_2.

Теперь, если вы находитесь вДля группы, которая предпочитает перебазировать вытащить запросы, ваш автоматический перебазирование будет проходить гладко , если NEW_CASE_1 PR принят и объединен сначала и , вы создаете свой второйPR на первый и вы перебазируете каждый из ваших оставшихся PR на принятых PR по порядку.Это сложнее и может привести к гораздо большей переработке, если ваши PR должны быть приняты в каком-то другом порядке по какой-то причине, но иногда это довольно приятно.Однако, хотите ли вы и / или ваша группа сделать это, вопрос гораздо важнее.

Answer 2

Одним из способов будет немедленная регистрация / продвижение с меткой маркера после создания указанной тестовой ветви.

Создание метки маркера может быть таким же тривиальным, как комментарий или пара комментариев, поэтому можно было бы избежать необходимости в цикле тестирования перед продвижением. Возможно, используйте название ветки, чтобы «украсить» комментарий. Я сразу имею в виду это! Поскольку в этом маленьком окне одновременно не создаются две новые тестовые ветви, у каждой из них теперь есть место для написания кода, который должен быть бесконфликтным.

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