git pull --rebase молча пропускает конфликты rebase

Question

Кто-то пометил это как дубликаты, но он не говорит, почему git rebase не вызывает конфликтов, в то время как git pull имеет

У меня есть два клона одного и того же репо, C1 и C2, и оба их заголовка находятся на коммите M1, который имеет некоторые изменения в файле F.

Предположим, что нет .gitconfig файла и .git/config для файла является значением по умолчанию, сгенерированным git

В C1

1. Я изменяю F (там же, где M1 изменен F)
2. git commit -a --amend --no-edit для перезаписи M1, что приводит к новой фиксации M2.
3. git push -f для перезаписи пульта.

В C2

• Я делаю git fetch. Так что origin/master == M2 в то время как HEAD == M1

, поскольку M1 и M2 обе изменены F, любая из следующих команд перейдет в состояние merge conflict:

• git merge origin/master
• git merge
• git rebase origin/master
• git pull

Однако следующие команды не запускают merge conflicts и устанавливают HEAD в M2

• git rebase
• git pull --rebase

Вопросы

• Правильно ли это поведение по замыслу?
• В чем разница между git rebase и git rebase origin/master
• Что делает git pull --rebase?

Раньше я всегда думал

• git pull совпадает с git fetch && git merge origin/master
• git pull --rebase совпадает с git fetch && git rebase origin/master

Но этот эксперимент опровергает мою мысль.

---

Ситуация не изменится, даже если я добавлю еще один M3 поверх M2 и нажму C1. В C2 он все равно сбрасывается на M3 и M1 теряется.

Answer 1

git merge пытается посмотреть на различия между точками M1 и C1 и на различия между точками M1 и C2 и объединить их вместе.

git rebase помещает вас в точку M2, затем применяет каждое из изменений от точки M1 к точке C2, которые не были также на пути к точке M2 в последовательности. Используя этот подход, он сможет лучше понять, что уместно, а что нет, поэтому многие вещи, которые кажутся конфликтами в подходе слияния, гораздо более очевидны для разработки.

---

Хотя многие разработчики предпочитают делать как можно меньше коммитов, git rebase работает лучше всего, когда каждый из коммитов был небольшим. Все это казалось мне волшебством, пока я не попытался сделать то же самое вручную в репозитории CVS. Изменение Coworker A, которое представляло собой всего лишь один коммит, было нелегко применить с концепцией rebase, потому что все это было одно. Но переключение на его обновление и применение к нему десятков крошечных коммитов Coworker B сработало очень хорошо, чтобы показать, что именно предназначалось для каждого обновления.