Почему я хочу сделать git rebase?

Я видел, как много людей говорили о git rebase и о том, что он делает, например. Hg: как сделать rebase как git 's rebase, и люди говорят о том, что он достигает (дает линейную историю), например. здесь Git rebase теряет историю, тогда зачем rebase? Но я не могу понять, почему вы хотели бы это сделать.

Кажется, что это большой расход, чтобы вернуться и пересмотреть свою историю фиксации (что обязательно должно включать некоторые уродливые слияния с n-way конфликтами). И я мог бы представить случаи, когда это могло бы ввести в заблуждение (например, если два человека решают одну и ту же проблему по-разному, но история не показывает, что их работа происходит параллельно, кажется, что это может легко привести к критике и обиде в некоторых средах кодирования высокого давления).

То, что вы получаете, - это более простой для понимания, но неправильный график истории. Что заставляет это сделать?

Спасибо заранее.

Ответ 1

Rebase наиболее полезен при нажатии одной фиксации или небольшого количества коммитов, разработанных за короткий промежуток времени (часы или минуты).

Прежде чем перейти к общему серверу, сначала нужно вытащить фиксации, сделанные в исходное состояние HEAD, в противном случае это создаст непереходное нажатие. При этом можно выбирать между слиянием (git pull) или операцией rebase (git pull --rebase). Опция слияния, в то время как технически более привлекательная, создает дополнительное слияние. Для небольшой фиксации появление двух коммитов за одно изменение фактически делает историю менее читаемой, поскольку операция слияния отвлекает от сообщения фиксации.

В типичном общем дереве разработки каждый разработчик заканчивает нажатие на общую ветвь, выполняя некоторые изменения git pull; <resolve conflicts>; git push. Если они используют git pull без --rebase, то происходит то, что почти каждая фиксация заканчивается сопровождением слиянием, хотя параллельная разработка не происходит. Это создает переплетенную историю из того, что на самом деле является линейной последовательностью коммитов. По этой причине git pull --rebase является лучшим вариантом для небольших изменений, возникающих в результате короткой разработки, тогда как слияние зарезервировано для интеграции долговечных ветвей функций.

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

Ответ 2

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

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

Я работал над патч-серией, которая не затрагивала каких-либо компонентов, которые в то же время были изменены вверх. В этом случае комманда слияния не содержит никакой полезной информации.
Я собираюсь отправить запрос на перенос GitHub, и требуемое слияние требуется много. Сначала перезагружая, я делаю запрос на извлечение более легким для того, чтобы владелец восходящего потока работал. Конечно, я мог бы слить вместо этого, но, поскольку они никогда не видели мой код раньше, это просто упростит чтение серии патчей.
Я сменяю изменения с восходящего потока, и существует большое количество конфликтов. git rebase позволяет мне разрешать эти конфликты при фиксации одновременно, что упрощает понимание и проверяет, когда я иду. Если я забочусь о поддержании фиксации слияния, я могу просто вернуться к не-переустановленной версии ветки, объединить ее с восходящим потоком, а затем использовать diff для переустановленной версии, поскольку конфликт разрешает слияние.