Садржај
- Почните једноставно са ГитХуб протоком
- Еколошке гране
- Означавање ознакама
- Објединити урезивање или не?
- Брзо премотавање унапред
- Стратегије гранања
Гит је фантастичан алат. Алати за контролу извора пружају неколико виталних карактеристика: место за чување кода, историју промена и информације о томе ко је шта и када урадио. Ако сте ви и ваш тим добри са порукама урезивања, можда ћете чак добити и бонус информације о томе зашто је дошло до промене. Дистрибуирани алати као што су Гит и Мерцуриал такође нуде бројне могућности за сарадњу између више спремишта, као и пружају ефикасне начине рада са огранцима.
Па, шта је тачно филијала у Гиту? Погледајте слику 1. Подружница у Гиту је једноставно показивач на урезивање. Ако погледате како је грана представљена у директорију '.гит', наћи ћете текстуалну датотеку са истим именом као грана, која једноставно садржи идентификатор урезивања тренутног 'савета' или најновије урезивања на тој грани. . Сама грана се креира праћењем претка тог појединачног урезивања, будући да свако урезивање зна након којег је урезивања дошло.
Као тренера, једна ствар о којој ме увек питају је шта је „исправна“ Гит стратегија гранања. Моји савети се прилично разликују у зависности од тима и ситуације, али постоје неки уобичајени обрасци који се појављују изнова и изнова. Овај пост износи те обрасце и објашњава ситуације у којима могу бити од највеће помоћи.
Почните једноставно са ГитХуб протоком
Познат по посту на блогу од Сцотта Цхацона, ГитХуб Флов је моја омиљена стратегија гранања. Зашто? Углавном зато што је једноставан, а да и даље покрива све битне основе. ГитХуб Флов једноставно наводи да приликом рада на било којој функцији или исправци грешке треба да направите грану.
Када је завршен, поново се спаја у мастер са урезивањем спајања. То је врло једноставан начин за тимове и појединце да безбедно креирају и сарађују на одвојеним функцијама и да их могу испоручити када заврше. Ствара графикон који изгледа отприлике као онај на слици 2.
Огранци ове „теме“ могу бити прилично дуговечни, али имајте на уму да што се грана више удаљава од главног, већа је вероватноћа да ће доћи до сукоба када функција дође. Правило је да је главна грана увек расположива, тако да се функције морају завршити и темељито тестирати пре него што се споје. Након што се нова карактеристика споји са главном, нормално је одмах инсталирати нову базу кода. За ово можете или успоставити истински приступ непрекидној примени, или једноставно поставити једноставан аутоматизовани процес примене, тако да се код може често примењивати.
На блогу Лауре Тхомсон постоји сјајан чланак који ово описује као „потенцијално континуирано распоређивање“. Не сматра се необичним постављање кода на платформе уживо више пута дневно.
Будући да се овај модел залаже за гранање чак и за „хитну исправку“ - брзу промену са једним урезивањем - он ствара узорак графикона за себе. Слика 3 представља пример где постоји само једно преусмеравање у смеру развоја.
Зашто би неко креирао једну урезу на грани, а затим је спојио са урезивањем спајања, уместо да само примењује промену директно на мастер? Постоје неки филозофски разлози за раздвајање, али за мене постоје две главне предности.
Прво, стварање подружнице даје прилику да отворите захтев за повлачење и добијете преглед / повратну информацију / КА о промени пре него што се споји. Друго, ако желите или уклонити промену или применити исту промену негде другде, обе те ствари су лакше са граном него са урезивањем директно на главном.
Еколошке гране
То је оно што волим да називам моделом „Бранцх пер Платформ“. Поред главне гране, постоје и гране које прате активну платформу, као и све друге платформе које користите у свом току рада (попут теста, постављања и интеграције). Да би то урадио, мастер остаје на ивици крварења вашег пројекта, али како су функције завршене, у складу с тим се спајате са осталим платформама (погледајте слику 4).
Предност овога је што увек имате пословницу која прати одређену платформу, што олакшава хитно решавање проблема ако је, на пример, примећен уживо. Користећи активну грану као основу вашег поправка, можете лако применити постојећу базу кода, плус једну једину промену. Једном када се платформа уживо среди, можете применити поправак на главну и било коју другу грану окружења. То значи да избегавате ситуацију у којој покушавате да погодите шта је на платформи уживо или вршите чудан поправак директно на мрежи!
Означавање ознакама
Веома слична алтернатива је коришћење ознака за означавање ваших издања када их направите. На овај начин се можете осврнути на историју верзија које су биле уживо. У ствари, ГитХуб чак има и наменску страницу за ово. Ова техника се посебно користи за обележавање издања библиотеке.
Остали алати, као што је Цомпосер за ПХП, користиће ознаке да би покупили и учинили доступним новообјављену верзију, па је важно да се ознаке правилно користе. Ознаке такође могу бити корисне у вашим пројектима, можда конфигуришући ваше алате за изградњу или примену да одговарају само на посебно именоване ознаке, а не на свако урезивање у грани или у целости спремишта.
Објединити урезивање или не?
Коришћење Гит-а даје нам могућност обједињавања промена у било ком редоследу, без обзира на то како су те функције заправо изграђене и комбиноване. Такође нам омогућава да препишемо историју, што доводи до бескрајних расправа о предностима чистог и лепог графикона урезивања, наспрам оног који одражава оно што се заправо догодило.
Слично као аргумент између табулатора и размака, овај аргумент може и трајаће неко време. Упркос томе, обе стране дискусије имају заслуге и важно је узети у обзир када стандардизујете начин рада свог тима.
Да би било шта од овога имало смисла, прво морамо разговарати о спајању предавања у Гит-у. Сви Гит урези имају идентификаторе урезивања - те дуге хек низове - и они су јединствени. Израђени су од информација о скупу промена, поруци урезивања, аутору, временској ознаци и надређеном урезивању на које су примењени.
То значи да ће се иста урезивања примијенити на другог родитеља, чак и ако резултујући код на крају буде идентичан, нови урез ће имати другачији идентификатор урезивања. Обавезе спајања имају не једног, већ два родитеља.
У дневнику изгледају овако:
цоммит 41еа02цц8а1д2964ц4ф7б46б5ф6б11цц04327959 Мерге: а8д1421 е71дбф5 Аутор: Лорна Митцхелл лорна@лорнајане.нет> Датум: Мон Дец 22 19:48:34 2014 +0000 Спајање филијале ’акрабат-упдате-хомепаге-витх-опен-цфпс’
Обратите пажњу на додатни ред у поруци урезивања која започиње Спајање: .... Два броја су референце урезивања два родитеља за ово урезивање - по један из сваке гране које се спајају заједно.
Брзо премотавање унапред
Спајања, међутим, не изгледају увек овако. Ако постоје промене на грани, али не и, на пример, на главној грани, тада ће се догодити „брзо премотавање унапред“. Почињемо са овом ситуацијом: промене на грани обележја, али не и на главној (као што је приказано на слици 5). Ако само затражимо од Гита да споји ову грану, она ће се „премотати унапред“.
Када се спајање догоди, спајање заправо није потребно. Зарези на грани карактеристика настављају се од најновијег урезивања на главној грани, правећи линеарну историју. Гит стога брзо премотава унапред, померајући главну налепницу на врх гране обележја како бисмо могли да наставимо одатле (слика 6). Ако циљате на традиционалнији образац спајања, то можете да примените помоћу прекидача --но-фф. Ово ствара историју која изгледа као на слици 7.
Прекидач --но-фф говори Гит-у да не премотава унапред већ да креира урезивање спајања. Многе стратегије гранања захтевају да се ова техника користи када се гране спајају. Већином ће нам ионако требати урезивање спајања, јер ће доћи до промена и у грани обележја и у грани у коју се спајамо. У неким ситуацијама - за мене је то обично приликом креирања гране хитних исправки - може бити корисно присилити урезивање обједињавања да историја буде јасна тачно која грана је где спојена.
Стратегије гранања
Можда је најпознатија стратегија гранања Гит Флов, која је врло свеобухватна стратегија. Тако свеобухватан, у ствари, потребан му је читав низ скрипти да би га могао правилно користити! Према мом искуству, Гит Флов је превише за све, али за врло велике и технички напредне тимове који истовремено решавају проблеме у више издања.
Међутим, свака стратегија гранања коју сам икада применио црпила је идеје из овог приступа, а ја сам покушао да их разбијем у овом чланку.
Сама стратегија гранања је процес; документ. То је место где као тим бележите свој приступ и став према начину на који производите, пратите и шаљете код. Сви разумеју како функционише сваки од покретних делова процеса (барем на нивоу кода - социјална и политичка питања су тема за други чланак) и како да сарађују у постизању циља којем сви циљате. Стратегија гранања може бити једноставна као страница на вики-ју компаније - нешто што даје структуру начину рада. Такође би могло бити одлично место за постављање Гит таблице са упутствима за обављање различитих корака.
Сматрам да постојање стратегије гранања увелико побољшава и квалитет рада и самопоуздање и комуникацију тима. Одвојите мало времена да се договорите и забележите своју стратегију, а затим наставите и будите још страшнији него што сте били раније.
Речи: Лорна Митцхелл
Лорна Митцхелл је аутор, тренер и програмер специјализован за ПХП, АПИ-је и Гит. Од ње можете добити већу помоћ читајући њену Гит радну свеску која садржи практичне вежбе за повишење нивоа ваших вештина. Овај чланак је првобитно објављен у броју 267 часописа нет.
Свиђа вам се ово? Прочитајте ово!
- Започните са контролом верзија Гит-а
- Како цртати и сликати - 90 професионалних савета и водича
- Како покренути блог
