Ръководство за използване на Git Rebase

Rebase е един от двата начина за обединяване на промените, направени в един клон, в друг клон. Начинаещите и дори опитните потребители на git понякога се чувстват неохотно да го използват, защото не виждат смисъл да овладеят друг начин за обединяване на промените, когато вече познават перфектно операцията по сливане. В тази статия бих искал да анализирам подробно теорията и практиката на използването на rebase.

И така, нека освежим теоретичните познания за това какво е пребазирането. Като начало, накратко - имате два клона - master и feature, и двете локални, характеристиката е създадена от master в състояние A и съдържа фиксирания C, D и E. 1 ангажимент B е направен към главния клон, след като беше отделени от него.

След прилагане на основната операция за пребазиране върху разклонението на характеристиките, дървото на фиксиране ще изглежда така:

Обърнете внимание, че фиксираните C ', D' и E 'не са равни на C, D и E, те имат различни хешове, но промените (делтите), които те носят, в идеалния случай са абсолютно еднакви. Разликата в ангажиментите се дължи на факта, че те имат различна основа (в първия случай - A, във втория - B), разликите в делтите, ако има такива, се дължат на разрешаването на конфликтни ситуации, възникнали по време на преоценката . Повече за това по-късно.

Това състояние има едно важно предимство пред първото, когато се обединява клонът на характеристиките в главния, клонът може да бъде обединен чрез бързо превъртане напред, което елиминира конфликти при извършване на тази операция, освен това кодът в разклонението на характеристиките е по-подходящ, тъй като отчита промените, направени в главния клон при фиксиране B.

Процесът на пребазиране в детайли

Нека сега да се занимаем с механиката на този процес, как точно дърво 1 се превърна в дърво 2?

Позволете ми да ви напомня, че преди пребазирането, вие сте в разклонението на характеристиките, тоест вашата HEAD разглежда показалеца на характеристиката, който от своя страна разглежда фиксацията E. Предавате ID на главния клон на командата като аргумент:

git rebase master

Първо, git намира базовия ангажимент - общия родител на тези две състояния. В този случай това е коммит А. След това, движейки се в посока на текущата ви HEAD, git изчислява разликата за всяка двойка комити, в първата стъпка между A и C, нека го наречем ΔAC. Тази делта се отнася за текущото състояние на главния клон. Ако това не доведе до състояние на конфликт, се създава фиксиране C ', като по този начин C' = B + ΔAC. Клоновете master и feature не се преместват, но HEAD се премества в нов фиксиране (C '), привеждайки вашето хранилище в отделно състояние HEAD.

След успешно създаване на фиксиране C ', git преминава към натискане на следващата промяна - ΔCD. Да предположим, че има конфликт при прилагане на тези промени за фиксиране на C '. Процесът на пребазиране спира (тук може да се окажете в състояние на отделен HEAD, като напишете git status). Промените, направени от ΔCD, са във вашето работно копие и (с изключение на конфликтните) са подготвени за фиксиране (пунктираната линия показва сценичната зона):

След това можете да предприемете следните стъпки:

1. Отменете процеса на пребазиране, като въведете в конзолата

git rebase --abort

В този случай маркерът HEAD ще бъде изтласкан обратно към разклонението на характеристиките и вече добавените фиксирания ще висят във въздуха (нито един указател няма да сочи към тях) и скоро ще бъдат изтрити.

2. Разрешете конфликта във вашия любим инструмент за сливане, подгответе файловете за фиксиране, като напишете git add% filename%. След като сте направили това с всички конфликтни файлове, продължете процеса на пребазиране, като въведете в конзолата

git rebase - продължи

В същото време, ако всички конфликти са наистина разрешени, ще бъде създаден коммит D 'и пребазирането ще премине към следващата, в този пример, последната стъпка.

3. Ако промените, направени по време на формирането на фиксиране B и фиксиране D са напълно взаимно изключващи се и "правилните" промени са направени в комит B, тогава не можете да продължите, като напишете git rebase --continue, тъй като разрешаването на конфликти ще намерите че промените са в работното копие не. В този случай трябва да пропуснете създаването на фиксиране D ', като въведете командата

git rebase --skip

След като бъдат приложени ΔDE промените, ще бъде създаден последният фиксиращ E ', указателят на клон на характеристиката ще бъде настроен да фиксира E', а HEAD ще сочи към клон на характеристиката - сега вие сте в състоянието на втората фигура, пребазирането приключи. Вече нямате нужда от старите фиксирания C, D и E.

Дата на автор: Понеделник 26 ноември 13:19:08 2012 +0400

Дата на записване: Mon Nov 26 13:33:27 2012 +0400

От небето до земята - преоценяване в реалния живот

Всъщност обикновено работите не с два клона, а с четири в най-простия случай: master, origin/master, feature и origin/feature. В този случай е възможно пребазиране както между клона и неговия произход, например характеристика и произход/функция, така и между локалните клонове на характеристика и главен.

Пренастройте клон с произход

Ако искате да започнете с rebase, най-доброто място да започнете е да пребазирате промените си в клона спрямо копието му в отдалеченото хранилище. Факт е, че когато добавите ангажимент и ангажимент се добави към отдалеченото хранилище, сливането се използва по подразбиране за обединяване на промените. Изглежда така:

---