4.3 GitHub - Управление на проект

Някой се появява, променя част от кода ви и ви изпраща Pull Request. Ще получите електронна поща за новия Pull Request изглеждащ подобно на Email известяване за нов Pull Request.

Няколко неща са за отбелязване в този имейл. Първо, той съдържа малък diffstat — списък на файловете, в които има промени от Pull Request-а и в какво количество са те. След това, имате линк към Pull Request-а в GitHub. Предоставят ви се и няколко URL-а, които можете да ползвате от командния ред.

Ако виждате ред git pull <url> patch-1, това е прост начин да слеете отдалечен клон без да трябва да добавяте remote. Видяхме това в Извличане от отделечени клонове. Ако искате, можете да създадете и да превключите в topic клон и след това да изпълните тази команда за да слеете Pull Request-а.

Другите интересни URL-и са .diff и .patch URL-ите, които както можете да предположите, осигуряват unified diff и patch версии на Pull Request-а. Технически, можете да слеете работата в Pull Request-а примерно така:

Както видяхме в Работния процес в GitHub, сега можете да проведете дискусия с човека, който е пуснал Pull Request-а. Можете да коментирате специфични редове код, да коментирате цели къмити или целия Pull Request, използвайки GitHub Flavored Markdown където искате.

Всеки път, когато някой друг коментира Pull Request-а, ще продължавате да получавате имейл нотификации, така че да сте наясно какво се случва. Всеки от дискутиращите ще има линк към Pull Request-а и също така можете директно да отговорите на имейла пускайки автоматично коментар в Pull Request нишката в GitHub.

Веднъж след като кодът е одобрен и искате да го слеете, можете или да го издърпате и слеете локално с помощта на git pull <url> <branch> синтаксиса, който видяхме по-рано, или да добавите fork-хранилището като remote, да го изтеглите и слеете.

Ако сливането е просто, можете направо да натиснете бутона “Merge” в GitHub. Това ще направи “non-fast-forward” сливане с merge commit, дори и ако е възможно fast-forward сливане. Всеки път когато използвате бутона, винаги се създава merge commit независимо от обстоятелствата. Както можете да видите в Merge бутон и инструкции за сливането на Pull Request-а ръчно, GitHub ви дава цялата тази информация ако натиснете помощната препратка.

Ако решите, че не искате да слеете, можете просто да затворите Pull Request-а и човекът, който го е стартирал ще бъде уведомен.

Ако си имате работа с много Pull Request-и и не искате да добавяте цял куп remotes или да правите еднократни изтегляния всеки път, GitHub ви предоставя един хитър трик за улеснение в работата. Това е материал за напреднали и ще видим детайлите за него в Refspec спецификации, но може да е много полезен.

GitHub в действителност представя Pull Request клоновете за дадено хранилище като вид псевдо-клонове на сървъра. По подразбиране, вие не ги получавате при клониране, но те са там по един маскиран начин и можете да получите достъп до тях лесно.

За да демонстрираме това, ще използваме low-level команда (често наричана “plumbing” команда, за която ще научим повече в Plumbing и Porcelain команди) наречена ls-remote. Обикновено тази команда не се използва ежедневно в Git операциите, но е полезна защото ни показва какви референции съществуват на сървъра.

Ако стартираме тази команда за “blink” хранилището, което ползвахме по-рано, ще видим списък от всички клонове, тагове и други референции в него.

Разбира се, ако сте във вашето хранилище и изпълните git ls-remote origin или кой да е друг remote, ще видите отпечатан изход подобен на този.

Ако хранилището е в GitHub и имате отворени Pull Request-и, ще получите тези референции с префикс refs/pull/. Това по същество са клонове, но понеже не са под refs/heads/, нормално не ги получавате когато клонирате или изтегляте от сървъра — fetching процесът по подразбиране ги игнорира.

Има по две референции на Pull Request - едната която завършва на /head сочи към точно същия къмит както и последния къмит в Pull Request клона. По този начин, ако някой отвори Pull Request в наше хранилище и клонът му се казва bug-fix, сочещ към къмит a5a775, тогава в нашето хранилище ние няма да имаме bug-fix клон (той е във fork-а), но ще имаме pull/<pr#>/head референция сочеща към a5a775. Това означава, че можем лесно да изтеглим всеки Pull Request клон в една стъпка без да трябва да добавяме множество remotes.

Сега можем да изтеглим референцията директно.

Това инструктира Git да се свърже с origin адреса и да изтегли референцията наречена refs/pull/958/head. Git за щастие следва инструкцията и сваля всичко необходимо за конструирането на тази референция, след което поставя указател към къмита, който искате в .git/FETCH_HEAD. Можете да продължите с git merge FETCH_HEAD в клон, в който да тествате, но merge commit съобщението изглежда леко странно. Също така, ако разглеждате много Pull Request-и, това става досадно

Съществува също начин да изтеглите всички Pull Request-и и да ги актуализирате всеки път, когато се свързвате с отдалечения сървър. Отворете файла .git/config и потърсете origin секцията. Ще изглежда по подобен начин:

Редът , който започва с fetch = се нарича “refspec.” Това е начин за съотнасяне на имена в сървъра с имена в локалната ви .git директория. В примера тук, това казва на Git, "нещата на сървъра, които се намират в refs/heads трябва да се съхраняват в локалното ми хранилище в refs/remotes/origin." Можете да промените тази секция за да добавите друг refspec:

Това инструктира Git че, “всички refs изглеждащи като refs/pull/123/head трябва да се съхраняват локално като refs/remotes/origin/pr/123.” Сега, ако запишете файла и изпълните git fetch:

Сега всички отдалечени Pull Request-и се представят локално като refs, които работят като tracking клонове - те са само за четене и се обновяват когато теглите. Това прави много лесно изпробването на код от Pull Request локално:

Наблюдателните читатели ще забележат надписа head в края на remote частта на refspec. Съществува също и refs/pull/#/merge референция от страна на GitHub, която представлява къмита, който ще се създаде ако натиснете бутона “merge” в сайта. Това може да ви позволи да тествате сливането преди още да сте натиснали бутона.

Можете да създавате Pull Request-и насочени не само към главния (master) клон, а към всеки един клон в мрежата. В действителност, можете да ги насочите и към друг Pull Request.

Ако забележите Pull Request, който се развива в добра посока и имате идея за подобряване на кода в него, или пък просто нямате push достъп до желания клон, можете да отворите отделен Pull Request директно към него.

Когато започвате да правите Pull Request, в горната част на екрана има кутия, указваща от и към кой клон опитвате да го насочите. Ако натиснете бутона “Edit” вдясно от кутията, можете да смените не само клоновете, но и fork-а.

Тук можете сравнително лесно да слеете вашия нов клон в друг Pull Request или друг fork на проекта.

Под “нотификации” в смисъла на GitHub имаме предвид специфичния подход, който сайтът използва за да поддържа връзка с вас при възникнали събития. Съществуват няколко различни начина за тяхната настройка. Ако отворите секцията “Notification center” от страницата с настройки можете да видите част от наличните опции.

Двата избора за получаване на известия са през “Email” и “Web” и може да изберете кой да е от двата, двата едновременно или пък нито един

Ако ползвате име на клон по подразбиране различно от “master” за основния клон, можете да укажете това в секцията “Options” в страницата с настройки за хранилището.

Просто сменете клона по подразбиране от падащия списък и той ще стане такъв за всички главни действия занапред, включително за това от кой клон ще се извлекат файловете на проекта когато някой клонира хранилището.

Ако искате да прехвърлите проекта си към друг потребител или организация в GitHub, разполагате с опция “Transfer ownership” в долната част на същата “Options” секция от настройките на проекта.

Това е полезно, ако прекратявате участието си в проект и някой друг иска да продължи поддръжката му или пък ако даден проект стане твърде мащабен и бихте желали да го преместите в организация.

Това не само ще премести хранилището заедно с всичката информация за него към друго място, но също така и ще бъде създаден redirect URL към новото място. Клониранията и изтеглянията от Git също ще бъдат пренасочени, а не само за уеб заявките.