git rebase - почему нужно разрешить несколько различий

Question

Я использовал git rebase несколько раз, и я все еще не понимаю, как это работает на самом деле.

С git -merge это кажется простым - разрешите разницу между кончиком вашей ветви и кончик другой ветви.

Однако с git -rebase часто мы разрешаем множественные различия при выполнении ребазировки. Я полагаю, что число разрешенных различий "сколько коммитов в моей ветке есть у другой ветки", верно? но все же, почему нужно разрешить все различия, а не только различие для самого последнего коммита на моей ветви?

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

Answer 1

git rebase - это сохранение чистой истории на top мастера. Многие проекты, например linux kernel, работают в топических c ветвях, где каждая область / тема / драйвер находится в своей собственной ветке поверх master, прежде чем она будет объединена с master.

В большинстве случаев, нас не волнуют многочисленные итерации, которые разработчик прошел перед тем, как представить серию исправлений. Например, нам не нужно знать, над каким родительским коммитом была начата разработка, сколько раз мастер был слит обратно в ветку, какие исправления были внесены в исходные коммиты и т. д. c. С точки зрения математики, мы хотим получить чистое окончательное решение, а не все подходы, которые вы использовали для достижения этого окончательного решения.

Все, что нам нужно, - это чистый набор коммитов поверх мастера. git rebase важно для этого. Он всегда сохраняет ваши изменения в top мастера, а не в виде запутанной серии слияний и исправлений. Это означает, что во время перебазирования вы должны исправить каждый коммит, когда он применяется поверх мастера (который переместился вперед), как если бы коммит только что был создан поверх этой версии мастера.

IOW в некоторых проектах предпочтение отдается топи c ветвям, которые по сути являются частными для разработчика, но основная ветвь, которая является публичной c, всегда использует слияние.

Answer 2

Ребаз - это запрос на перемещение серии патчей из одного места в вашей иерархии фиксации в другое место в вашей иерархии. Это как серия 'cherry-pick' (да, это действительно так; -)

Итак, сначала вам нужно определить правильный список коммитов, рассматриваемых как патчи, которые вы хотите переместить. Остерегайтесь недопонимания некоторых параметров диапазона ревизий (некоторые не работают. Они даже не говорят, что вы думали). Остерегайтесь своего «Upstream» - это может быть не то, что вы думаете, поэтому Git может подумать, что патч уже применен к «upstream».

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

Первый патч (diff) применен, произошел небольшой конфликт, скажем, новое (вышестоящее) место имело переименовал переменную, пока вы редактировали формулу. Это будет конфликт (два изменения в одном месте или в соседних строках). Итак, вы исправляете конфликты первого патча.

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

Это особенно плохо, если ваши коммиты не атомы c (т.е. каждый действительно маленький!). и без изменений semanti c (переименовывает et c).

Итак, перебазируйте довольно часто, если у вас есть быстрое движение вверх по течению (т.е. продолжайте в том же духе), или делайте это очень редко (т.е. делайте одно большое сеанс fix-it).

Также используйте функцию «ReReRe». Это возможность повторного использования записанного разрешения Git. Вы должны включить это. Он запомнит каждое из ваших «исправлений», а затем, если ему понадобится снова, он может использовать его повторно. Таким образом, вы можете попрактиковаться с исправлениями, забыть о плохих и перезапустить ребаз (используйте опцию --onto для временных попыток).

Документация по переосмыслению невелика, но есть несколько веб-сайтов. статьи.