Въведение в Git merge and rebase: какви са те и как да ги използвате

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

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

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

Git Merge

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

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

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

Минуси

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

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

Обединяване на главния клон в клон функция с помощта на checkoutи mergeкоманди.

$ git checkout feature $ git merge master (or) $ git merge master feature

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

Git Rebase

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

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

Ребазите са как промените трябва да преминават от върха на йерархията надолу, а сливанията са как текат обратно нагоре

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

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

Минуси

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

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

Пребазирайте разклонението на характеристиките на главния клон, като използвате следните команди.

$ git checkout feature $ git rebase master

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

Интерактивно пребазиране

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

$ git checkout feature $ git rebase -i master

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

pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3

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

Коя да използвам

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

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

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

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

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

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

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

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

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

Заключение

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

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

code = coffee + developer

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