Работа в екип без объркване: разбиране на стратегиите за разклоняване в Git

Въведение

Git се превърна в де факто индустриален стандарт за системи за контрол на версиите в разработката на софтуер. Първо трябва да прочетете моята статия за това Howво е Git и How да започнете. чел ли си го Отлично, да тръгваме! Харесва ви or не, този инструмент, създаден от Линус Товалдс, няма да се пенсионира. Така че има смисъл да се говори за това How разпределените екипи работят с Git и Howва стратегия за разклоняване трябва да изберат за това. Това не е несъществен въпрос. Когато сглобявате нов екип за разработка, който не е работил заедно преди това, стратегията за разклоняване често е едно от първите неща, които трябва да вземете. И някои хора ще с пяна на устата доказват, че една стратегия е по-добра от друга. И така, искам да ви предам малко обща информация за тях.

Необходими ли са стратегии за разклоняване?

Те наистина са необходими. Много необходимо. Защото, ако екипът не е съгласен с нещо, тогава всеки член на екипа ще прави Howвото иска:

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

Ето защо имаме три стратегии, които да разгледаме по-долу. Да тръгваме!

GitHub Flow

Тази стратегия за разклоняване, колкото и да е странно, е предпочитана в GitHub :) Тя идва с набор от правила :

1. Кодът в главния клон не трябва да се разбива. Трябва да е готов за разгръщане по всяко време. Тоест, не трябва да поставяте code там, който ще ви попречи да изградите проекта и да го внедрите на сървъра.
2. Когато планирате да работите върху нова функционалност, трябва да създадете нов клон на функция на базата на главния клон и да му дадете смислено име. Задайте codeа си локално и редовно изпращайте промените си в същия клон в отдалеченото хранorще.
3. Отворете заявка за изтегляне (можете да прочетете за заявките за изтегляне тук ), когато смятате, че работата е готова и може да бъде обединена в главния клон (or ако не сте сигурни, но искате да получите обратна връзка за свършената работа).
4. След като новата функция в заявката за изтегляне бъде одобрена, тя може да бъде обединена в главния клон.
5. Когато промените се обединят в главния клон, те трябва да бъдат разгърнати на сървъра незабавно.

Според GitHub Flow, преди да започнете да работите върху нещо ново, било то корекция or нова функция, трябва да създадете нов клон на базата на master и да му дадете подходящо име. След това започва работата по внедряването. Трябва постоянно да изпращате ангажименти към отдалечения сървър със същото име. Когато заключите, че всичко е готово, трябва да създадете заявка за изтегляне към главния клон. След това поне един or още по-добре двама души трябва да погледнат този code, преди да кликнат върху „Одобряване“. Обикновено ръководителят на екипа на проекта и втори човек определено трябва да разгледат. След това можете да завършите заявката за изтегляне. GitHub Flow е известен и с това, че управлява непрекъсната доставка (CD) в проекти. Това е така, защото когато промените влязат в главния клон, те трябва да бъдат разгърнати на сървъра незабавно.

GitFlow

Предишната стратегия (GitHub Flow) не е много сложна в основата си. Има два вида клонове: главни и функционални клонове. Но GitFlow е по-сериозен. Поне снимката по-горе трябва да изясни това :) Как работи тази стратегия? Като цяло GitFlow се състои от два постоянни клона и няколко вида временни клонове. В контекста на GitHub Flow главният клон е постоянен, а останалите са временни. Устойчиви клонове

• господар: Никой не трябва да пипа or бута нищо към този клон. В тази стратегия master представлява най-новата стабилна version, която се използва в производството (т.е. на реален сървър)
• развитие: Клонът за развитие. Може да е нестабилно.

Разработката се извършва с помощта на три спомагателни временни клона :

1. Разклонения на функции — за разработване на нова функционалност.
2. Разклонения за издаване — за подготовка за издаване на нова version на проекта.
3. Клонове за актуални корекции — за бързо коригиране на грешка, открита от реални потребители на реален сървър.

Характерни клонове

Разклоненията на функциите се създават от разработчиците за нова функционалност. Те винаги трябва да се създават въз основа на клона за разработка. След като завършите работата по новата функционалност, трябва да създадете заявка за изтегляне към клона за разработка. Ясно е, че големите екипи могат да имат повече от един функционален клон наведнъж. Погледнете отново снимката в началото на описанието на стратегията GitFlow.

Освободете клонове

Когато необходимият набор от нови функции е готов в клона за разработка, можете да се подготвите за пускането на нова version на продукта. Клон за освобождаване, който е създаден въз основа на клона за разработка, ще ни помогне с това. Когато работите с клона за освобождаване, трябва да намерите и коригирате всички грешки. Всички нови промени, които са необходими за стабorзиране на клона за освобождаване, също трябва да бъдат обединени обратно в клона за разработка. Това се прави с цел стабorзиране и на развойния бранш. Когато тестерите кажат, че клонът е достатъчно стабилен за нова version, той се обединява с главния клон. По-късно за този комит се създава таг, на който е присвоен номер на versionта. За да видите пример, погледнете снимката в началото на стратегията. Там ще видите Tag 1.0— това е само таг, който показва version 1.0 на проекта. И накрая, имаме клона за актуални корекции.

Клонове за актуални корекции

Клоновете с актуални корекции също са предназначени за пускане на нова version на главния клон. Единствената разлика е, че тези издания не са планирани. Има ситуации, когато бъгове попадат в издадената version и се откриват в производствената среда. Вземете iOS: веднага щом бъде пусната нова version, веднага получавате куп актуализации с корекции на грешки, открити след пускането. Съответно, трябва бързо да коригираме грешка и да пуснем нова version. На нашата снимка това съответства на version 1.0.1. Идеята е, че работата по новата функционалност не трябва да спира, когато е необходимо да се поправи грешка на реален сървър (or Howто ние казваме, "in prod" or "in production"). Клонът на актуалната корекция трябва да бъде създаден от основния клон, тъй като той представлява това, което в момента се изпълнява в производството. Веднага след като корекцията на грешки е готова, той се обединява в master и се създава нов етикет. Точно като подготовката на клон за освобождаване, клонът за актуална корекция също трябва да обедини своята корекция обратно в клона за разработка.

Разклонителен работен процес

В работния процес на разклоняването разработката включва две хранorща:

1. Оригиналното хранorще, в което ще бъдат обединени всички промени.
2. Хранorще за вorца. Това е копие на оригиналното хранorще, собственост на друг разработчик, който иска да направи промени в оригинала.

Звучи малко странно досега, нали? Всеки, който вече се е сблъсквал с разработка с отворен code, вече е запознат с този подход. Тази стратегия дава следното предимство: разработката може да се осъществи във fork хранorще, без да се предоставят разрешения за съвместна разработка в оригиналния клон. Естествено, собственикът на оригиналното хранorще има право да отхвърли предложените промени. Или да ги приеме и обедини. Това е удобно Howто за собственика на оригиналното хранorще, така и за разработчика, който иска да помогне при създаването на продукта. Например, можете да предложите промени в ядрото на Linux . Ако Линус реши, че имат смисъл, промените ще бъдат добавени (!!!).

Пример за работен процес на разклоняване

Работният процес за разклоняване се прилага в GitHub, когато има библиотека, която искате да използвате. Той има грешка, която ви пречи да го използвате напълно. Да предположим, че се гмурнете достатъчно дълбоко в проблема и знаете решението. Използвайки работния процес на разклоняване, можете да коригирате проблема без права за работа в оригиналното хранorще на библиотеката. За да започнете, трябва да изберете няHowво хранorще, например Spring Framework . Намерете и щракнете върху бутона „Форк“ в горния десен ъгъл: Това ще отнеме известно време. След това копие на оригиналното хранorще ще се появи в личния ви акаунт, което ще покаже, че това е разклонение:Сега можете да работите с това хранorще Howто обикновено, като добавяте промени към главния клон и когато всичко е готово, можете да създадете заявка за изтегляне към оригиналното хранorще. За да направите това, щракнете върху бутона Нова заявка за изтегляне :

Коя стратегия да избера

Git е гъвкав и мощен инструмент, който ви позволява да работите с голямо разнообразие от процеси и стратегии. Но колкото повече възможности за избор имате, толкова по-трудно е да решите коя стратегия да изберете. Ясно е, че няма еднозначен отговор за всички. Всичко зависи от ситуацията. Въпреки това има няколко насоки, които могат да помогнат с това:

1. Най-добре е първо да изберете най-простата стратегия. Преминете към по-сложни стратегии само когато е необходимо.
2. Помислете за стратегии, които имат възможно най-малко типове клонове за разработчиците.
3. Разгледайте плюсовете и минусите на различните стратегии и след това изберете тази, от която се нуждаете за вашия проект.

Това е всичко, което исках да кажа за стратегиите за разклоняване в Git. Благодаря за вниманието :) Последвайте ме в GitHub , където често публикувам свои творения, включващи различни технологии и инструменти, които използвам в работата си.