5.4 Дистрибуиран Git - Одржување на проект

Ако сте примиле лепенка од некој кој го создал со git diff или некоја варијанта на Unix` diff` командата (што не е препорачливо, видете го следниот дел), можете да го примените со командата git apply. Под претпоставка дека сте го зачувале лепенка на / tmp / patch-ruby-client.patch, можете да го примените следењето:

Ова ги модифицира датотеките во вашиот работен директориум. Тоа е речиси идентично со извршување на командата patch-p1 за да се примени крпеницата, иако е повеќе параноична и прифаќа помалку нејасни натпревари од печ. Исто така, се справува со додавање на датотеки, бришење и преименување ако се опишани во формат git diff, кој` patch` нема да го направи. Конечно, git apply е` примени го целиот или прекини го целиот '' модел, каде што било што се применува или ништо не е, а patch` може делумно да ги примени patchfiles, оставајќи го вашиот работен директориум во чудна состојба. git apply е севкупно многу поконзервативно отколку` patch`. Нема да создаде обврска за вас - откако ќе ја извршите, морате да ги фатите и да ги извршите промените што ги внесовте рачно.

Исто така можете да го користите git apply за да видите дали пакетот се применува чисто пред да се обидете да ја примените истата - може да извршите` git apply - check 'со лепенка:

Ако нема излез, тогаш закрпата треба да се применува чисто. Оваа команда, исто така, ќе излезе со не-нула статус ако проверката не успее, па можете да го користите во скрипти ако сакате.

Ако соработникот е корисник на Git и бил доволно добар за да ја користи командата format-patch за генерирање на нивниот закрпи, тогаш вашата работа е полесна бидејќи лепенка содржи информации за авторот и порака за обврски за вас. Ако можете, поттикнете ги вашите соработници да користат format-patch наместо` diff` за да генерираат закрпи за вас. Треба само да го користите git apply за застарени лепенки и такви работи.

За да примените дамка генерирана од format-patch, користите` git am` (командата е именувана am, бидејќи се користи за" примена на серија закрпи од поштенско сандаче "). Технички, git am е изграден за да прочита mbox датотека, што е едноставен, обичен текст формат за складирање на една или повеќе е-пораки во една текстуална датотека. Тоа изгледа вака:

Ова е почеток на излезот од командата git format-patch што ја видовте во претходниот дел; исто така, претставува валиден формат за е-пошта на mbox. Ако некој ви испрати e-mail испраќањето правилно користејќи git send-email, а вие го преземате во формат mbox, тогаш можете да посочете` git am` во таа датотека mbox, и ќе почне да ги применува сите закрпи што ги гледа. Ако извршите пошта клиент кој може да зачува неколку пораки во mbox формат, можете да зачувате цела серија на закрпи во датотека, а потоа користете git am за да ги примените по една.

Меѓутоа, ако некој постави датотека за испраќање генерирана преку git format-patch до систем за издавање билети или нешто слично, можете да ја зачувате датотеката локално, а потоа да ја предадете таа датотека зачувана на вашиот диск на` git am`, за да ја примените:

Можете да видите дека се применува чисто и автоматски го креира новиот залог за вас. Информациите за авторот се земаат од насловите на "Од" и "Дата" од е-поштата, а пораката на посветеноста се зема од "Предмет" и телото (пред далноводот) на е-поштата. На пример, ако овој patch беше применет од горниот пример mbox, генерираната обврска ќе изгледа вака:

Информацијата Commit укажува на лицето кое го применило лепенката и времето кога се применувало. Информацијата Авторот е поединецот кој првично го создал лепенката и кога бил првично создаден.

Но, можно е печот да не се применува чисто. Можеби вашата главна гранка премногу се оддалечи од гранката од која е изграден лепенка, или пак печот зависи од друг лепенка што не сте ја аплицирале. Во тој случај, процесот git am ќе пропадне и ќе ве праша што сакате:

Оваа команда ги става маркерите за конфликти во сите датотеки со кои има проблеми, слично на конфликтното спојување или ребаза. Го решавате ова прашање на ист начин - уредувајте ја датотеката за решавање на конфликтот, ставете ја новата датотека, а потоа стартувајте го git am -resolved за да продолжите на следниот лепенка:

Ако сакате Git да се обиде малку поинтелигентно за да го разреши конфликтот, можете да му дадете опција за -3, што го прави Git обид да се спои со три начини. Оваа опција не е вклучена стандардно, бидејќи не функционира ако извршителот на кој се вели дека тој е базиран не е во вашето складиште. Ако го имате тоа што го извршите - ако лепенката е заснована на јавна обврска - тогаш опцијата -3 е генерално многу попаметна за примена на конфликтна лепенка:

Во овој случај, без опцијата "-3", лепенката би се сметала за конфликт. Бидејќи опцијата -3 била користена, крпеницата се применувала чисто.

Ако користите голем број на закрпи од mbox, исто така можете да ја извршите командата am во интерактивен режим, кој застанува на секој закрпат што го наоѓа и прашува дали сакате да го примените:

Ова е убаво ако имате зачувано голем број закрпи, затоа што прво можете да го видите спотот ако не се сеќавате што е тоа, или да не го примените лепенка ако веќе сте го направиле тоа.

Кога сите закрпи за вашата тема се применуваат и се посветени на вашата гранка, можете да одберете дали и како да ги интегрирате во подолготрајна гранка.

Еден основен работен тек е едноставно спојување на сите кои работат директно во вашата "мајстор" гранка. Во ова сценарио, имате "господар" гранка која содржи во основа стабилен код. Кога имате работа во гранка на тема за која мислите дека сте завршиле, или работа која некој друг придонела и сте потврдиле, ќе ја споите во вашата господарска гранка, избришете ја само споената гранка на тема и повторете ја.

На пример, ако имаме складиште со работа во две гранки именувани ruby_client и` php_client` што изгледа како << merwf_a >>, а ние се спојуваме со ruby_client, проследено со` php_client`, вашата историја ќе заврши како да изгледа како < <merwf_b >>.

Тоа е веројатно наједноставниот тек на работа, но може да биде проблематичен ако се занимавате со поголеми или постабилни проекти каде што сакате да бидете навистина внимателни за она што го воведувате.

Ако имате поважен проект, можеби ќе сакате да користите двофазен циклус на спојување. Во ова сценарио, имате две долготрајни гранки, master и` develop`, во кои ќе се утврди дека господар се ажурира само кога е исклучено многу стабилно ослободување и целиот нов код е интегриран во` развие` гранка . Редовно ги притискате двата гранки во јавното складиште. Секој пат кога имате нова гранка на тема за да се спојат (<< merwf_c >>), ќе ја споите во развие (<< merwf_d >>); тогаш, кога ќе означите порака, ќе го пренасочите господар до каде што е сега стабилната` развие` гранка (<< merwf_e >>).

На овој начин, кога луѓето клонираат складиштето на вашиот проект, тие можат или да го проверат господар за да ја изградат најновата стабилна верзија и да продолжат да ја следат таа лесно, или да проверат` развиваат`, што е најсовремена содржина . Вие исто така може да го проширите овој концепт со тоа што имаат "интегрираат" гранка каде целата работа се спојува заедно. Потоа, кога кодовата база на таа гранка е стабилна и поминува тестови, ќе ја споите во развие гранка; и кога тоа се докажа себеси стабилно за некое време, ќе го пренасочите вашиот "господар" гранка.

Проектот Git има четири долготрајни гранки: master ', next` и pu (предложени надградби) за нова работа, и` maint` за подржувачи за одржување. Кога новата работа е воведена од страна на учесниците, таа е собрана во филијали за теми во складиштето на одржувачот на начин сличен на она што го опишавме (види << merwf_f >>). Во овој момент, темите се оценуваат за да се утврди дали се безбедни и подготвени за потрошувачка или дали им е потребна поголема работа. Ако тие се безбедни, тие се споени во следната, и таа гранка се турка за да можат сите да ги пробаат темите интегрирани заедно.

If the topics still need work, they’re merged into pu instead. Кога се утврди дека тие се целосно стабилни, темите се повторно споени во господар. Отсеките next и` pu` потоа се обновуваат од master. Ова значи дека "господар" скоро секогаш се движи напред, "следниот" е повремено повлечен, а pu се рестартира уште почесто:

Кога филијалата на тема конечно е споена во master, таа е отстранета од складиштето. Проектот Git, исто така, има maint гранка која се откажува од последното издание за да обезбеди поднесени закрпи во случај да се бара ослободување од одржување. Така, кога клонирате Git репозиториумот, имате четири гранки кои можете да ги проверите за да го оцените проектот во различни фази на развој, во зависност од тоа како најсовреме сакате да биде или како сакате да придонесете; а одржувачот има структуриран тек на работа за да им помогне да проверат нови придонеси. Работен процес на Git проектот е специјализиран. За да ја разберете ова, можете да ја проверите Hithead Guide.

Други одржувачи претпочитаат да се омаловажат или да видат придонеси од цреша на врвот на нивната господарска гранка, наместо да ја спојуваат, за да одржуваат претежно линеарна историја. Кога имате работа во филијала на тема и сте утврдиле дека сакате да ја интегрирате, се преместите во таа гранка и ја стартувате командата rebase за да ги измените промените на врвот на вашиот сегашен господар (или "развиј" и така натаму) филијала. Ако тоа функционира добро, можете да го пренасочите вашиот "мастер" филијала и ќе завршите со линеарна историја на проектот.

Друг начин да се преместите воведена работа од една гранка во друга е да ја изберете црешата. Изборот на цреша во Git е како обичај за една посветеност. Потребно е далновод кој беше воведен со обврска и се обидува повторно да го примени на филијалата во која сте моментално. Ова е корисно ако имате голем број на обврски во филијала на тема и сакате да се интегрирате само еден од нив, или ако имате само една застапеност во некоја одделна тема и би сакале да ја користите цреша отколку да ја стартувате. На пример, да претпоставиме дека имате проект кој изгледа вака:

Ако сакате да се повлечеш "e43a6" во вашата господарска гранка, можете да го извршите

Ова ја повлекува истата промена воведена во e43a6, но добивате нова вредност за SHA-1, бидејќи применливиот датум е различен. Сега вашата историја изгледа вака:

Now you can remove your topic branch and drop the commits you didn’t want to pull in.

Ако правиш многу спојување и опоравување, или ако одржуваш долготрајна тематска гранка, Git има функција наречена ‘rerere '’ која може да помогне.

Rerere претставува ‘` повторна употреба снимена резолуција '’ - тоа е начин на скратување рачно решавање на конфликти. Кога е овозможено, Git ќе одржи збир на претходни и пост-слики од успешните спојувања, и ако забележи дека има конфликт кој изгледа токму како оној што веќе сте го поправиле, тој само ќе го искористи поправката од последен пат , без да ви пречи со тоа.

Оваа функција доаѓа во два дела: поставка за конфигурација и команда. Поставката за конфигурација е rerere.enabled, и доволно е да се стави во вашата глобална конфигурација:

Сега, секогаш кога ќе направите спојување кое ги решава конфликтите, резолуцијата ќе биде снимена во кешот во случај да ви треба во иднина.

Ако ви треба, можете да комуницирате со преферираниот кеш користејќи ја командата git rerere. Кога се повикува сам, Git ја проверува својата база на податоци за резолуции и се обидува да пронајде совпаѓање со било какви тековни спорови за спојување и да ги разреши (иако ова се прави автоматски ако rerere.enabled е поставено на` true`). Исто така, постојат подкомисии за да се види што ќе се сними, да се избрише специфичната резолуција од кешот и да се исчисти целата кеш. Повеќе детали ќе ги покриеме во << ref_rerere >>.