6.2 GitHub - Придонес кон проект

Тони бара код за да работи на неговиот програмски микропроцесор Arduino и најде одлична програмска датотека на GitHub на https://github.com/schacon/blink [].

Единствениот проблем е тоа што стапката на трепкање е премногу брзо. Сметаме дека е многу поубаво да чекаме 3 секунди, наместо 1 помеѓу секоја промена на државата. Значи, да ја подобриме програмата и да ја поднесеме назад кон проектот како предложена промена.

Прво, кликнуваме на копчето "Вилушка" како што беше споменато претходно за да добиеме сопствена копија од проектот. Нашето корисничко име тука е ‘` tonychacon '’, па нашата копија на овој проект е на 'https: // github.com / tonychacon / blink` и тоа е местото каде што можеме да го уредиме. Ќе го клонираме локално, ќе создадеме тема на гранката, ќе го смениме кодот и конечно ќе ја вратиме промената назад до GitHub.

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

Како алтернатива, можете да отидете на страницата ‘` Филијали '’ на `https://github.com/ <user> / <project> / branches" за да ја лоцирате вашата филијала и оттаму да отворите ново барање за повлекување.

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

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

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

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

Каде што овој разговор може да се одвива преку е-пошта во работните процеси презентирани во << ch05-distributed-git >>, на GitHub ова се случува онлајн. Сопственикот на проектот може да ја прегледа унифицираната разлика и да остави коментар со кликнување на која било од редовите.

Откако одржувачот ќе го направи овој коментар, лицето кое го отворило барањето за потпишување (и навистина, некој друг што го следи складиштето) ќе добие известување. Ќе продолжиме да го прилагодуваме ова подоцна, но ако има вклучено известување преку е-пошта, Тони ќе добие е-пошта како оваа:

Секој може исто така да остави општи коментари за барањето за повлекување. Во << _ pr_discussion >> можеме да видиме пример на сопственикот на проектот коментирајќи ја линијата на кодот, а потоа оставајќи општ коментар во делот за дискусија. Можете да видите дека кодек коментари се доведени во разговорот, како и.

Сега соработникот може да види што треба да направат за да ја прифатат нивната промена. За среќа, ова е многу едноставно. Каде преку е-маил можеби ќе треба да ја превртувате вашата серија и да ја поднесете повторно на мејлинг листата, со GitHub вие едноставно се обврзувате на гранката на тема повторно и притиснете, што автоматски ќе го ажурира барањето за повлекување. Во << _ pr_final >> исто така можете да видите дека стариот коментар во коментарот е пропаднат во ажурираното барање за повлекување, бидејќи е направено на линија која оттогаш е променета.

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

Интересно е да се забележи дека ако кликнете на табулаторот ‘` Датотеки смени ’ на ова барање за повлекување, ќе го добиете `` унифициран ' разлик - односно вкупната разлика во вкупниот износ што ќе се внесе во вашиот главната гранка, ако оваа гранка на тема беше споена внатре. Во git diff термини, тој во основа автоматски ви покажува` git diff master …​ <branch> `за гранката на која се заснова ова барање за повлекување. Види << _what_is_introduced >> за повеќе за овој тип на разлика.

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

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

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

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

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

На пример, ако се вратиш повторно и погледнете повторно во << _ pr_final >>, ќе забележите дека соработникот не го повратил своето извршување и испрати друго барање за повлекување. Наместо тоа, тие додадоа нови обврски и ги туркаа до постојната гранка. На овој начин, ако се вратите назад и ќе го разгледате ова барање за повлекување во иднина, можете лесно да го најдете целиот контекст за тоа зошто биле донесени одлуки. Притискањето на копчето `Merge 'на страницата намерно создава обврска за спојување која го упатува Барањето за потпишување, така што лесно може да се врати и да се испита оригиналниот разговор ако е потребно.

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

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

Имате две главни опции за да го направите тоа. Можете да го ребалансирате филијалата на врвот на она што е целниот гранка (обично "господар" филијала на складиштето што сте го навеле), или можете да ја спои целната гранка во вашата гранка.

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

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

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

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

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

Ако апсолутно сакате да ја оспорите филијалата за да го исчистите, сигурно може да го сторите тоа, но многу е охрабрен да не го притискате гранката на која веќе е отворена Барањето за влечење. Ако другите луѓе го повлекоа и направија повеќе работа на тоа, ќе наидете на сите прашања наведени во << _rebase_peril >>. Наместо тоа, притиснете го преработениот филијала во нова филијала на GitHub и отворете сосема ново барање за потпишување кое ќе го референцира стариот, а потоа затворете го оригиналот.

Вашето следно прашање може да биде: "Како да го користам старото барање за повлекување?" Излезе дека има многу, многу начини да се повикувате на други работи речиси насекаде каде што можете да напишете во GitHub.

Ајде да започнеме со тоа како да се препратиме на друго барање за повлекување или проблем. Сите барања за повлекување и прашања се доделени броеви и тие се единствени во рамките на проектот. На пример, не можете да добивате Pull Request # 3 and Issue # 3. Ако сакате да се повикате на било кое барање за повлекување од било кое друго, едноставно можете да ставите # <num> во кој било коментар или опис. Можете исто така да бидете поспецифични ако барањето за издавање или повлекување живее на друго место; напишете корисничко име # <num>, ако упатувате на прашање или барање за повлекување во вилушка од складиштето во кое што сте, или корисничко / репо # <num> за да упатите нешто во друго складиште.

Ајде да погледнеме еден пример. Да речеме дека ја прекршивме гранката во претходниот пример, создадовме ново барање за повлекување, и сега сакаме да го повикаме старото барање за повлекување од новиот. Ние исто така сакаме да се повикаме на прашање во вилушка на складиштето и прашање во сосема поинаков проект. Ние можеме да го пополниме описот како << _ pr_references >>.

Кога ќе го поднесеме ова барање за повлекување, ќе видиме сето тоа изречено како << _ pr_references_render >>.

Забележете дека целосниот URL на GitHub што го ставаме таму беше скратен само со потребните информации.

Сега, ако Тони се врати и го затвора оригиналното барање за повлекување, можеме да видиме дека со споменување во новиот, GitHub автоматски создаде trackback настан во временската линија за повлекување. Ова значи дека секој што го посетува ова барање за повлекување и гледа дека е затворен, лесно може да се поврзе со оној кој го заменил. Врската ќе изгледа нешто како << _ pr_closed >>.

Покрај броевите на броеви, исто така може да се повикате на одредена обврска од страна на SHA-1. Мора да наведете целосен карактер SHA-1 од 40 карактери, но ако GitHub го гледа тоа во коментар, тој ќе се поврзе директно со извршувањето. Повторно, можете да референцирате да се занимавате со вилушки или други складишта на ист начин како што правите со проблеми.

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

Можете да креирате листа на задачи како што е ова:

Ако го вклучиме ова во описот на нашето барање за повлекување или проблем, ќе го видиме како << _ eg_task_lists >>

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

Освен тоа, GitHub ќе бара листи со задачи во вашите Прашања и Повлекување барања и ќе ги прикаже како метаподатоци на страниците што ги наведуваат. На пример, ако имате барање за повлекување со задачи и гледате на страната за преглед на сите барања за повлекување, можете да видите колку е направено. Ова им помага на луѓето да ги срушат барањата за повлекување во подзадачи и им помага на другите луѓе да го следат напредокот на филијалата. Можете да видите пример за ова во << _ task_list_progress >>.

Овие се неверојатно корисни кога отворате Барање за повлекување рано и го користите за следење на вашиот напредок преку имплементација на функцијата.

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

За да додадете фрагмент од кодот, мора да го "оградите" во backticks.

Ако додадете име на јазик како што го сторивме таму со "java", GitHub исто така ќе се обиде да синтакса нагласи фрагмент. Во случај на горенаведениот пример, тоа ќе заврши како рендерирање како << _ md_code >>.

Ако реагирате на мал дел од долгите коментари, можете селективно да цитирате од другиот коментар од претходните линии со знакот >. Всушност, ова е толку вообичаено и толку корисно што за неа има кратенка на тастатурата. Ако нагласите текст во коментар за кој сакате директно да одговорите и да го притиснете копчето r, тој ќе го цитира тој текст во полето за коментари за вас.

Цитатите изгледаат вака:

Once rendered, the comment will look like Rendered quoting example..

Конечно, можете исто така да користите емоти во вашите коментари. Ова всушност се користи доста опширно во коментарите што ги гледате на многу прашања на GitHub и Pull Requests. Постои дури и помошник за емоции во GitHub. Ако пишувате коментар и почнувате со знак :, автокомплетер ќе ви помогне да го пронајдете она што го барате.

Emojis земаат форма на : <name>: каде било во коментарот. На пример, би можеле да напишете нешто вака:

Кога ќе биде изречена, ќе изгледа нешто како << _ md_emoji >>.

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

Ова не е технички GitHub со вкус на Markdown, но тоа е неверојатно корисно. Во прилог на додавање на линкови на марканда на линкови до коментари, за кои може да биде тешко да се најдат и вградат URL адреси, GitHub ви овозможува да ги влечете и испуштате сликите во текстуални области за да ги вградите.

Ако погледнете на << _ md_drag >>, можете да видите мал "` Парсери како Markdown "навестување над полето за текст. Кликнување на тоа ќе ви даде целосен измамник на се што можете да направите со Markdown на GitHub.