Chapters ▾ 2nd Edition

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

Управление на проект

След като разгледахме как се допринася в проект по ефективен начин, вероятно ще ви интересува и обратната страна, как да поддържаме собствен такъв. Това може да включва приемане и прилагане на пачове генерирани през format-patch и изпратени до вас или пък интегриране на промени в отдалечени клонове за хранилища добавени като remotes към проекта ви. Независимо дали поддържате canonical хранилище или искате да помогнете проверявайки и одобрявайки пачове, трябва да знаете как да приемате работа от колегите ви по начин ясен за тях и удобен за вас във времето.

Работа в Topic клонове

Когато мислите да интегрирате новополучени промени, добра идея е да ги изпробвате в topic клон — временен такъв създаден специално за теста. По такъв начин е лесно да поправите пач индивидуално и да го зарежете, ако той не работи, докато имате време да го разгледате по-подробно. Ако създадете клон с име съответстващо на темата на изпратената работа, например ruby_client или нещо подобно, можете лесно да го запомните и по-късно да се върнете в него. Поддръжникът на Git проекта например, дори се стреми да използва namespaces за тези имена — като sc/ruby_client, където sc е съкращение за човека, който е изпратил работата. Както помним, създаването на клон базиран на master се прави така:

$ git branch sc/ruby_client master

Или, ако искате да превключите към него веднага, може да използвате checkout -b варианта:

$ git checkout -b sc/ruby_client master

Сега сте готови да добавите новата работа, която сте получили, в този нов topic клон и да решите дали искате да я слеете в long-term клоновете си.

Прилагане на пачове от Email

Ако сте получили пач по имейл, ще трябва да го приложите в topic клона и да го изпробвате. Това се прави с помощта на една от двете команди git apply или git am.

Прилагане на пач с apply

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

$ 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 apply --check 0001-see-if-this-helps-the-gem.patch
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply

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

Прилагане на пач с am

Ако работата идва от напреднал 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 формат за съхранение на едно или повече имейл съобщения в един файл. Изглежда по подобен начин:

From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
From: Jessica Smith <jessica@example.com>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] Add limit to log function

Limit log functionality to the first 20

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

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

$ git am 0001-limit-log-function.patch
Applying: Add limit to log function

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