Tortoise Git - потерянные коммиты после извлечения привели к конфликтам

Я собираюсь ответить на ваши вопросы построчно:

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

Да, это правильно.

Теперь коллега совершал локальные действия и пытался надавить, что привело к конфликту. Она вытягивала, разрешала конфликты и потом ТОЛЬКО отправляла свои измененные файлы. В удаленном репо была еще одна фиксация, говорящая о ветке слияния с некоторыми файлами, которая эффективно отменяет мои предыдущие коммиты. Ожидается ли это?

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

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

Например, вот как слияние, приводящее к конфликтам, выглядит из командной строки:

git status

On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:

        modified:   hello.txt

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      foo.txt

Обратите внимание, что git автоматически поставил hello.txt для фиксации, потому что у него нет конфликтов. Я не использовал TortoiseGit более 1,5 лет, но, если мне не изменяет память, помещенные файлы представлены в TortoiseGit отмеченными флажками, что означает, что вы хотите зафиксировать эти файлы.

В данном случае снятие флажков с автоматически устанавливаемых флажков неверно. В основном это означает, что вы не хотите фиксировать те изменения файла, которые вы только что объединили из другой ветки (или, в вашем случае, из восходящей ветки remote/origin). По сути, это отбрасывает работу, проделанную над этими файлами.

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

Как мы должны работать локально, а затем время от времени выполнять повторную синхронизацию?

Это зависит от того, как вы и ваша команда хотите организовать рабочий процесс.

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

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

Для всеобщего блага эта стратегия, к которой я прибегнул, кажется, хорошо работает для нас.

1. Если запрос Git приводит к конфликту, разрешите конфликт локально.
2. Убедитесь, что не осталось конфликтующих файлов.
3. Сделайте Git pull еще раз.
4. Перейдите к шагу 2, если снова возникнет конфликт.

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

Изменение мышления необходимо при разрешении конфликтов, если вы пришли из SVN. В SVN конфликт слияния во время обновления не прерывает процесс обновления SVN. Клиент SVN по-прежнему будет обновлять вашу локальную копию до последней удаленной версии. В конфликтном состоянии останутся только отдельные файлы, которые вы можете разрешить (и при необходимости зафиксировать обратно).

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

В Git конфликт во время извлечения просто завершает/прерывает процесс обновления. Таким образом, если в удаленном репо было 10 коммитов, которые необходимо извлечь, и вы получаете конфликт, когда Git извлекает (и объединяет) 3-й из этих коммитов, процесс фактически прерывается. 8 удаленных коммитов НЕ находятся в вашем локальном репо (обратите внимание, что удаленный коммит, вызвавший конфликт, также не был успешно объединен, поэтому его 8 коммитов не синхронизируются локально, а не 7).

Вы разрешаете конфликты и продолжаете выполнять git pull до тех пор, пока не добьетесь успеха, что предотвращает перезапись других коммитов. Чтобы предоставить немного больше деталей из того, что я понял о git, нажатие без разрешения конфликта приведет к неправильному перемещению головы коммита удаленной ветки. например предположим, вам нужно получить 4 ревизии из репозитория Git:

A - B - C - D
            |- commit head

Теперь предположим, что у вас возник конфликт при извлечении и слиянии ревизии B. Если вы сейчас сделаете отправку на удаленный сервер (без разрешения конфликтов и выполнения git pull до успешного завершения), удаленный репозиторий теперь будет выглядеть так:

A - B - C - D
    |- E - commit head

Таким образом, несмотря на то, что коммиты C/D существуют удаленно, они не будут частью вашей сборки на основе заголовка коммита ветки. Если вы последуете совету @CupCake и отправите оставшиеся файлы, коммиты C/D станут частью коммита E. Так что это не влияет на правильность сборки. Но если вы не отправляете эти файлы после конфликта, которые вы не изменили, но Git показывался как измененные (потому что вы не разрешили конфликт и завершили успешное извлечение git), то фактически вы ведете к потерянным коммитам.