Результат конфликтующих веток GIT слился одновременно - PullRequest
Новая
       15

Результат конфликтующих веток GIT слился одновременно

0 голосов
/ 31 октября 2019

По большей части, мой вопрос был полностью задан и дан ответ здесь: Git Merging - что происходит с объединением двух веток одновременно Небольшая часть, которая мне интересна, - это то, что произойдет вэтот сценарий к коду Боба. В тот момент, когда он не может объединить свои изменения, потому что Алиса вошла туда первой, так что теперь его локальная ветвь Мастера не синхронизирована с веткой происхождения, он вынужден сделать извлечение или выборку, чтобы вернуть свою локальную ветвь обратно в линиюс происхождением / мастер. Что происходит с его локально совершенными изменениями? Конечно, если он снова отстранится от мастера, разве его изменения теперь не будут перезаписаны локально?

[ПРАВИТЬ] Я мог бы сказать, что намного лучше. Я думаю, что мне нужна ясность в том, что в связанном сценарии оба пользователя работают над одним файлом, Боб вносит изменения в строку 2 файла. Алиса также вносит изменения в строку 2 в своей ветке. Алиса получает свое слияние первым. Боб фиксирует все свои изменения локально и пытается объединить свои изменения с источником / мастером. Это не удается, так как источник / мастер изменился, поэтому он вынужден снова вытащить из источника / мастера. Как только он это сделает, в его локальной мастер-копии есть изменения Алисы. Теперь он вынужден снова совершить коммит, чтобы передать свои изменения своему новому локальному мастеру, после чего он может выполнить слияние с источником / мастером.

Правильно ли я понял?

1 Ответ

0 голосов
/ 01 ноября 2019

В тот момент, когда он не может объединить свои изменения, потому что Алиса вошла туда первой ...

Вот где твой вопрос идет не так. Он может слиться, потому что у него еще нет слияния Алисы. То, что он не может сделать успешно - потому что Алиса бьет его ударом - это git push его слияние с другим Git.

После неудачного git push Боб должен отступить назад и запустить git fetch. Теперь Боб имеет (и должен наблюдать) слияние Алисы. Если Боб решит перешагнуть через все, он может в своем репозитории переопределить слияние Алисы - в конце концов, репозиторий Боба - это Боб, как и хотелось бы Бобу, но если он использует механизмы по умолчанию,Git обеспечивает разделение работы, он:

  • перебазирует свои коммиты, чтобы прийти после слияния Алисы (отбрасывая его слияние в процессе), или
  • отменить его текущее слияние (этонемного хитро, но Боб может использовать git rebase -i, чтобы сделать это легко), а затем повторно объединить слияния Алисы, или
  • самый простой метод: объединить его слияния с объединением Алисы.

Все три метода имеют тенденцию к успеху автоматически или имеют конфликты, в которых Боб, вероятно, лучше всего подходит для определения правильного разрешения. Результатом является то, что Боб может теперь git push успешно, без использования --force.

Давайте снова рассмотрим все три случая:

  1. Перебазировать при слиянии Алисы.

    Здесь Боб решает заменить свои старые серии коммитов (которые идут параллельно с работой Алисы) новыми и улучшенными перебазированными коммитами (которые приходят после работы Алисы). Поскольку они начинаются с модифицированной базы кода Алисы, они сохраняют изменения Алисы.

  2. Полностью откажитесь от текущего слияния (MB), оставив его серию параллельных коммитов с Алисой, но нетКоммит слияния в конце.

    Здесь Боб объединяет свою серию коммитов с результатом слияния Алисы. Поскольку в ее результат слияния включен ее код, в результат слияния Боба также включен код Алисы, если только Боб не удалит его по какой-либо причине.

  3. Слияние со слиянием Алисы.

    Здесь Боб сохраняет MB (из связанных вопросов и ответов), но добавляет новое слияние, которое объединяет MB с MA. Это объединяет изменения Алисы с изменениями Боба, поэтому работа Алисы включена в ее окончательный результат.

Разница между этими тремя вариантами заключается в конечном графике и наборе коммитов: какТрудно ли это прочитать (как коммиты, так и график), как сложно использовать их в будущем для обнуления при любых введенных ошибках и так далее. Есть аргументы для всех трех процессов и аргументы против всех трех. Алиса и Боб должны согласиться с любой процедурой, которую они используют, но это соглашение не является частью инструментов, предоставляемых Git.

...