Кога ще има нужда от 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 има операция за прекъсване и всички операции стигат до reflog, така че можете да отмените всичко. Всъщност е точно обратното.

Позволява ви да се чувствате свободни да се ангажирате по всяко време, без да е необходимо да имате „добра“ компилация, докато сте на път да направите такава. Ревизиите, които публикувате, могат да бъдат чисти, като смачкате всички стъпки, които сте предприели по пътя, в един ангажимент.

Използвам rebase през цялото време (доста често чрез изтегляне, което обикновено съм конфигурирал да rebase след фазата на извличане). Не мислете за това като за пренаписване на историята - мислете за това като за предоставяне на инструмент, с който да изчистите грубата си чернова, преди да я публикувате.

След година ще бъде ли важно за някой във вашия проект да знае, че наистина сте стартирали тази функция срещу ревизия 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 погребва информация в reflog, където е необходимо известно копаене, за да я върнете отново. 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 някои екипи предпочитат да имат чиста история на разработка/основен клон; така че те пребазират изходния клон (и може би го смачкват в една ревизия на целевия клон). В 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