Git
Chapters ▾ 2nd Edition

5.2 Дистрибуиран Git - Придонес кон проект

Придонес кон проект

Главната тешкотија со опишувањето како да се придонесе кон проект се бројните варијанти за тоа како да се направи тоа. Бидејќи Git е многу флексибилен, луѓето можат и работат заедно на многу начини, а проблематично е да опишете како треба да придонесете - секој проект е малку поинаков. Некои од променливите кои се вклучени се брои активен придонес, избраниот работен тек, вашиот пристап за извршување, а можеби и надворешниот метод за придонес.

Првата променлива е бројот на активни учесници - колку корисници активно придонесуваат за овој проект и колку често? Во многу случаи, ќе имате два или три програмери со неколку обврски на ден, или можеби помалку за малку хитни проекти. За поголеми компании или проекти, бројот на програмери може да биде во илјадници, со стотици или илјадници обврски кои доаѓаат секој ден. Ова е важно бидејќи со се повеќе и повеќе програмери, имате повеќе проблеми со тоа што ќе бидете сигурни дека вашиот код ќе се применува чисто или лесно може да се спои. Промените што ги доставувате може да бидат застарени или сериозно прекинати од работата што е споена додека работите или додека вашите промени чекаат да бидат одобрени или применети. Како може да го задржите вашиот код постојано ажурирани и вашите обврски валидни?

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

Следната променлива е вашиот пристап за извршување. Работниот тек потребен за да се придонесе кон проект е многу различен ако имате пристап за запишување на проектот отколку ако не го користите. Ако немате пристап за запишување, како проектот претпочита да ја прифати придонесената работа? Дали има дури и политика? Колку работа придонесувате во исто време? Колку често придонесувате?

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

Започнете упатства

Пред да почнеме да ги разгледуваме конкретните случаи на употреба, тука е брзата забелешка за пораките за извршување. Имајќи добра насока за создавање обврски и држење кон него, го правиме со Git и многу полесно соработуваме со другите. Проектот Git обезбедува документ кој поставува бројни добри совети за креирање на обврски од кои да испрати закрпи - можете да го прочитате во изворниот код на Git во датотеката "Documentation / SubmittingPatches".

Прво, вашите поднесоци не треба да содржат грешки во празен простор. Git обезбедува лесен начин за проверка за ова - пред да извршите, стартувај `git diff - check ', кој ги идентификува можните грешки во празнините и ги наведува за вас.

Output of `git diff --check`.
Figure 52. Output of git diff --check.

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

Потоа, обидете се да направите секој изврши логички одвоени промени. Ако можете, обидете се да ги направите вашите промени сварливи - не кодирајте цел викенд за пет различни прашања, а потоа ги доставувајте ги како масовно извршување во понеделникот. Дури и ако не се извршувате за време на викендот, користете ја областа за поставување во понеделникот за да ја поделите вашата работа во најмалку една посветеност по прашање, со корисна порака за извршување. Ако некои од промените ја модификуваат истата датотека, обидете се да го користите git add -patch за делумно сцени датотеки (детално опфатени во << _interactive_staging >>). Сликата на проектот на врвот на гранката е идентична без разлика дали извршувате една или пет, се додека сите промени се додадат во одреден момент, па обидете се да им олеснат работите на вашите соработници кога треба да ги разгледаат вашите промени.

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

Последното нешто што треба да се има на ум е порака за извршување. Добивањето на навика за создавање на квалитетни пораки за извршување прави многу полесно користење и соработка со Git. Како општо правило, вашите пораки треба да започнат со една линија, која не е повеќе од 50 карактери, и која ја опишува конзистентноста на промените, проследено со празна линија, проследено со подетално објаснување. Проектот Git бара подетално објаснување да вклучи ваша мотивација за промената и да ја спротивстави неговата имплементација со претходното однесување - ова е добра упатство за следење. Исто така, добра идеја е да се користи моменталниот момент во овие пораки. Со други зборови, користете команди. Наместо "Додадов тестови за" или "Додавање тестови за", "користете" Додај тестови за. " Еве еден template originally written by Tim Pope:

Краток (50 знаци или помалку) резиме на промени

Подетален објаснувачки текст, доколку е потребно. Заврши го
околу 72 карактери или така. Во некои контексти, прво
линија се третира како предмет на е-пошта, а остатокот од
текстот како тело. Правата линија одвојување на
резиме од телото е критично (освен ако го испуштате телото
целосно); алатки како rebase може да се збунети ако трчате
двете заедно.

Понатамошни ставови доаѓаат по празни линии.

   - Точките на куршуми се во ред, исто така

   - Вообичаено се користи цртичка или ѕвездичка за куршумот,
     претходи од еден простор, со празни линии во
     помеѓу, но конвенциите се разликуваат тука

Ако сите ваши обврски за комуникација го следат овој модел, работите ќе ви бидат многу полесни за вас и за програмерите со кои соработувате. Проектот Git има добро форматирани пораки за пораки - обидете се да го стартувате git log -no-merges таму за да видите како изгледа убаво форматираната историја на извршување на проектот.

  1. Како што велиме, не како што правиме.

Заради краткост, многу од примерите во оваа книга немаат убаво форматирани пораки како овој; Наместо тоа, едноставно ја користиме -m опцијата за` git commit`.

На кратко, стори како што кажуваме, не како што правиме.

scroll-to-top