Git выбирает неправильный коммит предка

Question

Я использую Git с несколькими другими людьми.У нас есть центральное хранилище, а затем локальные ветви отслеживания.Недавно мы столкнулись с проблемой, когда git неправильно думает, что последний общий коммит-предок основной ветви и новой ветви - это коммит, который был выдвинут только после того, как мы создали новую ветку, что приводит к отмене изменений при слиянии.новая ветвь обратно. Пример:

Алиса вносит некоторые изменения в свою локальную копию главной ветви и фиксирует их, но не нажимает.Скажем, она изменяет первую строку файла foo.txt.

Боб извлекает из центральной копии главную ветвь.Насколько он может сказать, он в курсе.

Оба продолжают работать.В какой-то момент Алиса отталкивает.Позже Боб вызывает git log и видит, что его ветка якобы является предком коммита, в котором Алиса изменила foo.txt, хотя он никогда не извлекал ее изменения.Когда Боб сливается, как и ожидалось, изменения Алисы исчезли.

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

Answer 1

Кто-то на каком-то этапе принудительно отправил некоторые изменения и переписал определенный хеш-коммит (используя -f в push).Похоже, что ваш сценарий может произойти с этим.

Если это может помочь вам, наш рабочий процесс на работе всегда должен использовать rebase при вытягивании / нажатии:

Человек A внес изменения и подтолкнулих.

Человек B продолжает работать, выполняя local commits

На каком-то этапе Человек B хочет начать игру.Чтобы сделать это.

• Человек B должен убедиться, что локальная ветвь чиста (если есть тайник).

• Человек B запускает git pull -rebase (это загрузит все изменения и заново примените его поверх новой HEAD)

• В случае возникновения какого-либо конфликта, лицо B разрешает конфликты.

• Человек B, наконец, запускает локальную копию в прямом эфире.

И повторно примените тот же процесс, с Человеком A, который находится позади головы источника и должен вытащить ребаз

И НИКОГДА не используйте -f, когда толкаете вживую, это действительно плохо.

Подробнее: Силовой толчок заманчив, когда, скажем, человек А сделал коммит, толкнул его вживую, а затем понял, что тамбыла оставлена ​​ошибкаЧеловек А вносит поправку в последний коммит.Единственный способ затем запустить этот коммит в прямом эфире - это нажать push -f ... и это очень плохо для людей, работающих над своими собственными копиями, которые сделали локальные коммиты для своей копии и отправили live