2nd Edition

5.3 Дистрибуиран Git - Приватен мал тим

Приватен мал тим

Наједноставниот поставување со кој најверојатно ќе наидете е приватен проект со еден или двајца други развивачи. "Приватен" во овој контекст значи затворен код - не е достапен за надворешниот свет. Вие и другите програмери имаат пристап до складиштето.

Во ова опкружување, можете да го следите работниот тек сличен на она што може да го направите кога користите Subversion или друг централизиран систем. Вие сеуште ги добивате предностите на нештата како офлајн извршување и многу поедноставно разгранување и спојување, но работниот тек може да биде многу сличен; главната разлика е во тоа што спојувањето се случува на клиентска страна, наместо на серверот во времето на извршување. Да видиме што може да изгледа кога двајца програмери почнуваат да работат заедно со споделено складиште. Првиот инвеститор, Џон, го клонира складиштето, прави промени и се обврзува локално. (Во овие примери протоколните пораки се заменети со ... за да ги скратат малку.)

# John's Machine
$ git clone john@githost:simplegit.git
Cloning into 'simplegit'...
...
$ cd simplegit/
$ vim lib/simplegit.rb
$ git commit -am 'remove invalid default value'
[master 738ee87] remove invalid default value
 1 files changed, 1 insertions(+), 1 deletions(-)

Вториот инвеститор, Џесика, го прави истото - го клонира складиштето и прави промени:

# Jessica's Machine
$ git clone jessica@githost:simplegit.git
Cloning into 'simplegit'...
...
$ cd simplegit/
$ vim TODO
$ git commit -am 'add reset task'
[master fbff5bc] add reset task
 1 files changed, 1 insertions(+), 0 deletions(-)

Сега, Џесика ја турка својата работа на серверот, кој работи одлично:

# Jessica's Machine
$ git push origin master
...
To jessica@githost:simplegit.git
   1edee6b..fbff5bc  master -> master

Последната линија на излезот погоре покажува корисна порака за враќање од притисни операција. Основниот формат е <oldref> .. <newref> fromref -> toref, каде што` oldref` значи стара референца, newref значи новата референца,` fromref` е името на локалната референца се турка и toref е името на далечинскиот референца што се ажурира. Ќе видите сличен резултат како што е прикажано подолу во дискусиите, така што со основна идеја за значењето ќе помогне во разбирањето на различните состојби на складиштата. Повеќе детали се достапни во документацијата за git-push.

Продолжувајќи со овој пример, набргу потоа, Џон прави некои промени, ги обврзува во неговото локално складиште и се обидува да ги притисне на ист сервер:

# John's Machine
$ git push origin master
To john@githost:simplegit.git
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to 'john@githost:simplegit.git'

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

Како прв чекор, Џон ја презема работата на Џесика (ова само што ја прави работата на Џесика во нагорниот тек, сè уште не ја спои во работата на Јован):

$ git fetch origin
...
From john@githost:simplegit
 + 049d078...fbff5bc master     -> origin/master

Во овој момент локалното складиште на Џон изгледа вака:

Figure 53. John’s divergent history.

Во овој момент локалното складиште на Џон изгледа вака:

$ git merge origin/master
Merge made by the 'recursive' strategy.
 TODO |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Додека тој локален спој оди непречено, ажурираната историја на Џон сега ќе изгледа вака:

Figure 54. John’s repository after merging origin/master.

Во овој момент, Џон можеби ќе сака да го тестира овој нов код за да се осигура дека ниту една од делата на Џесика не влијае врз ниту еден од неговите и, се додека сè изгледа добро, тој конечно може да ја придвижи новата споена работа до серверот:

$ git push origin master
...
To john@githost:simplegit.git
   fbff5bc..72bbc59  master -> master

На крајот, историјата на извршување на Џон ќе изгледа вака:

Figure 55. John’s history after pushing to the origin server.

Во меѓувреме, Џесика создаде нова тема, наречена issue54, и направи три обврски кон таа гранка. Таа сè уште не ги донела промените на Џон, па нејзината историја на извршување изгледа вака:

Figure 56. Jessica’s topic branch.

Одеднаш, Џесика дознава дека Џон има наметнато некоја нова работа на серверот и таа сака да го разгледа, па може да ја донеси сите нови содржини од серверот што таа сè уште не ја има:

# Jessica's Machine
$ git fetch origin
...
From jessica@githost:simplegit
   fbff5bc..72bbc59  master     -> origin/master

Тоа ја повлекува работата што Џон во меѓувреме го удрил. Историјата на Џесика сега изгледа вака:

Figure 57. Jessica’s history after fetching John’s changes.

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

$ git log --no-merges issue54..origin/master
commit 738ee872852dfaa9d6634e0dea7a324040193016
Author: John Smith <jsmith@example.com>
Date:   Fri May 29 16:01:27 2009 -0700

   remove invalid default value

Синтаксиката issue54..origin / master е лог-филтер кој бара од Git да ги прикажува само оние кои се во последната гранка (во овој случај` потекло / господар`) кои не се на првата гранка (во овој случај ` issue54`). Детално ќе ја прочитаме оваа синтакса во << _commit_ranges >>.

Од горенаведениот резултат, можеме да видиме дека постои единствена обврска што ја направил Џон дека Џесика не се споила во нејзината локална работа. Ако таа спојува "потекло / господар", тоа е единствената обврска која ќе ја модифицира нејзината локална работа.

Сега, Џесика може да ја спои нејзината тематска работа во нејзината господарска гранка, да ја спои Џонската работа ("потекло / господар") во нејзината "господарска гранка", а потоа повторно да се врати на серверот.

Прво (откако ја извршил целата работа на нејзината тема тема "issue54"), Џесика се враќа во нејзината магистерска гранка во подготовка за интегрирање на сето ова дело:

$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.

Џесика може прво да се спои или "потекло / господар" или "прашање54" - и двете се возводно, па редот не е важен. Конечната слика треба да е идентична, без разлика кој поредок ќе избере; само историјата ќе биде поинаква. Таа избира да ја спои прво филијалата issue54:

$ git merge issue54
Updating fbff5bc..4af4298
Fast forward
 README           |    1 +
 lib/simplegit.rb |    6 +++++-
 2 files changed, 6 insertions(+), 1 deletions(-)

Нема проблеми; како што можете да видите дека е едноставно брзо напред спојување. Сега Џесика го комплетира локалниот процес на спојување со спојување на претходно добиената работа на Џон, која седи во гранката "потекло / господар":

$ git merge origin/master
Auto-merging lib/simplegit.rb
Merge made by the 'recursive' strategy.
 lib/simplegit.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Сè спојува чисто, и историјата на Џесика сега изгледа вака:

Figure 58. Jessica’s history after merging John’s changes.

Сега потеклото / господарот може да се стигне од" господар "гранката на Џесика, па затоа треба да биде во состојба успешно да изврши притисок (претпоставувајќи дека во меѓувреме Џон не направил повеќе промени):

$ git push origin master
...
To jessica@githost:simplegit.git
   72bbc59..8059c15  master -> master

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

Figure 59. Jessica’s history after pushing all changes back to the server.

Тоа е еден од наједноставните работни процеси. Работате некое време (обично во гранка на тема) и спојте ги тие работи во вашата "господарна гранка" кога е подготвена да биде интегрирана. Кога сакате да ја споделите таа работа, ќе го донесите и споите вашиот "господар" од "потекло / господар" ако се промени, и конечно притиснете на "master" филијалата на серверот. Општата секвенца е вака:

Figure 60. General sequence of events for a simple multiple-developer Git workflow.

Private Managed Team

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

Да речеме дека Џон и Џесика работат заедно за една карактеристика (ја нарекуваат оваа ‘` featureA ’), додека Џесика и третиот развивач, Џози, работат на секунда (на пример ,, функцијаB '). Во овој случај, компанијата користи еден вид на работниот тек на интеграција-менаџер каде што работата на поединечните групи е интегрирана само од страна на одредени инженери, а "мајсторот" на главната репо може да се ажурира само од страна на тие инженери. Во ова сценарио, целата работа се врши во тимски гранки и подоцна се повлекуваат заедно со интеграторите.

Да го следиме работниот тек на Џесика додека работи на нејзините две функции, паралелно соработувајќи со двајца различни развивачи во оваа средина. Претпоставувајќи дека веќе ја има клонирано нејзиното складиште, таа одлучува да работи на "featureA" во прв план. Таа создава нова гранка за функцијата и некои работи за тоа таму:

# Jessica's Machine
$ git checkout -b featureA
Switched to a new branch 'featureA'
$ vim lib/simplegit.rb
$ git commit -am 'add limit to log function'
[featureA 3300904] add limit to log function
 1 files changed, 1 insertions(+), 1 deletions(-)

Во овој момент, таа треба да ја сподели својата работа со Џон, па таа ја турка својата филијала featureA се обврзува до серверот. Џесика нема пристап до "господар" гранка - само интеграторите прават - така таа мора да изврши притисок во друга гранка со цел да соработува со Џон:

$ git push -u origin featureA
...
To jessica@githost:simplegit.git
 * [new branch]      featureA -> featureA

Џесика го испраќа Џон да му каже дека е наметната некоја работа во филијала наречена featureA и тој може да го разгледа сега. Додека чека за повратна информација од Џон, Џесика одлучи да почне да работи на "featureB" со Џози. За да започне, таа започнува нова функција гранка, врз основа на серверот господар гранка на серверот:

# Jessica's Machine
$ git fetch origin
$ git checkout -b featureB origin/master
Switched to a new branch 'featureB'

Сега, Џесика прави неколку обврски на гранката featureB:

$ vim lib/simplegit.rb
$ git commit -am 'made the ls-tree function recursive'
[featureB e5b0fdc] made the ls-tree function recursive
 1 files changed, 1 insertions(+), 1 deletions(-)
$ vim lib/simplegit.rb
$ git commit -am 'add ls-files'
[featureB 8512791] add ls-files
 1 files changed, 5 insertions(+), 0 deletions(-)

Сега складиштето на Џесика изгледа вака:

Figure 61. Jessica’s initial commit history.

Таа е подготвена да им помогнам на нејзината работа, но добива е-пошта од Josie дека гранката со некоја почетна ‘` featureB '’ работа врз неа веќе беше турна на серверот како гранка на функцијаBeBee. Џесика треба да ги спои тие промени со сопствената, пред да може да ја притисне својата работа на серверот. Џесика прво ги допира промените на Џози со git fetch:

$ git fetch origin
...
From jessica@githost:simplegit
 * [new branch]      featureBee -> origin/featureBee

Претпоставувајќи дека Џесика сѐ уште е на нејзината проверена "featureB" гранка, таа сега може да ја спои Џози со таа гранка со git merge:

$ git merge origin/featureBee
Auto-merging lib/simplegit.rb
Merge made by the 'recursive' strategy.
 lib/simplegit.rb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Во овој момент, Џесика сака да ја потпомогне сета оваа споена ‘` featureB '’ работа на серверот, но таа не сака едноставно да ја притиска сопствената гранка featureB. Наместо тоа, бидејќи Џози веќе започнала да ја гради врската "featureBee", Џесика сака да изврши притисок врз that филијалата, која ја прави со:

$ git push -u origin featureB:featureBee
...
To jessica@githost:simplegit.git
   fba9af8..cd685d1  featureB -> featureBee

Ова се нарекува refspec. Погледнете << _refspec >> за подетална дискусија за Git refspecs и различни работи што можете да ги направите со нив. Исто така го забележуваме знакот -u; ова е кратко за -set-upstream, кое ги конфигурира гранките за полесно притискање и повлекување подоцна.

Одеднаш, Џесика добива е-мејл од Џон, кој и 'кажува дека ги натерал некои промени во гранката featureA на која соработуваат, и го прашува Џесика да ги погледне. Повторно, Џесика го води едноставниот "git fetch" за да донесат нови содржини од серверот, вклучувајќи ја и (се разбира) последната работа на Џон:

$ git fetch origin
...
From jessica@githost:simplegit
   3300904..aad881d  featureA   -> origin/featureA

Џесика може да ја прикаже дневникот на новата работа на Џон, споредувајќи ја содржината на новопосетената featureA гранка со нејзината локална копија од истата гранка:

$ git log featureA..origin/featureA
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
Author: John Smith <jsmith@example.com>
Date:   Fri May 29 19:57:33 2009 -0700

    changed log output to 30 from 25

Ако Џесика го сака она што го гледа, таа може да ја спои новата работа на Џон во нејзината локална featureA филијала со:

$ git checkout featureA
Switched to branch 'featureA'
$ git merge origin/featureA
Updating 3300904..aad881d
Fast forward
 lib/simplegit.rb |   10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)

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

$ git commit -am 'small tweak'
[featureA 774b3ed] small tweak
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git push
...
To jessica@githost:simplegit.git
   3300904..774b3ed  featureA -> featureA

Историјата на извршување на Џесика сега изгледа вака:

Figure 62. Jessica’s history after committing on a feature branch.

Во одреден момент, Џесика, Џози и Џон ги информираат интеграторите дека "функцијата А" и "функцијаБеј" филијали на серверот се подготвени за интеграција во главната линија. Откако интеграторите ги обединуваат овие гранки во главната линија, превземањето ќе го сведе новото спојување, со што историјата ќе изгледа вака:

Figure 63. Jessica’s history after merging both her topic branches.

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

Figure 64. Basic sequence of this managed-team workflow.

Forked Public Project

Придонес кон јавните проекти е малку поинаков. Бидејќи немате дозволи директно да ги ажурирате гранките на проектот, морате да ја добиете работата на одржувачите на друг начин. Овој прв пример опишува придонес преку фалсификување на домаќините на Git кои го поддржуваат лесното приклучување. Многу хостинг сајтови го поддржуваат ова (вклучувајќи GitHub, BitBucket, repo.or.cz и други), и многу одржувачи на проектот очекуваат овој стил на придонес. Следниот дел се занимава со проекти кои претпочитаат да ги прифатат придонесите со е-пошта.

Најпрво, најверојатно ќе сакате да го клонирате главното складиште, да креирате гранка на теми за серија на закрпи или дамки што планирате да придонесете и вашата работа таму. Редоследот изгледа вака вака:

$ git clone <url>
$ cd project
$ git checkout -b featureA
  ... work ...
$ git commit
  ... work ...
$ git commit

Note

Можеби ќе сакате да го користите rebase -i за да ја сквоти вашата работа до една посветеност или да ја преуредите работата во обврските за да ја направите лепенката полесна за одржувачот да го прегледа - видете << ch07-git-tools # _reverting_history> > за повеќе информации за интерактивно пребивање.

Кога вашата работа на филијалата е завршена и сте подготвени да го вратите назад до одржувачите, одете на оригиналната страница на проектот и кликнете на копчето "Вилушка", креирајќи своја сопствена вилушка за проектот. Потоа треба да го додадете овој URL на репозитори како нов далечински управувач од вашето локално складиште; во овој пример, да го наречеме myfork:

$ git remote add myfork <url>

Потоа треба да ја притиснете вашата нова работа во ова складиште. Најлесно е да се притисне на гранката на тема на која работите на вашето преклопено складиште, наместо спојување на таа работа во вашата господарска гранка и притискање на тоа. Причината е дека ако вашата работа не е прифатена или е избрана од цреша, не мора да ја премотате вашата господарска гранка (операцијата Git cherry-pick е подетално опфатена во << _rebase_cherry_pick >>). Ако одржувачите се спојат,` rebase`, или cherry-pick својата работа, на крајот ќе го вратите преку повлекување од нивното складиште во секој случај.

Во секој случај, можете да ја притиснете вашата работа со:

$ git push -u myfork featureA

Откако вашата работа ќе биде ставена во вилушка на складиштето, треба да ги известите одржувачите на оригиналниот проект дека имате работа што би сакале да се спојат. Ова често се нарекува pull request, а ти обично генерира такво барање или преку веб-страницата - GitHub има свој ‘` Pull Request '’ механизам кој ќе го пречекаме во << ch06-github >> - или можете да ја извршите командата git request-pull и рачно да му ги испратите следните резултати на одржувачот на проектот.

Командата git request-pull ја зема основната гранка во која сакате да се повлече темата на филијалата и URL-то на складиштето на Git од кое сакате да се повлечат, и дава резиме на сите промени што ги барате да бидат повлечени. На пример, ако Џесика сака да го испрати Џон на барање за повлекување, а таа е сторено две обврски на темата гранка таа само се наметнува, таа може да се кандидира ова:

$ git request-pull origin/master myfork
The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
Jessica Smith (1):
        added a new function

are available in the git repository at:

  git://githost/simplegit.git featureA

Jessica Smith (2):
      add limit to log function
      change log output to 30 from 25

 lib/simplegit.rb |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

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

На проект за кој не сте одржувач, генерално е полесно да се има гранка како master секогаш да се следи` потекло / господар` и да се направи вашата работа во гранките на теми што можете лесно да ги отфрлите ако тие се одбиени. Имајќи теми за работа изолирани во гранките на тема, исто така, ви олеснува да ја реблокирате вашата работа ако во меѓувреме се премести врвот на главното складиште и вашите обврски веќе не се применуваат чисто. На пример, ако сакате да поднесете друга тема за работа на проектот, не продолжувајте да работите на гранката на тема што сте ја наметнале - почнете со работа од главната гранка на главното складиште:

$ git checkout -b featureB origin/master
  ... work ...
$ git commit
$ git push myfork featureB
$ git request-pull origin/master myfork
  ... email generated request pull to maintainer ...
$ git fetch origin

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

Figure 65. Initial commit history with featureB work.

Да речеме дека одржувачот на проектот се повлече во еден куп други лепенки и се обиде својата прва гранка, но повеќе не се спојува. Во овој случај, можете да се обидете да го ребалансирате таа гранка на врвот на "потекло / господар", да ги разрешите конфликтите за одржувачот, а потоа повторно да ги поднесете вашите промени:

$ git checkout featureA
$ git rebase origin/master
$ git push -f myfork featureA

Ова ја препишува вашата историја и сега изгледа како << psp_b >>.

Figure 66. Commit history after featureA work.

Бидејќи си ја преокупирал гранката, мора да ја наведете -f на вашата команда за притискање за да може да ја замени гранката` featureA` на серверот со обврска која не е потомок од неа. Алтернатива би била да се поттикне оваа нова работа на друга гранка на серверот (можеби наречена featureAv2).

Ајде да погледнеме во уште едно можно сценарио: одржувачот ја разгледа работата во вашата втора гранка и му се допаѓа концептот, но би сакал да го смените деталите за имплементацијата. Исто така, ќе ја искористите оваа можност за да ја преместите работата да биде базирана на тековната "мајсторска" гранка на проектот. Почнувате нова гранка базирана на тековната гранка "потекло / господар", сквош ги промените "функцијата Б" таму, ги разрешувате сите конфликти, извршете ја промената, а потоа притиснете го тоа како нова гранка:

$ git checkout -b featureBv2 origin/master
$ git merge --squash featureB
  ... change implementation ...
$ git commit
$ git push myfork featureBv2

Опцијата --squash ја зема целата работа на споената гранка и го скрши во еден нагон на промени, создавајќи ја состојбата на складиштето, како да се случи вистинско спојување, без всушност да се изврши спојување. Ова значи дека вашата идна посветеност ќе има само еден родител и ќе ви овозможи да ги претставите сите промени од друга гранка, а потоа да направите повеќе промени пред снимањето на новата обврска. Исто така, опцијата `--no-commit 'може да биде корисна за одложување на спојувањето во случај на стандарден процес на спојување.

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

Figure 67. Commit history after featureBv2 work.

Јавен проект над е-пошта

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

Работниот тек е сличен на случајот со претходната употреба - креирате теми за секоја серија на печурки на кои работите. Разликата е како ги доставувате до проектот. Наместо да го фалсификувате проектот и да притискате на сопствена верзија за запишување, генерирате е-порти за секоја серија на е-пошта и испратете ги на е-поштата на програмерот:

$ git checkout -b topicA
  ... work ...
$ git commit
  ... work ...
$ git commit

Сега имате две обврски кои сакате да ги испратите на мејлинг листата. Користете git format-patch за да ги генерирате датотеките форматирани од mbox кои можете да ги испратите на е-поштата - се претвора секоја зачленет во е-порака со првата линија на порака за обврска како предмет и остатокот од пораката плус крперот што се воведува како тело. Убаво е што примената на лепенка од е-пошта генерирана со "формат-печ" правилно ги зачувува сите информации за извршување.

$ git format-patch -M origin/master
0001-add-limit-to-log-function.patch
0002-changed-log-output-to-30-from-25.patch

Командата format-patch ги отстранува имињата на датотеките за дамки што ги создава. Прекинувачот -M му кажува на Git да бара преименувања. Датотеките завршуваат како вака:

$ cat 0001-add-limit-to-log-function.patch
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

---
 lib/simplegit.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/simplegit.rb b/lib/simplegit.rb
index 76f47bc..f9815f1 100644
--- a/lib/simplegit.rb
+++ b/lib/simplegit.rb
@@ -14,7 +14,7 @@ class SimpleGit
   end

   def log(treeish = 'master')
-    command("git log #{treeish}")
+    command("git log -n 20 #{treeish}")
   end

   def ls_tree(treeish = 'master')
--
2.1.0

Можете исто така да ги уредувате овие датотеки за да додадете повеќе информации за листата на е-пошта што не сакате да се појави во пораката за извршување. Ако додадете текст помеѓу линијата --- и почетокот на лепенка (линијата diff --git), програмерите можат да ја прочитаат, но таа содржина е игнорирана од процесот на амандман.

За да го испратите е-пошта до мејлинг-листата, можете да ја вметнете датотеката во вашата програма за е-пошта или да ја испратите преку командна линија. Вметнувањето на текстот често предизвикува проблеми со форматирањето, особено со "попаметни" клиенти кои не ги зачувуваат нови линии и други празни места соодветно. За среќа, Git обезбедува алатка која ви помага да испраќате правилно форматирани закрпи преку IMAP, што може да биде полесно за вас. Ќе покажеме како да испратиме лепенка преку Gmail, што се случува да биде агент на е-пошта што го знаеме најдобро; можете да прочитате детални упатства за повеќе програми за пошта на крајот од горенаведената датотека "Documentation / SubmittingPatches" во изворниот код на Git.

Прво, треба да го поставите делот imap во датотеката "~ /. Gitconfig". Можете да ја наместите секоја вредност одделно со серија команди за git config` или можете да ги додадете рачно, но на крајот вашата конфигурациска датотека треба да изгледа вака:

[imap]
  folder = "[Gmail]/Drafts"
  host = imaps://imap.gmail.com
  user = user@gmail.com
  pass = YX]8g76G_2^sFbd
  port = 993
  sslverify = false

Ако вашиот IMAP-сервер не користи SSL, последните две редови веројатно не се потребни, а вредноста на домаќинот ќе биде imap: // наместо imaps: //. Кога тоа е поставено, можете да го користите git imap-send за да ја поставите серијата на" patch "во папката Drafts на наведениот IMAP сервер:

$ cat *.patch |git imap-send
Resolving imap.gmail.com... ok
Connecting to [74.125.142.109]:993... ok
Logging in...
sending 2 messages
100% (2/2) done

Во овој момент, треба да бидете во можност да отидете во папката своја Drafts, да го промените полето To до листата за испраќање на која праќате лепенка, можеби CC на одржувачот или лицето одговорно за тој дел и да го испратите.

Можете исто така да ги испратите закрпите преку SMTP-сервер. Како и досега, можете да ја наместите секоја вредност одделно со серија команди за git config`, или можете рачно да ги додадете во делот за испраќање во вашата датотека ~ / .gitconfig`:

[sendemail]
  smtpencryption = tls
  smtpserver = smtp.gmail.com
  smtpuser = user@gmail.com
  smtpserverport = 587

Откако ќе го направите ова, можете да го користите "git send-email" за испраќање на вашите закрпи:

$ git send-email *.patch
0001-added-limit-to-log-function.patch
0002-changed-log-output-to-30-from-25.patch
Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
Emails will be sent from: Jessica Smith <jessica@example.com>
Who should the emails be sent to? jessica@example.com
Message-ID to be used as In-Reply-To for the first email? y

Потоа, Git плука по еден куп информации за најава, гледајќи нешто слично за секој печ кој го испраќате:

(mbox) Adding cc: Jessica Smith <jessica@example.com> from
  \line 'From: Jessica Smith <jessica@example.com>'
OK. Log says:
Sendmail: /usr/sbin/sendmail -i jessica@example.com
From: Jessica Smith <jessica@example.com>
To: jessica@example.com
Subject: [PATCH 1/2] added limit to log function
Date: Sat, 30 May 2009 13:29:15 -0700
Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
In-Reply-To: <y>
References: <y>

Result: OK

Резиме

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

prev | next

1. Почеток

2. Основите на Git

3. Гранење во Git

4. Git на Сервер

5. Дистрибуиран Git

6. GitHub

7. Git Алатки

8. Персонализација на Git

9. Git и други системи

10. Внатрешноста на Git

A1. Appendix A: Git во други околини