Git pull против git pull --rebase

Question

В отношении этого хорошо написанного ответа: https://stackoverflow.com/a/4675513/1139436

Если вы по какой-то причине чувствуете, что нужно быть филиалом ...

На что здесь ссылается "ветвь"? В нашем рабочем процессе мы разветвляемся от мастера, чтобы вносить исправления, новые функции и т. Д., А затем отправляем эти изменения в gerrit для просмотра, который после одобрения (я полагаю, я его не настраивал) объединяет их в мастер. Это те ветки, на которые ссылались, или комментарий относится к чему-то большему (проекты расходятся и т. Д.)?

Вернуться к нашему рабочему процессу ... Как только изменения будут отправлены, мы git checkout master, git pull* и git branch -D bugfix_branch. С тех пор я пометил pull с помощью *, что часто приводило к объединению коммитов в моем локальном мастере Я начал использовать git pull --rebase и больше не вижу этих коммитов слияния, но признаюсь, я совсем не понимаю, что происходит под капотом.

Почему я вижу коммиты слияния и я хочу их? Мне лучше --rebase и избегать их? Ни у кого, кажется, нет ответа в любом случае, пока он "просто работает".

Answer 1

В конечном счете, решения о том, использовать ли рабочий процесс, ориентированный на слияние, рабочий процесс, ориентированный на ребаз, или какой-либо гибрид, то есть использовать оба варианта, выбирая тот, который основан на суждении, - это вопрос мнения и, ну, в общем, суждение. ¹ Есть веские аргументы с обеих сторон. Вот две сторонние страницы мнений, одна от Кена Шидло в пользу перебазирования и одна, на которой перечислены аргументы с обеих сторон , а также страница учебника Atlassian о слиянии против перебазирования.

Что нужно знать о rebase, так это то, что он копирует (некоторые) коммиты. Если вы понимаете модель представления коммитов в Git как graph , ² , то пример аргумента pro-rebase Кена Шидло покажет вам, что это значит: исходные коммиты B и C в:

  B--C   <-- feat
 /
A--D--E   <-- master

образно брошены волкам в пользу новых блестящих замен B' и C':

  B--C   [abandoned]
 /
A--D--E   <-- master
       \
        B'-C'  <-- feat

Заменив тускло-неприглядную старую цепочку B-C на новую блестящую цепочку коммитов B'-C', новая ветвь функций теперь может быть легко встроена в master с коммитом слияния или без него. Использование фиксации слияния - запуск git merge --no-ff feat при включенном master - дает вам этот график:

A--D--E------F   <-- master
       \    /
        B'-C'  <-- feat

, который помогает историку прийти в будущем (как только имя feat будет стерто, что безопасно, так как F помнит C' и E) и видит, что коммит pair , B'-C' - вот что реализовало эту функцию. Имеет ли это значение по сравнению с более простым:

A--D--E--B'-C'  <-- master

это отдельный вопрос. Но тот факт, что true оригинальных коммитов были B--C, теряется в любом случае из-за перебазирования. Если этот факт важен по какой-то причине, то вы что-то потеряли, сделав ребазинг.

Это, в двух словах, аргумент против ребазирования: вы можете потерять какой-то важный бит истории. Аргумент про ребазу заключается в том, что эти биты истории не просто неважны , они активно мешают пониманию . Большая часть компьютерного программирования - это абстракция, а абстракция - это искусство удаления ненужных деталей . ³ . Это дает вам хорошее представление "большой картинки". Как только вы поймете, где вы сейчас находитесь и куда хотите идти, , а затем вы можете представить мелкие детали того, как вы попали сюда и как туда добраться. Если вы заблудились в куче подробностей и не знаете, где вы находитесь и куда идете, вам больше всего повезет с каким-то броуновским движением.

---

¹ Это также верно в отношении того, следует ли произносить суждение с помощью дополнительного "е": http://grammarist.com/spelling/judgment-judgement/, https://www.dictionary.com/e/judgement-vs-judgment/

² Если вы не , работайте по страницам в Думайте как (а) Git .

³ Это верно и для математики. Сама теория графов возникла из , удалив ненужные детали: Осознание Эйлером того, что все, что имело значение, - это мосты и массы земли. (См. Ссылку в сноске 2.)