Когда понадобится git-rebase?

Каждый раз, читая документацию по git-rebase, я теряюсь. Мне это кажется чем-то вроде низкоуровневой операции (читай: темной магии).

Цитата из документов:

Предположим, что существует следующая история и текущая ветка - «тема»:

       A---B---C topic
      /
 D---E---F---G master

С этого момента результат любой из следующих команд:

git rebase master 
git rebase master topic

было бы:

               A'--B'--C' topic
              /
 D---E---F---G master

Возникает вопрос: Зачем кому-то это нужно?

Во-первых, кажется, что история «переписывается», как если бы ветвь началась в другой точке; по сути, история коммитов будет «кучей лжи».

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

Другой вопрос: Мне не хватает действительно интересных / экономящих время функций из-за того, что я не знаю, как использовать git-rebase?

РЕДАКТИРОВАТЬ:

Связанный вопрос: Отмена git rebase


git version-control rebase
person hasen    schedule 28.05.2009    source источник

Ответы (4)


arrow_upward
8
arrow_downward

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

Это позволяет вам не стесняться делать коммит в любое время, когда вы хотите, без необходимости иметь «хорошую» сборку, пока вы на пути к ее созданию. Редакции, которые вы публикуете, можно очистить, объединив все шаги, которые вы сделали на этом пути, в одну фиксацию.

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

Будет ли важно через год для кого-либо в вашем проекте знать, что вы действительно начали эту функцию с ревизией E, а не с ревизией G?

Ненужные рекурсивные слияния затемняют более важные части истории.

person Dustin    schedule 28.05.2009
comment
не могли бы вы немного рассказать об отмене? как, например, отменить перебазирование? - person hasen; 29.05.2009
comment
Извините, я думаю, что некоторые мои комментарии были съедены. Практически каждая операция, которая изменяет репозиторий, делает это, добавляя что-то новое и указывая на него. Reflog показывает все ваши предыдущие состояния HEAD. Вы всегда можете сбросить --hard до одного или выполнить обратную ветвь. Если вы не постараетесь, эта информация не будет потеряна в течение 90 дней. - person Dustin; 29.05.2009
comment
Неправильно, что в git нет небезопасных операций. В то время как git rebase не отбрасывает никакой информации, git gc (который git по умолчанию периодически вызывает сам по себе) делает. И даже до того, как git gc уничтожит информацию безвозвратно, git rebase закапывает информацию в журнал ссылок, где требуется некоторое копание, чтобы получить ее снова. Rebase - очень полезный инструмент, но не заблуждайтесь: это острый инструмент. - person mhagger; 13.08.2009
comment
@mhagger: Не могли бы вы объяснить, почему git-gc выбрасывает информацию? Я думал, он удаляет только то, на что больше не ссылаются? - person sleske; 09.10.2011
comment
@sleske git rebase создает новые коммиты и направляет на них ветку, не оставляя ничего, указывающего на старые коммиты. Следовательно, старые коммиты подлежат сборке мусора (если на них нет другой ссылки). - person mhagger; 29.10.2011

arrow_upward
8
arrow_downward

Вам нужно использовать его, например, когда вы хотите отправить патч для кода, который был изменен кем-то другим. Например, если вы перешли с версии 1.56 программного обеспечения, а сопровождающий тем временем перешел на версию 1.57, он, вероятно, примет исправления только для версии 1.57.

Вы должны переустановить свою ветку до версии 1.57, исправить все конфликты, проверить и повторно отправить патч.

person Metiu    schedule 28.05.2009
comment
Я не использовал git для отправки патчей, но что не так с получением, слиянием и последующим сравнением с удаленной веткой? - person hasen; 29.05.2009
comment
Ничего особенного. Причина, по которой это необходимо в первую очередь, заключается в том, что Git (в отличие от Mercurial) не записывает, в какой ветке была сделана данная ревизия. В Git некоторые команды предпочитают иметь чистую историю ветки development / master; поэтому они переустанавливают исходную ветку (и, возможно, превращают ее в единую ревизию в целевой ветке). В Mercurial, если вы хотите иметь чистую историю ветки, вы просто фильтруете по этой ветке; название ветки является неотъемлемой частью ревизии. (Побочный эффект заключается в том, что ветки Mercurial являются постоянными и не могут быть, например, переименованы после публикации.) - person Mike Rosoft; 21.04.2021

arrow_upward
4
arrow_downward

Как только вы объедините «тему» ​​обратно в «мастер», у вас все равно возникнут эти конфликты. Таким образом, лучше время от времени переставлять «тему» ​​в «мастер» (это проще, если вы будете делать маленькие шаги, чем если вы сделаете один большой шаг - по крайней мере, imo). Если вы перебазируете перед слиянием, все «рискованные» вещи произойдут в ветке, и слияние будет легко после.

person bayer    schedule 28.05.2009

arrow_upward
4
arrow_downward

См. git rebase: поддержание актуальности веток сообщение в блоге Джеймса Боуэса

person Jakub Narębski    schedule 30.05.2009