Git 🌙
Chapters ▾ 2nd Edition

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

Одржување на проект

Покрај тоа што знаете како ефикасно да придонесете за проект, најверојатно ќе треба да знаете како да го задржите. Ова може да се состои од прифаќање и примена на закрпи генерирани преку формат-patch и преку е-маил до вас, или интегрирање на промени во оддалечените гранки за складишта што сте ги додале како дистанционни за вашиот проект. Без разлика дали одржувате канонско складиште или сакате да им помогнете со потврдување или одобрување на закрпи, треба да знаете како да ја прифатите работата на начин кој е појасен за другите доверители и одржлив од вас на долг рок.

Работа во филијали на теми

Кога размислувате за интегрирање на нова работа, обично е добра идеја да се обиде во темата гранка - привремена гранка специјално направена да се обиде таа нова работа. На овој начин, лесно може да се прилагоди печ поединечно и да се остави ако не работи додека не сте време да се вратите на него. Ако креирате едноставно име на гранка врз основа на темата на делото што ќе го пробате, како што е "ruby_client" или нешто слично описни, можете лесно да се сеќавате, ако морате да го напуштите некое време и да се вратите подоцна. Одржувачот на проектот Git има тенденција да именува простор на овие гранки, како што е sc / ruby_client, каде` sc` е краток за лицето кое придонело за работата. Како што ќе се сетите, можете да ја креирате гранката базирана на вашата "майстер" гранка како што е ова:

$ git branch sc/ruby_client master

Или, ако сакате да се префрлите на него веднаш, можете да ја користите опцијата checkout -b:

$ git checkout -b sc/ruby_client master

Сега сте подготвени да додадете придонеслената работа што сте ја добиле во оваа гранка на оваа тема и да одредите дали сакате да ја споите во вашите долгорочни гранки.

Примена на закрпи од е-пошта

Ако добиете лепенка преку е-пошта која треба да се интегрирате во вашиот проект, треба да го примените лепенчарот во вашата гранка на тема за да ја оцените. Постојат два начини да се примени е-пошта: со git apply или со` git am`.

Примена на лепенка со примен

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

$ 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 apply --check 0001-seeing-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 за застарени лепенки и такви работи.

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

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. Ако некој ви испрати e-mail испраќањето правилно користејќи git send-email, а вие го преземате во формат mbox, тогаш можете да посочете` git am` во таа датотека mbox, и ќе почне да ги применува сите закрпи што ги гледа. Ако извршите пошта клиент кој може да зачува неколку пораки во mbox формат, можете да зачувате цела серија на закрпи во датотека, а потоа користете git am за да ги примените по една.

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

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

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

$ git log --pretty=fuller -1
commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
Author:     Jessica Smith <jessica@example.com>
AuthorDate: Sun Apr 6 10:17:23 2008 -0700
Commit:     Scott Chacon <schacon@gmail.com>
CommitDate: Thu Apr 9 09:19:06 2009 -0700

   add limit to log function

   Limit log functionality to the first 20

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

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

$ git am 0001-seeing-if-this-helps-the-gem.patch
Applying: seeing if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

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

$ (fix the file)
$ git add ticgit.gemspec
$ git am --resolved
Applying: seeing if this helps the gem

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

$ git am -3 0001-seeing-if-this-helps-the-gem.patch
Applying: seeing if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

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

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

$ git am -3 -i mbox
Commit Body is:
--------------------------
seeing if this helps the gem
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all

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

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

Checking Out Remote Branches

Доколку вашиот придонес дојде од корисник на Git кој го поставил сопственото складиште, го вметнал голем број промени во него, а потоа ви го испрати URL-то до складиштето и името на оддалечената гранка во која се наоѓаат промените, можете да ги додадете како далечински и се спојуваат локално.

На пример, ако Џесика ви испрати е-пошта велејќи дека има одлична нова функција во "руби-клиент" филијала на нејзиното складиште, можете да ја тестирате со додавање на далечинскиот управувач и проверка на таа подружница локално:

$ git remote add jessica git://github.com/jessica/myproject.git
$ git fetch jessica
$ git checkout -b rubyclient jessica/ruby-client

Ако таа повторно ви испрати e-mail со друга гранка која содржи уште една одлична можност, можете директно да "добиете" и "checkout" затоа што веќе имате далечинско поставување.

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

Другата предност на овој пристап е што ја добивате историјата на обврските, исто така. Иако можеби имате легитимни прашања за спојување, знаете каде во вашата историја се базира нивната работа; правилното тројно спојување е стандардно, наместо да се снабдува со "-3" и се надеваме дека закржувањето е генерирано од јавна обврска на која имате пристап.

Ако не работат со некоја личност постојано, но сепак сакате да се повлечете од нив на овој начин, можете да го дадете URL на далечинското складиште во командата за git pull. Ова го прави еднократно повлекување и не го зачувува УРЛ како далечинска референца:

$ git pull https://github.com/onetimeguy/project
From https://github.com/onetimeguy/project
 * branch            HEAD       -> FETCH_HEAD
Merge made by the 'recursive' strategy.

Одредување на она што се воведува

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

Често е корисно да се добие преглед на сите обврски што се во оваа гранка, но кои не се во вашата господарска гранка. Можете да ги исклучите обврските во главната гранка со додавање на опцијата --not пред името на филијалата. Ова го прави истото како и формат master..contrib што го користевме порано. На пример, ако вашиот доверител ви испрати две закрпи и ќе креирате гранка наречена "придонеси" и ќе ги примените овие закрпи таму, можете да го извршите ова:

$ git log contrib --not master
commit 5b6235bd297351589efc4d73316f0a68d484f118
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Oct 24 09:53:59 2008 -0700

    seeing if this helps the gem

commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
Author: Scott Chacon <schacon@gmail.com>
Date:   Mon Oct 22 19:38:36 2008 -0700

    updated the gemspec to hopefully work better

За да видите какви промени секој запис го воведува, запомнете дека можете да ја пренесете опцијата -p во` git log` и да додаде разлика што ќе се внесе во секоја заложба.

За да видите целосен разлика од тоа што ќе се случи ако сте се соединиле со оваа гранка со друга гранка, можеби ќе треба да користите чуден трик за да ги добиете точните резултати. Може да мислите да го извршите ова:

$ git diff master

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

Ако master е директен предок на вашата гранка на тема, ова не е проблем; но ако двете истории се разликуваат, разликата ќе изгледа како да ги додавате сите нови работи во вашата гранка на тема и да ги избришете сè што е уникатно за гранката master.

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

Технички, можете да го направите тоа преку експлицитно сфаќање на заедничкиот предок, а потоа да го извршите различното од тоа:

$ git merge-base contrib master
36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
$ git diff 36c7db

или, поточно:

$ git diff $(git merge-base contrib master)

Сепак, ниту еден од нив не е особено погоден, така што Git обезбедува уште една кратенка за истото: синтаксичка со три точки. Во контекст на командата git diff, можете да ставите три периоди по друга гранка за да направите` diff` помеѓу последната посветеност на гранката на која сте и нејзиниот заеднички предок со друга гранка:

$ git diff master...contrib

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

Интегрирање на придонесената работа

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

Спојување на работни процеси

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

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

History with several topic branches.
Figure 68. History with several topic branches.
After a topic branch merge.
Figure 69. After a topic branch merge.

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

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

Before a topic branch merge.
Figure 70. Before a topic branch merge.
After a topic branch merge.
Figure 71. After a topic branch merge.
After a topic branch release.
Figure 72. After a project release.

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

Рабовилни процеси со голема спојување

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

Managing a complex series of parallel contributed topic branches.
Figure 73. Managing a complex series of parallel contributed topic branches.

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

Merging contributed topic branches into long-term integration branches.
Figure 74. Merging contributed topic branches into long-term integration branches.

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

Работни процедури за пребирање и обработка на цреша

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

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

Example history before a cherry-pick.
Figure 75. Example history before a cherry-pick.

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

$ git cherry-pick e43a6
Finished one cherry-pick.
[master]: created a0a41a9: "More friendly message when locking the index fails."
 3 files changed, 17 insertions(+), 3 deletions(-)

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

History after cherry-picking a commit on a topic branch.
Figure 76. History after cherry-picking a commit on a topic branch.

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 config --global rerere.enabled true

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

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

Обележување на вашите изданија

Кога одлучивте да го намалите објавувањето, најверојатно ќе сакате да доделите таг за да можете повторно да го креирате тоа издание во било која точка што оди напред. Можете да креирате нова ознака како што е наведено во << ch02-git-basics-chapter >>. Ако одлучите да ја потпишете ознаката како одржувач, означувањето може да изгледа вака:

$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gmail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09

Ако ги потпишете вашите ознаки, може да имате проблем со дистрибуирањето на јавниот PGP клуч кој се користи за потпишување на вашите ознаки. Одржувачот на проектот Git го реши ова прашање со вклучување на нивниот јавен клуч како дупка во складиштето, а потоа додавајќи ознака која директно упатува на таа содржина. За да го направите ова, можете да дознаете кој клуч сакате со извршување gpg -list-keys:

$ gpg --list-keys
/Users/schacon/.gnupg/pubring.gpg
---------------------------------
pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
uid                  Scott Chacon <schacon@gmail.com>
sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]

Потоа, можете директно да го внесувате клучот во базата на податоци Git со тоа што ќе го извезете и ќе го напишете преку git hash-object, кој пишува нов blob со тие содржини во Git и ви го враќа SHA-1 на blob:

$ gpg -a --export F721C45A | git hash-object -w --stdin
659ef797d181633c87ec71ac3f9ba29fe5775b92

Сега кога ја имате содржината на клучот во Git, можете да креирате ознака која директно упатува на неа со специфицирање на новата SHA-1 вредност што ви ја дал командата hash-object:

$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92

Ако извршите git push -tags, ознаката` maintainer-pgp-pub` ќе биде споделена со сите. Ако некој сака да потврди ознака, тие можат директно да го внесат вашиот PGP клуч со повлекување на blob директно надвор од базата на податоци и внесување во GPG:

$ git show maintainer-pgp-pub | gpg --import

Тие можат да го користат тој клуч за да ги потврдат сите ваши потпишани ознаки. Исто така, ако вклучите инструкции во пораката за ознаки, со активирањето на git show <tag> ќе ви овозможиме краен корисник поконкретни инструкции за верификација на ознаки.

Генерирање на изграден број

Бидејќи Git нема монотоно зголемување на броеви како "v123" или еквивалентно да се оди со секоја заложба, ако сакате да имате човечко читливо име за да оди со посетување, можете да стартувате git опишуваат за таа залог. Git ви го дава името на најблиската таг со бројот на обврски на таа ознака и делумна SHA-1 вредноста на посетувањето што го опишувате:

$ git describe master
v1.6.2-rc1-20-g8c5b85c

На овој начин, можете да извезувате слика или да изградите и да именувате нешто разбирливо за луѓето. Всушност, ако го изградите Git од изворниот код клониран од Git репозиториумот, git -version ви дава нешто што изгледа вака. Ако опишувате обврска која сте директно обележана, таа ви го дава името на ознаката.

Командата git descriptione ги фаворизира означените ознаки (ознаки создадени со знаме` -a` или -s), па оттука треба да се креираат тагови за ослободување на овој начин ако користите` git опишуваат`, за да осигурате дека именката е именувана правилно кога е опишано. Исто така можете да го користите овој стринг како цел на исходот или да покажете команда, иако се потпира на скратената SHA-1 вредност на крајот, па затоа не може да биде валидна засекогаш. На пример, кернелот Линукс неодамна скокна од 8 до 10 знаци за да се обезбеди единственост на објект SHA-1, па постарите имиња на излезните git опишуваат беа поништени.

Подготовка за издавање

Сега сакате да објавите изгради. Една од работите што ќе сакате да направите е да креирате архива на најновата слика на вашиот код за оние сиромашни души кои не го користат Git. Командата да го направите ова е git архива:

$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
$ ls *.tar.gz
v1.6.2-rc1-20-g8c5b85c.tar.gz

Ако некој го отвори тој тарбол, го добиваат најновото слика на вашиот проект под проектниот именик. Исто така можете да создадете архива на истиот начин, но со пренесување на опцијата --format = zip во` git archive`:

$ git archive master --prefix='project/' --format=zip > `git describe master`.zip

Сега имате убав тарифен и зип архива на вашиот проект порака што можете да испратите на вашата веб-страница или е-пошта до луѓето.

The Shortlog

Време е да испратите е-мејл листа на луѓе кои сакаат да знаат што се случува во вашиот проект. Убав начин за брзо добивање еден вид на промени на она што е додадено на вашиот проект, бидејќи твоето последно издание или е-пошта е да ја користите командата git shortlog. Ги сумира сите обврски во опсегот што го давате; на пример, следново ви дава резиме на сите обврски од вашето последно издание, ако вашето последно издание беше именувано како v1.0.1:

$ git shortlog --no-merges master --not v1.0.1
Chris Wanstrath (8):
      Add support for annotated tags to Grit::Tag
      Add packed-refs annotated tag support.
      Add Grit::Commit#to_patch
      Update version and History.txt
      Remove stray `puts`
      Make ls_tree ignore nils

Tom Preston-Werner (4):
      fix dates in history
      dynamic version method
      Version bump to 1.0.2
      Regenerated gemspec for version 1.0.2

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

scroll-to-top