3.6 Клонове в Git - Управление на проект

Ако сте получили пача от някого, който го е генерирал с git diff или някакъв вариант на Unix diff инструмента (което не е препоръчително, вижте следващата секция), можете да го приложите с командата git apply. Ако сте записали пача в /tmp/patch-ruby-client.patch:

Това модифицира файловете в работната директория. Командата е почти идентична на patch -p1, въпреки че е по-параноична и приема по-малко fuzzy matches от patch. Тя също така обработва добавянето, изтриването и преименуването на файлове, ако тези процеси са правилно описани в git diff формата, нещо което patch няма да направи. Освен това git apply използва модела “apply all or abort all”, където или всичко се прилага успешно или нищо не се прилага. За разлика от нея, patch може да прилага частично patchfiles, оставяйки работната ви директория в странен статус. git apply като цяло е много по-консервативна от patch. Процесът няма автоматично да ви направи къмит — след като завърши ще трябва сами да индексирате и къмитнете промените.

Можете също да използвате git apply за да видите дали пачът ще се приложи коректно преди в действителност да се изпълни, командата е git apply --check с името на пача:

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

Ако работата идва от напреднал Git потребител, който е наясно с format-patch, тогава работата ви се улеснява, защото пачът ще съдържа също и информация за автора и къмит съобщение. Ако можете, окуражавайте сътрудниците ви да използват format-patch вместо diff, когато генерират пачове за вас. Използвайте git apply само за legacy пачове и неща като това (diff генерирани).

За да приложите пач генериран с format-patch, по-добрият вариант е да използвате git am (наречена е am понеже се използва за "apply a series of patches from a mailbox"). Технически, git am е проектирана да чете mbox файл, който е plain-text формат за съхранение на едно или повече имейл съобщения в един файл. Изглежда по подобен начин:

Това е началото на изхода от командата git format-patch, който видяхме в предната секция, също валиден mbox имейл формат. Ако някой ви е изпратил пача по пощата коректно с git send-email и го запишете в mbox формат, тогава можете да подадете на git am въпросния mbox файл и тя ще започне да прилага всички пачове, които намери. Ако имате имейл клиент способен да записва множество съобщения в mbox формат, тогава можете да запишете цялата серия пачове в един файл и след това да пуснете git am, която да ги приложи последователно.

Обаче, ако някой е качил пач файл генериран с git format-patch към ticketing система или нещо подобно, можете да запишете файла локално и след това да го подадете на git am да го приложи:

Може да видите, че той се е приложил чисто и автоматично се създава нов къмит за вас. Информацията за автора е взета от хедърите From и Date на имейла, а къмит съобщението от Subject хедъра и тялото му (частта преди пача). Например, ако този пач беше приложен от mbox примера отгоре, генерираният къмит би изглеждал така:

Commit реда индикира кой е човекът, който е приложил пача и времето, когато това е станало. Author от своя страна носи информация за създателя на пача и кога е създаден първоначално.

Възможно е обаче пачът да не се прилага чисто. Може главният ви клон да се е разделил твърде много от клона, от който е направен пача или пък самият пач да зависи от друг такъв, който все още не сте приложили. В подобен случай git am ще прекъсне и ще ви попита как искате да продължите:

Командата поставя маркери за конфликт в съответните файлове, както това става при конфликтно сливане или пребазиране. Разрешаването на конфликтите също е аналогично — редактирате файла, индексирате го и след това изпълнявате git am --resolved за да продължите цикъла със следващия пач:

Ако искате Git да се опита да разреши конфликта по малко по-интелигентен начин, може да подадете флага -3 и Git ще се опита да направи three-way сливане. Тази опция е забранена по подразбиране, защото няма да работи в случай, че пачът рапортува, че е базиран на къмит, който не присъства в хранилището ви. Ако обаче имате този къмит (ако пачът например е базиран на публичен такъв), тогава -3 опцията е много по-гъвкава в прилагането на конфликтен пач:

В този случай, без -3 флага пачът щеше се счита за конфликтен. Но понеже той е подаден, пачът се прилага чисто.

Ако прилагате множество от пачове от mbox, можете също така да пуснете am командата в интерактивен режим, при което тя ще спира на всеки пач и ще ви пита дали желаете да го приложи:

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

Когато всички пачове са приложени и къмитнати в topic клона, може да изберете дали и кога да ги интегрирате в long-term клон.

Един простичък процес за действие е просто да слеете цялата нова работа директно в master клона. В такъв сценарий се предполага, че имате master клон, който съдържа стабилен код. Когато получите промени в topic клон и смятате, че той е готов за интегриране или пък когато сте получили и проверили работата на колега, просто сливате нещата в master клона, изтривате topic клона и това се повтаря във времето.

Например, ако имаме хранилище с работа в два клона, ruby_client и php_client, изглеждащи като в История с няколко topic клона и слеем ruby_client последван от php_client, историята накрая ще изглежда като След сливане на topic клон.

Вероятно това е най-простият работен процес, но може да бъде проблематичен, ако си имате работа с по-големи или по-стабилни проекти, където искате да сте много внимателни с това, което въвеждате като промени.

Ако проектът е особено важен, може да искате да използвате двустъпков цикъл на сливане. При такъв сценарий, имате два long-running клона, master и develop, при които master се обновява само, когато излезе много стабилна версия на проекта и промените преди това са интегрирани успешно в develop. И двата клона редовно се публикуват в публично хранилище. Всеки път, когато имате нов topic клон за сливане (Преди сливане на topic клон), вие го сливате в develop (След сливане на topic клон), след което тагвате нова версия и правите fast-forward на master към мястото, където сега е стабилния develop (След нова версия на проекта).

По такъв начин, когато някой клонира хранилището, може да извлече или master и да компилира последната стабилна версия, или develop, който съдържа най-пресните новости. Можете допълнително да разширите тази концепция с отделен integrate клон, където цялата работа е слята заедно. След това, когато кодът в него е стабилен и преминава тестовете, го сливате в develop клона и ако времето покаже, че и той е наистина надежден, правите fast-forward на master.

Проектът Git има четири long-running клона: master, next, и seen (преди това известен като 'pu' — proposed updates) за нови промени, и maint за maintenance backports. Когато сътрудниците изпратят нова работа, тя се събира в topic клонове в хранилище на поддържащия проекта в маниер подобен на този, който описахме (вижте Управление на сложни серии от parallel contributed topic клонове.). В този момент, topic клоновете се изпитват, за да се определи дали са безопасни и готови за използване или трябва да се поправят допълнително. Ако са добре, те се сливат в next и този клон се публикува, така че всички могат да изпробват новите промени както са интегрирани заедно.

Ако промените не са задоволителни, те вместо това се сливат в клона seen. Когато се установи, че са окончателно надеждни, промените биват интегрирани в master. След това next и seen се построяват отново от master. Това значи, че master винаги се мести напред, next от време на време се пребазира, а seen се пребазира още по-често:

Когато даден topic клон най-сетне се слее в master, той се изтрива от хранилището. Проектът Git също има и клон maint, който се прави от последната версия за да осигури backported пачове в случай, че се изисква maintenance release. Така при клониране на Git хранилището, имате четири клона, които може да използвате за да пробвате проекта в различните му състояния на разработка, в зависимост от това колко актуален искате да бъде или как искате да допринасяте към него. А поддържащият проекта има структуриран работен процес за управление на новите промени. Все пак, Git проектът е със специализиран работен процес. За да го разберете напълно, можете да погледнете Git Maintainer’s guide.

Други мениджъри на проекти предпочитат да пребазират или cherry-pick-ват нови промени на базата на master клона си, вместо да ги сливат. Целта е да поддържат почти линейна история. Ако се установи, че промените в topic клона са подходящи за интегриране, превключвате към него и изпълнявате rebase командата, за да възпроизведете промените на базата на текущия master клон (или от develop и т.н.). Ако това работи добре, можете да направите fast-forward на master клона и да запазите линейната история на проекта.

Другият начин да преместите нова работа от един клон в друг е да я cherry-pick-нете. Процесът cherry-pick в Git е подобен на rebase за единичен къмит. Той взема пача, който е бил въведен в даден къмит и се опитва да го приложи повторно в текущия клон. Това е полезно, ако имате множество къмити в topic клон и искате да интегрирате само един от тях или ако къмитът е само един, но предпочитате да не изпълнявате rebase. Да кажем, че имате проект изглеждащ така:

Ако искате да издърпате къмита e43a6 в master клона, можете да направите следното:

Това въвежда същата промяна от e43a6, но получавате нов SHA-1 хеш за къмита, защото приложената дата е различна. Сега историята изглежда така:

Сега можете да премахнете topic клона и да изоставите къмитите, които не желаете да въвеждате.

Ако ви се налага да правите често сливания и пребазирания или ако поддържате topic клон с по-дълъг живот, Git предлага във ваша услуга опцията известна като “rerere”.

Терминът Rerere идва от “reuse recorded resolution” — това е начин за бързо прилагане на ръчно разрешаване на конфликти. Когато rerere е активна, Git ще съхранява набор от pre- и post-images от успешни сливания и ако установи, че е налице конфликт, който изглежда подобен на такъв, който е бил разрешен в миналото, автоматично ще използва записания начин за разрешаването му без да ви занимава с него.

Тази функционалност идва в две части: конфигурационна настройка и команда. Настройката е rerere.enabled и е достатъчно да имате следното в глобалната конфигурация:

Сега след като направите ръчно разрешаване на конфликт, резолюцията ще бъде запомнена в кеша и ще бъде използвана в бъдеще.

Ако е необходимо, може да комуникирате с rerere кеша с командата git rerere. Когато тя се използва самостоятелно, Git проверява базата си данни с решения за конфликти и се опитва да намери съответствие (въпреки, че това се прави автоматично, ако rerere.enabled е true). Също така има подкоманди за разглеждане на това какво ще се запише, за изтриване на конкретна резолюция от кеша и за изтриване на целия кеш. Ще разгледаме детайлно rerere в Rerere.