Въведение в Git Merge и Git Rebase: какво правят и кога да ги използват

Като разработчик, много от нас трябва да избират между Merge и Rebase. С всички референции, които получаваме от интернет, всички вярват, че „Не използвайте Rebase, това може да доведе до сериозни проблеми.“ Тук ще ви обясня какво са сливането и повторното задаване, защо трябва (и не трябва) да ги използвате и как да го направя.

Git Merge и Git Rebase служат на една и съща цел. Те са проектирани да интегрират промените от множество клонове в един. Въпреки че крайната цел е една и съща, тези два метода я постигат по различни начини и е полезно да знаете разликата, тъй като ставате по-добър разработчик на софтуер.

Този въпрос раздели общността на Git. Някои смятат, че винаги трябва да пребазирате, а други, че винаги трябва да се слеете. Всяка страна има някои убедителни предимства.

Git Merge

Сливането е често срещана практика за разработчиците, които използват системи за контрол на версиите. Независимо дали клоните са създадени за тестване, корекции на грешки или други причини, обединяването извършва промени в друго местоположение. За да бъдем по-конкретни, сливането взема съдържанието на изходен клон и ги интегрира с целеви клон. В този процес се променя само целевия клон. Историята на клоновете на източника остава същата.

Merge Master -> Клон за функции

Професионалисти

  • Просто и познато
  • Запазва пълна история и хронологичен ред
  • Поддържа контекста на клона

Против

  • Историята на ангажиментите може да бъде замърсена от много обединения за сливане
  • Отстраняването на грешки с помощта на git bisect може да стане по-трудно

Как да го направим

Обединете главния клон в клона с функции, като използвате командите за проверка и обединяване.

$ git чек функция
$ git master master
(или)
$ git сливане главна функция

Това ще създаде нов „ангажимент за сливане“ в клона с функции, който съхранява историята на двата клона.

Git Rebase

Rebase е друг начин за интегриране на промените от един клон в друг. Rebase компресира всички промени в един „кръпка“. След това интегрира пластира към целевия клон.

За разлика от сливането, преиздаването изравнява историята, защото прехвърля завършената работа от един клон в друг. В процеса се премахва нежеланата история.

Отстъпките са как промените трябва да преминат от върха на йерархията надолу, а сливанията са как те се връщат обратно нагоре
Rebase функция клон в master

Професионалисти

  • Рационализира потенциално сложна история
  • Манипулирането на един ангажимент е лесно (например връщането им)
  • Избягва обединяването да извършва „шум“ в заети репости с заети клонове
  • Почиства междинните ангажименти, като ги прави един-единствен ангажимент, което може да бъде полезно за екипите на DevOps

Против

  • Скръшването на функцията до шест комита може да скрие контекста
  • Пускането на обществени хранилища може да бъде опасно, когато работите като екип
  • Това е повече работа: Използване на rebase, за да поддържате винаги актуализиран клонът на функциите си
  • Освобождаването с отдалечени клонове изисква да натиснете. Най-големият проблем, с който се сблъскват хората е, че те принуждават натискане, но не са задали git push default. Това води до актуализации за всички клонове със същото име, както локално, така и отдалечено, и това е ужасно да се справим.
Ако пребазирате неправилно и неволно пренапишете историята, това може да доведе до сериозни проблеми, така че не забравяйте да знаете какво правите!

Как да го направим

Поставете отново клона на функцията върху главния клон, като използвате следните команди.

$ git чек функция
$ git master rebase

Това премества целия клон на функцията отгоре на основния клон. Това прави, като пренаписва историята на проекта, като създава чисто нови ангажименти за всеки ангажимент в оригиналния (функция) клон.

Интерактивно освобождаване

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

$ git чек функция
$ git rebase -i master

Това ще отвори редактора, като изброява всички ангажименти, които предстои да бъдат преместени.

изберете 22d6d7c Съобщение за ангажиране №1
изберете 44e8a9b Съобщение за ангажиране №2
изберете 79f1d2h Съобщение № 3

Това дефинира точно как ще изглежда клона след извършване на повторната база. Пренареждайки субектите, можете да направите историята да изглежда като всичко, което искате. Например, можете да използвате команди като fixup, squash, edit etc., вместо pick.

Кой да използвате

И така, какво е най-доброто? Какво препоръчват експертите?

Трудно е да се обобщи и да се вземе решение за един или друг, тъй като всеки отбор е различен. Но трябва да започнем от някъде.

Екипите трябва да обмислят няколко въпроса, когато задават своите Git rebase спрямо сливащи политики. Защото както се оказва, една стратегия на работния процес не е по-добра от другата. Зависи от вашия екип.

Помислете за нивото на освобождаване и Git компетентност във вашата организация. Определете степента, в която оценявате простотата на освобождаването в сравнение с проследяването и историята на сливането.

И накрая, решенията за сливане и освобождаване трябва да бъдат разгледани в контекста на ясна стратегия за разклоняване (Вижте тази статия, за да разберете повече за стратегията за разклоняване). Успешна стратегия за разклоняване е проектирана около организацията на вашите екипи.

Какво препоръчвам?

С нарастването на екипа ще бъде трудно да се управляват или проследяват промените в развитието с политика на винаги сливане. За да имате чиста и разбираема история на ангажименти, използването на Rebase е разумно и ефективно.

Като вземете предвид следните обстоятелства и насоки, можете да се възползвате максимално от Rebase:

  • Развивате се на местно ниво: Ако не сте споделили работата си с никой друг. На този етап трябва да предпочетете освобождаване над сливане, за да поддържате историята си подредена. Ако имате личната ви вилица на хранилището и не е споделена с други разработчици, можете да направите нова база данни, дори след като сте се насочили към вашия клон.
  • Кодът ви е готов за преглед: Вие създадохте заявка за изтегляне. Други преглеждат работата ви и потенциално я вкарват в вилицата си за местен преглед. На този етап не бива да рестартирате работата си. Трябва да създадете „преработете“ ангажименти и да актуализирате своя клон с функции. Това помага за проследяването на заявката за изтегляне и предотвратява случайното счупване на историята.
  • Прегледът е направен и готов за интегриране в целевия клон. Честито! На път сте да изтриете клона на функцията си. Като се има предвид, че други разработчици няма да бъдат обединени в тези промени от този момент нататък, това е вашият шанс да освежите историята си. На този етап можете да пренапишете историята и да сгънете оригиналните ангажименти, а тези досадни „pr rework“ и „merge“ ангажименти в малък набор от фокусирани команди. Създаването на изрично сливане за тези ангажименти не е задължително, но има стойност. Той записва кога функцията е завършила да овладее.

заключение

Надявам се, че това обяснение даде някои поглед върху Git merge и Git rebase. Стратегията за сливане срещу ребаза винаги е спорна. Но може би тази статия ще ви помогне да разсеете вашите съмнения и ще ви позволи да възприемете подход, който работи за вашия екип.

Очаквам с нетърпение да напиша на работните процеси и концепциите на Git. Коментирайте темите, за които искате да пиша следващата. Наздраве!

код = кафе + разработчик

Ето още една полезна справка

  • Как да приемем стратегията за разклоняване на Git

школа за кодиране за разработчици на софтуер