Git Revert удалил работу другого разработчика.Зачем?

Question

В моей компании наш рабочий процесс git выглядит следующим образом: мы создаем feature branch из master, развиваем его на feature branch до тех пор, пока мы не закончим.Затем мы создаем PR для слияния с master, а затем сливаем это feature branch в test.При слиянии с test приложение развертывается на тестовом сервере.Когда тестирование закончено и мы получаем зеленый свет, разработчик просматривает PR и объединяет его в master, что, в свою очередь, развертывает приложение в промежуточной среде.

Я работал над веткой функций и случайно слилсяtest в feature branch (вместо слияния master в feature branch), поэтому, когда я создавал PR, в нем были все сделанные мной изменения, а также изменения других разработчиков, которые слились в test, ноне были в master.Я отменил слияние: git revert -m 1 <commit before merge hash>, а затем слил эту ветвь в test.После этого я получил сообщение от действительно злого разработчика, в котором говорилось, что я удалил их работу (их работа была в test).Я хочу понять, почему это произошло, я хотел вернуться к фиксации до слияния ТОЛЬКО В МОИХ ФИЛИАЛАХ, создать пиар, а затем слиться с test, надеюсь, объединить мою ветку с изменениями этого разработчика в test.Похоже, они удалили свою работу.Кто-нибудь может объяснить мне, почему это произошло?

Answer 1

Из справки git:

git-revert - отменить некоторые существующие коммиты

-m номер родителя, --основная линия родителя-number

Обычно вы не можете отменить слияние, потому что не знаете, какая сторона слияния должна рассматриваться как основная линия.Этот параметр указывает родительский номер (начиная с 1) основной линии и позволяет отменить изменение относительно указанного родителя.

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

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

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

Но когда происходит такая ситуация, я обычно не использую git-revert для коммитов слияния.

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

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

Перейдите в ветку feature и сбросьте ее до коммита до неудачного слияния:

$ git reset --hard hash_of_commit_prior_to_bad_merge
$ git push -f

Ваша ветвь очищена.Теперь перейдите к ветке test и сделайте то же самое, сначала сбросьте настройки перед слиянием и нажмите принудительно, чтобы обновить пульт.

На этом этапе обе ветви чистые.

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

Дайте людям знать, что он исправлен.

Этот подход чистый и работает хорошо, если вы делаете это сразу после происшествия иКоманда позволяет вам принудительно толкать.

Поскольку вы работаете с ветками feature и test, я не понимаю, почему это не будет разрешено.

Даже если вы это сделаетеЧерез некоторое время и удалив чужой коммит из test, вы можете просто объединить его снова после того, как закончите.

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

Надеюсь, это поможет.

Answer 2

Полагаю, пропущенных коммитов не слишком много. Тогда команда ниже 2 поможет вам.

1) в ветке ранее существовавший пропущенный коммит,

$ git reflog | grep -i "key-word-of-the-commit"

получить commit-id-missed сверху

Лучше проверить содержимое коммита, прежде чем перейти к 2）

$ git show commit-id-missed

2) в целевой ветви, где вы хотите объединить этот коммит,

$ git cherry-pick commit-id-missed

Он восстановит все ошибки, которые вы сделали. Но если будет слишком много коммитов, это будет трата времени.