Кровавый случай потери кода из-за неправильного использования git merge

оригинал:Кровавый случай потери кода из-за неправильного использования git merge@blog.23lab.com

задний план

Несколько лет назад большое количество команд менялось.git,gitВозможности нативных библиотек и веток значительно повышают удобство управления кодом, а масштабное использование локальных библиотек и веток приводит к частым слияниям между кодами, с чем наша команда уже сталкивалась ранее.git mergeЕсли в дальнейшем код утерян, производительность такова, что какие-то изменения вносит разработка А, а после промежуточной последовательностиcommit, merge,push, и в итоге некоторые изменения пропали, заходим в историю коммитов, а соответствующей записи об изменении нет. Совершив сравнение снова и снова, вы всегда найдете определенное время.merge, но это не может объяснить, почему он потерян.В конце концов, ради страховки я обычно выбираю несравненное, чтобы сделать полное сравнение, чтобы убедиться, что все потерянные коды восстановлены.

Я снова столкнулся с этой проблемой сегодня, и на этот раз это было еще более странно.Когда я искал, почему я его потерял, другой коллега отправил код, и потерянный код вернулся.В то время я думал только об одном слове в своем голова, то есть: ад. Но успокойтесь и подумайте, вероятность того, что git потеряет код, очень мала, должно быть, наша позиция неверна. Итак, я серьезно изучил сегодняшнюю запись о представленных материалах и, наконец, нашел ответ, а именно:git mergeЭто было вызвано тем, что после этого была отправлена ​​только часть кода, о которой, кстати, упоминается здесь,git pullравныйgit fetch + git merge,такgit pullТакже необходимо уделить особое внимание вопросам, затронутым в данной статье.

процесс проверки

Чтобы проверить проблему, я построил новыйgitБиблиотека для воспроизведения вышеуказанной проблемы, согласно симуляции, с которой мы столкнулись, весь процесс я использовал для имитации перекрестной отправки и слияния трех пользователей, а именно user1, user2, user3, для удобства я не выбрал регистрацию трех номеров, а отправил Имена включаются в информацию, что может привести к двум конфликтам кода и частичным фиксациям в обоих случаях. Окончательная запись отправки кода выглядит следующим образом:

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

Как код потерялся?

Прежде всего, на шагах 1 и 2 пользователь1 и пользователь2 изменяются локально и изменяются вместе.file1, только пары user2file2Также были внесены изменения, поэтому, если код этих двух объединен, можно ожидать, когда произойдет слияние.file1Будет конфликтовать, файл2 не будет. После завершения модификации user2 это делается один разgit push,В этот моментgitГолова удаленного репозитория должна указывать на последний коммит пользователя user2. Затем пользователь1 делаетgit pull, так как файл1 был изменен двумя пользователями, его необходимо объединить, а затем пользователь1 отправляет только после обработки конфликтаfile1, не представленfile2(вручную через командную строкуreset, но с некоторыми инструментами с графическим интерфейсом вы можете выбрать только отправкуfile1из). На данный момент библиотека потерянаuser2:file2:add lineЭто изменение, это начало кровавой бани, потерянный код. можно сравнитьДо слитияа такжеПосле слияния.

Как "восстанавливается" код?

Я только что проверил, как код был утерян, но на этом дело не закончилось, я уже упоминал выше, что самое странное то, что код восстанавливается, что происходит? После того, как пользователь 1 выполнил код на шаге 3, он сделал две отправки и изменил файл 3 и файл 1. В то же время пользователь 3 присоединился и изменил файл 1 локально (ожидается, что он будет конфликтовать с пользователем 1), а затем пользователь 1git push, затем пользователь3git pull, то он сообщитfile1Конфликт. Опять же, пользователь 3 совершил ту же ошибку, что и пользователь 1, и отправил только конфликтующий файл.file1. По опыту потери кода на шаге 3,file3Смена файла2 точно ушла, и это правда после проверки, но если посмотреть на смену файла2, то она вернулась, так что так называемое восстановление не восстановление, так называемая потеря не потеряна, просто спроси, боишься ли ты. Что еще хуже, давайте посмотримfile2изменить историю.

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

Суммировать

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

• Не выполняйте частичную фиксацию после слияния git! !
• Не выполняйте частичную фиксацию после слияния git! !

• Не выполняйте частичную фиксацию после слияния git! !

• Не изменяйте вручную информацию git merge! !

• Не изменяйте вручную информацию git merge! !
• Не изменяйте вручную информацию git merge! !

Адрес экспериментальной библиотеки, упомянутой в тексте:find-the-missing-code, Заинтересованные детской обувью можете посмотреть подробнее.