Съдържание
- Започнете просто с GitHub поток
- Клонове за околната среда
- Маркиране с етикети
- Обединяване на ангажиране или не?
- Сливане бързо напред
- Стратегии за разклоняване
Git е фантастичен инструмент. Инструментите за контрол на източника предоставят няколко жизненоважни функции: място за съхраняване на код, история на промените и информация за това кой какво и кога е направил. Ако вие и вашият екип се справяте добре с съобщения за ангажименти, може дори да получите бонусна информация за това защо е направена промяна. Разпределените инструменти като Git и Mercurial също предлагат много възможности за сътрудничество между множество хранилища, както и осигуряват ефективни начини за работа с клонове.
И така, какво точно представлява клон в Git? Обърнете внимание на Фигура 1. Клон в Git е просто указател към фиксиране. Ако погледнете как е представен клон в директорията „.git“, ще намерите текстов файл със същото име като клона, просто съдържащ идентификатора на фиксиране на текущия „съвет“ или най-новия фиксиране в този клон . Самият клон се създава чрез проследяване на родословието на този единичен фиксация, тъй като всеки фиксация знае кой коммит е възникнал след това.
Като обучител винаги ме питат какво е „правилната“ стратегия за разклоняване на Git. Съветите ми варират доста в зависимост от екипа и ситуацията, но има някои често срещани модели, които се появяват отново и отново. Тази публикация очертава тези модели и обяснява ситуациите, в които те могат да бъдат най-полезни.
Започнете просто с GitHub поток
Известен с публикация в блог от Скот Чакон, GitHub Flow е любимата ми стратегия за разклоняване. Защо? Най-вече защото е просто, като същевременно покрива всички основни основи. GitHub Flow просто заявява, че когато работите върху която и да е функция или корекция на грешки, трябва да създадете клон.
Когато приключи, той се обединява обратно в главната с коммит за сливане. Това е много лесен начин за екипи и лица да създават и да си сътрудничат по отделни функции безопасно и да могат да ги доставят, когато приключат. Създава графика, която прилича на тази на фигура 2.
Клоновете на тези „теми“ могат да бъдат доста дълголетни, но имайте предвид, че колкото повече клон се отклонява от главния, толкова по-вероятно е да възникнат конфликти, когато функцията кацне. Правилото е, че главният клон винаги може да се разгърне, така че функциите трябва да бъдат завършени и щателно тествани, преди да бъдат обединени. След като нова функция е обединена с главната, нормално е да се внедри незабавно новата кодова база. За целта можете или да установите истински подход за непрекъснато внедряване, или просто да настроите лесен автоматизиран процес на внедряване, така че кодът да може да бъде разположен често.
В блога на Лора Томсън има страхотна статия, която описва това като „потенциално непрекъснато внедряване“. Не се счита за необичайно внедряването на код на платформи на живо няколко пъти на ден.
Тъй като този модел се застъпва за разклоняване дори на „актуална корекция“ - бърза промяна с еднократно фиксиране - той създава графичен модел изцяло сам по себе си. Фигура 3 представлява пример, при който има само едно отклоняване от посоката на развитие.
Защо някой да създаде единичен ангажимент в клон и след това да го обедини с ангажимент за сливане, вместо просто да приложи промяната директно към master? Има няколко философски причини за раздялата, но за мен има две основни предимства.
Първо, създаването на клон дава възможност за отваряне на заявка за изтегляне и получаване на преглед / обратна връзка / QA за промяната, преди тя да се слее. На второ място, ако искате или да обедините промяната, или да приложите същата промяна другаде, и двете неща са по-лесни с клон, отколкото с директен на главния фиксиране.
Клонове за околната среда
Това обичам да наричам модела ‘Branch per Platform’. В допълнение към главния клон има клонове, които проследяват платформата на живо, както и всички други платформи, които използвате в работния си процес (като тест, подреждане и интеграция). За да направите това, капитанът остава на кървящия ръб на вашия проект, но тъй като функциите са завършени, вие се сливате с другите платформи съответно (вижте фигура 4).
Предимството на това е, че винаги имате клон, който проследява определена платформа, което улеснява много бързото отстраняване на проблем, ако например той бъде забелязан на живо. Използвайки клон на живо като основа на вашата корекция, можете лесно да внедрите съществуващата кодова база, плюс една единствена промяна. След като платформата на живо е подредена, можете да приложите корекцията към главния и други клонове на средата. Това означава, че избягвате ситуация, в която или се опитвате да отгатнете какво има на платформата на живо, или правите странни корекции директно на живо!
Маркиране с етикети
Много подобна алтернатива е да използвате маркери, за да маркирате вашите издания, когато ги правите. По този начин можете да погледнете назад към историята на версиите, които са били на живо. Всъщност GitHub дори има специална страница за това. Тази техника се използва специално за маркиране на библиотечни издания.
Други инструменти, като Composer for PHP, ще използват маркерите, за да вземат и предоставят на разположение наскоро освободената версия, така че е важно маркерите да се използват правилно. Етикетите също могат да бъдат полезни във вашите собствени проекти, може би за конфигуриране на вашите инструменти за изграждане или внедряване, за да реагират само на конкретно именувани тагове, а не на всеки фиксиране в клон или всъщност цяло хранилище.
Обединяване на ангажиране или не?
Използването на Git ни дава възможност да обединяваме промени във всякакъв ред, независимо от това как тези функции всъщност са били изградени и комбинирани. Също така ни дава възможност да пренапишем историята, което води до безкрайни дебати за предимствата на чистата и красива графика на ангажименти, спрямо тази, която отразява действително случилото се.
Подобно на аргумента между раздели и интервали, този аргумент може и ще работи за известно време. Въпреки това и двете страни на дискусията имат предимства и това е важно съображение, когато стандартизирате начина, по който ще работи вашият екип.
За да има смисъл от всичко това, първо трябва да поговорим за коммитни сливания в Git. Всички Git комити имат идентификатори на фиксиране - тези дълги шестнадесетични низове - и те са уникални. Те са направени от информация за набора от промени, съобщението за фиксиране, автора, клеймото за време и родителския ангажимент, към който са приложени.
Това означава, че ако един и същ коммит е приложен към различен родител, дори ако полученият код завърши идентичен, новият фиксиране ще има различен идентификатор на фиксиране. Ангажиранията за обединяване имат не един, а двама родители.
В дневника те изглеждат така:
фиксиране 41ea02cc8a1d2964c4f7b46b5f6b11cc04327959 Обединяване: a8d1421 e71dbf5 Автор: Лорна Мичъл [email protected]> Дата: Понеделник 22 декември 19:48:34 2014 +0000 Обединяване на клон ‘akrabat-update-homepage-with-open-cfps’
Забележете допълнителния ред в съобщението за фиксиране, което стартира Merge: .... Двете числа са препратките на комитите на двамата родители за този фиксат - по един от всеки от клоните, които се обединяват заедно.
Сливане бързо напред
Обединяванията обаче не винаги изглеждат така. Ако има промени в клон, но не, например, в главния клон, ще се извърши „бързо сливане напред“. Започваме с тази ситуация: промени в клон на характеристика, но не и в master (както е показано на фигура 5). Ако просто поискаме от Git да обедини този клон, той ще се „превърти напред“.
Когато се случи сливането, всъщност не е необходимо обединяване. Фиксациите в разклонението на характеристиките продължават от най-новия обвързване на главния клон, като правят линейна история. Следователно Git бързо напред, премествайки главния етикет към върха на разклонението на характеристиките, за да можем да продължим от там (Фигура 6). Ако се стремите към по-традиционен шаблон за сливане, можете да принудите това, като използвате превключвателя --no-ff. Това създава история, която прилича на Фигура 7.
Превключвателят --no-ff казва на Git да не пренасочва бързо напред, а вместо това да създава коммиране на сливане. Много стратегии за разклоняване изискват тази техника да се използва, когато клоните се сливат. По-голямата част от времето все пак ще ни е необходим ангажимент за сливане, тъй като ще има промени както в разклонението на характеристиките, така и в клона, в който сме обединени. В някои ситуации - за мен това е обикновено при създаване на клон с актуални корекции - може да бъде полезно да принудите ангажимента за сливане, за да направи историята ясна точно кой клон къде е обединен.
Стратегии за разклоняване
Може би най-известната стратегия за разклоняване е Git Flow, която е много изчерпателна стратегия. Толкова изчерпателен, всъщност, той се нуждае от цял набор от скриптове, за да го използва правилно! Според моя опит Git Flow е прекалено много за всички, но за много големи и технически напреднали екипи, които решават проблеми в множество версии едновременно.
Въпреки това, всяка стратегия за разклоняване, която някога съм прилагал, е черпила идеи от този подход и се опитах да ги разбия в тази статия.
Стратегията за разклоняване сама по себе си е процес; документ. Това е мястото, където като екип улавяте своя подход и отношение към начина, по който произвеждате, проследявате и изпращате код. Всеки разбира как работи всяка от движещите се части в процеса (поне на ниво код - социалните и политическите въпроси са тема за друга статия) и как да си сътрудничат за постигане на целта, към която всички се стремите. Стратегията за разклоняване може да бъде проста като страница във фирмения уики - нещо, което дава структура на начина, по който работите. Може също да е чудесно място да поставите таблицата с Git за това как да направите различните стъпки.
Намирам, че наличието на стратегия за разклоняване значително подобрява както качеството на работата, така и увереността и комуникацията на екипа. Отделете малко време, за да се съгласите и запишете стратегията си, а след това продължете напред и бъдете още по-страхотни от преди.
Думи: Лорна Мичъл
Лорна Мичъл е автор, треньор и разработчик, специализирана в PHP, API и Git. Можете да получите повече помощ от нея, като прочетете нейната Git Workbook, която съдържа практически упражнения за изравняване на вашите умения. Тази статия първоначално е публикувана в брой 267 на нетното списание.
Хареса ли ви това? Прочетете тези!
- Започнете с контрола на версиите на Git
- Как да рисувате и рисувате - 90 професионални съвета и уроци
- Как да стартирам блог
