Пренаписване на история с Git Rebase
Руски (пуски) превод от Сергей Жук (можете да видите и оригиналната статия на английски)
Основният работен поток на Git изглежда така: правите задача в отделен клон, след което го обединявате в основния клон, когато приключите. Това прави git merge основен инструмент за обединяване на клонове. Това обаче не е единственият инструмент, който Git предлага.
Алтернатива на горния сценарий може да бъде обединяването на клонове с помощта на git rebase. Вместо обединяване на клонове в специален фиксиране, смяна премества целия клон с изданието в края на главния клон, както е показано по-долу.
Това служи на същата цел като git merge, свързване на ангажименти от различни клонове. Но има две причини, поради които можем да изберем да сменим вместо сливане:
- Резултати от изместване в линейна история на проекта.
- Това ни дава възможност да изчистим историята на местните ангажименти.
В тази статия ще разгледаме тези два често използвани случая за git rebase. За съжаление предимствата на git rebase ни водят до компромис. Ако се използва неправилно, това може да бъде една от най-опасните операции, които можете да извършите в хранилището на Git. По този начин трябва внимателно да прецените опасностите при преместване на клонове.
Необходимите условия
1. Shift, за да получите линейна история
Първият случай на употреба, който ще разгледаме, включва различна история на проекта. Помислете за хранилище, където master е продължил, докато работите по проблем в друг клон.
За да натиснете разклонението на характеристиките към главния клон, трябва да изпълните следните команди:
Това ще премести разклонението на характеристиките от текущата му позиция в края на главния клон. .
Има две възможни опции кога може да ви потрябва. Първо, вашата задача засяга нови ангажименти от капитана и сега те ще бъдат достъпни за нея. На второ място, ако задачата е затворена, тогава тя може бързо да бъде обединена в главния клон. И в двата случая смяна ще доведе до линейна история, докато git merge ще доведе до незадължителни коммити за сливане.
Например, помислете какво се случва, ако използвате сливане вместо shift.
Това ще създаде допълнителен ангажимент за сливане в разклонението на характеристиките. Освен това ще се случва всеки път, когато искате да включите ангажименти, по-високи от вашия клон. В крайна сметка историята на проекта ви ще бъде затрупана с безсмислени ангажименти за обединяване.
Същото може да се види и при сливане в другата посока. Без да се използва смяна, обединяването на клон на характеристика в главния клон също изисква ангажиране за сливане. Въпреки че това изглежда като смислен ангажимент (представлява отделна, завършена задача), крайният резултат е история, пълна с вилици:
Ако направите смяна преди сливането, Git може да изтласка главния клон до края на функцията. Можете да видите линейната история на напредъка на проекта, като използвате командата git log - комитите от разклонението на характеристиките са спретнато групирани върху комитите от master. Това не е задължително случаят, когато клонове се обединяват с коммита на сливане.
Разрешаване на конфликти
Когато стартирате git rebase, Git взема всеки ангажимент от клона и ги пребазира един по един на ново място. Ако някой от тези фиксира промени същите редове като ангажиментите нагоре по веригата, това ще доведе до конфликти.
