Почему git commit может быть потерян в этом случае? - PullRequest
2 голосов
/ 20 апреля 2019

Мой коллега провел серию неосторожных операций «тяни / толкай». Он оказывается в ситуации, когда его местный коммит пропадает

Я восстановил его коммит, используя git reflog. Но я не мог понять, почему его операции приводят к ситуации. Может кто-нибудь пролить свет?

См. git reflog вывод и комментарии ниже:

#######
# reflog is in reverse manner, most recent operation first
# test is like our "develop" branch, MTX-65 is the feature branch
# Both are remote-tracking
#######
39261b7 (HEAD -> MTX-65, origin/feature/MTX-65) HEAD@{0}: checkout: moving from test to MTX-65
7f66c72 (test) HEAD@{1}: checkout: moving from MTX-65 to test
39261b7 (HEAD -> MTX-65, origin/feature/MTX-65) HEAD@{2}: pull: Fast-forward
d51c1be HEAD@{3}: rebase finished: returning to refs/heads/MTX-65
d51c1be HEAD@{4}: rebase: Add Notification
c33d31f HEAD@{5}: pull --tags -r origin feature/MTX-65: checkout c33d31f4d0109396dea6d6bb78f47ba56097e4ac

#######
# This is the key commit that got lost
# It's not in `git log` out any more
#######
a6a7a7e HEAD@{6}: commit (merge): Warning message
3c8113c HEAD@{7}: commit (amend): Add Notification
7f551e4 HEAD@{8}: commit: Add Notification
96bcf99 HEAD@{9}: pull --tags -r origin feature/MTX-65: Fast-forward
b79bee0 HEAD@{10}: commit: personal & institution page
3cfb1aa HEAD@{11}: commit: Institution:
7f66c72 (test) HEAD@{12}: checkout: moving from test to MTX-65
7f66c72 (test) HEAD@{13}: merge MTX-65: Fast-forward
0733fd2 HEAD@{14}: checkout: moving from MTX-65 to test
7f66c72 (test) HEAD@{15}: commit (merge): Merge test
ebfaeea HEAD@{16}: checkout: moving from test to MTX-65
0733fd2 HEAD@{17}: pull: Fast-forward
1043c35 HEAD@{18}: checkout: moving from MTX-65 to test

#######
# This is a commit that still exists after the disaster
#######
ebfaeea HEAD@{19}: commit: institution 认证信息

1 Ответ

1 голос
/ 21 апреля 2019

Давайте посмотрим на a6a7a7e HEAD@{6}: commit (merge): Warning message.

commit (merge) указывает на конфликты слияния.После разрешения конфликтов ваш коллега изменит сообщение о фиксации по умолчанию на Warning message.Сообщение по умолчанию выглядит как Merge made by the 'recursive' strategy.

Тогда ваш коллега запускает git pull --tags -r origin feature/MTX-65-r, git rebase используется вместо git merge после завершения извлечения.

Как сказано в руководстве ,

По умолчаниюrebase просто удалит коммиты слияния из списка задач и поместит перебазированные коммиты в одну линейную ветвь.

Существует много споров о том, что лучше, git merge или git rebase.Один из плюсов git rebase заключается в том, что мы можем использовать его для создания линейной истории удобным способом.Как и предполагалось, коммиты слияния по умолчанию отбрасываются, хотя git rebase предоставляет -r и -p для их сохранения в некоторых ситуациях.

В течение git rebase ожидается, что конфликты возникнут снова.Теоретически, изменения не могут быть потеряны, если ваш коллега разрешает их так же, как и в предыдущем git merge.Вы можете попробовать git log --reflog -S <keywords> -p, чтобы узнать, в какой фиксации изменения, включая ключевые слова, теряются.

...