6.3 GitHub - Een project onderhouden

Er is nu iemand die een wijziging op je code gemaakt heeft en die je een Pull Request stuurt. Je zou een email bericht moeten krijgen die je over het nieuwe Pull Request bericht en die er ongeveer zo uitziet als Email bericht van een nieuwe Request..

Er zijn een aantal dingen te zien aan deze email. Het geeft je een kleine diffstat — een lijst met bestanden die gewijzigd zijn in de Pull Request en hoezeer ze zijn gewijzigd. Het geeft je een link naar de Pull Request op GitHub. Het geeft je ook een aantal URLs die je vanaf de commando regel kunt gebruiken.

Als je de regel bekijkt waar git pull <url> patch-1 staat, is dit een eenvoudige manier om een remote branch te mergen zonder een remote toe te voegen. We hebben dit kort behandeld in Remote branches uitchecken. Als je wilt, kan je een topic branch maken en ernaar switchen en dit commando aanroepen om de Pull Request wijzigingen erin te mergen.

De andere interessante URLs zijn de .diff en .patch URLs, die zoals je zult vermoeden, de unified diff en patch versies van de Pull Request geven. Je zou technisch gesproken de Pull Request in je werk mergen met zoiets als dit:

Zoals behandeld in De GitHub flow, kan je nu een conversatie voeren met de persoon die de Pull Request geopend heeft. Je kunt commentaar geven op specifieke regels code, commentaar geven op hele commits of commentaar geven over de gehele Pull Request; waarbij de GitHub smaak van Markdown overal gebruikt kan worden.

Elke keer als iemand anders commentaar geeft op de Pull Request blijf je e-mails ontvangen zodat je weet dat er activiteit plaatsvindt. Alle betrokkenen krijgen een link naar de Pull Request waar de activiteit op plaatsvindt en je kunt ook direct de mail beantwoorden (reply-to) om commentaar op de Pull Request conversatie te geven.

Zodra de code goed genoeg is en je het wilt mergen, kan je ofwel de code lokaal pullen en mergen met de git pull <url> <branch> syntax die we eerder gezien hebben, of door de fork als remote toe te voegen en dan te fetchen en mergen.

Als de merge triviaal is, kan je ook gewoon de “Merge” knop op de GitHub site klikken. Dit zal een “non-fast-forward” merge uitvoeren, waardoor een merge commit wordt gemaakt zelfs als er een fast-forward merge mogelijk was. Dit houdt in dat hoe dan ook, elke keer als je de merge knop klikt een merge commit gemaakt wordt. Zoals je kunt zien in Merge knop en instructies hoe je een Pull Request handmatig merged., geeft GitHub je al deze informatie als je de hint link klikt.

Als je besluit dat je het niet wilt mergen, kan je ook gewoon het Pull Request sluiten en de persoon die het geopend heeft krijgt een berichtje.

Als je te maken hebt met veel Pull Requests en niet elke keer een aantal remotes wilt toevoegen of eenmalige pulls wilt doen, is er een aardige truuk die GitHub je toestaat te doen. Dit is een beetje een truuk voor gevorderden en we zullen de details beter behandelen in De Refspec, maar het kan behoorlijk handig zijn.

GitHub presenteert de Pull Request branches voor een repository als een soort van pseudo-branches op de server. Standaard zal je ze niet krijgen als je kloont, maar ze zijn er wel op een verborgen manier en je kunt ze op een redelijk eenvoudige wijze benaderen.

Om dit te demonstreren, zullen we een low-level (laag niveau) commando (waar vaak aan wordt gerefereerd als een “sanitaire voorziening” (plumbing) commando, waar we meer over zullen lezen in Binnenwerk en koetswerk (plumbing and porcelain)) genaamd ls-remote gebruiken. Dit commando wordt over het algemeen niet gebruikt in de dagelijks Git operaties maar het is handig om te laten zien welke referenties er zich op de server bevinden.

Als we dit commando gebruiken met de “blink” repository die we eerder zagen, krijgen we een lijst van alle branches, tags en andere refernties in de repository.

Natuurlijk, als je in je repository bent en je gebruikt git ls-remote origin of welke remote je ook wilt controleren, zal het je iets vergelijkbaars laten zien.

Als de repository op GitHub is en er zijn Pull Requests die open staan, zal je deze referenties krijgen die een prefix refs/pull/ hebben. Dit zijn eigenlijk gewoon branches, maar omdat deze niet onder refs/heads/ vermeld staan krijg je ze normaalgesproken niet als je van de server kloont of fetcht — het proces van fetchen negeert ze gewoonlijk.

Er zijn twee referenties per Pull Request - degene die op /head eindigt wijst naar precies dezelfde commit als de laatste commit in de Pull Request branch. Dus als iemand in onze repository een Pull Request opent en zijn branch heeft de naam bug-fix` en deze wijst naar commit a5a775, dan zal in onze repository geen branch bug-fix aanwezig zijn (omdat deze in hun fork zit), maar we hebben wel pull/<pr#>/head die wijst naar a5a775. Dit betekent dat we relatief eenvoudig in één keer elke Pull Request branch kunnen pullen zonder daarvoor een heleboel remotes hoeven toe te voegen.

Nu kan je iets doen wat lijkt op het direct fetchen van de referentie.

Dit zegt tegen Git, “Maak contact met de origin remote, en download de ref genaamd refs/pull/958/head.” Git gehoorzaamt trouw, en zal alles downloaden wat je nodig hebt om die ref samen te stellen, en zal een verwijzing naar de commit die je wilt onder .git/FETCH_HEAD zetten. Je kunt daarna een git merge FETCH_HEAD doen in een branch waar je dit in wilt testen, maar dat merge commit bericht zal er wat vreemd uitzien. Daarnaast, als je veel pull requests zal reviewen, wordt dit erg vervelend.

Er is ook een manier om alle pull requests te fetchen en ze up-to-date te houden elke keer als je contact maakt met de remote. Open .git/config in je favoriete editor, en ga op zoek naar de origin remote. Dat zou er zo ongeveer uit moeten zien:

De regel die begint met fetch = is een “refspec.” Het is een manier om namen op de remote te mappen met namen in je lokale .git directory. Deze specifieke zegt tegen Git: "de spullen op de remote die onder refs/heads staan moeten in mijn lokale repository onder refs/remotes/origin worden geplaatst." Je kan deze sectie wijzigen door een andere refspec toe te voegen:

Die laatste regel vertelt Git, “Alle refs die er als refs/pull/123/head uitzien moeten lokaal worden opgeslagen als refs/remotes/origin/pr/123.” Als je dit bestand nu opslaat en een git fetch uitvoert:

Nu worden alle remote pull request lokaal vertegenwoordigt met refs die zich vrijwel hetzelfde gedragen als tracking branches: ze zijn alleen-lezen, en ze worden geüpdatet als je een fetch doet. Dat maakt het enorm makkelijk om de code van een pull request lokaal uit te checken:

De oplettende lezers tussen jullie zullen de head aan het eind van het remote deel van de refspec hebben opgemerkt. Er is ook een refs/pull/#/merge ref aan de GitHub kant, welke de commit vertegenwoordigt die het resultaat zou zijn als je op de “merge” knop op de site zou klikken. Dit stelt je in staat de merge te testen zelfs voordat je de knop klikt.

Je kunt niet alleen Pull Requests openen die de main of master-branch betreffen, je kunt zelfs een Pull Request openen die betrekking heeft op elke willekeurige branch in het netwerk. Je kunt zelfs een Pull Request openen op een andere Pull Request.

Als je een Pull Request ziet die de juiste kant op gaat en je hebt een idee voor een verandering die daarvan afhankelijk is of je weet niet zeker of het een goed idee is, of je hebt domweg geen push-toegang op de doelbranch, kan je een Pull Request direct op de Pull Request openen.

Als je een Pull Request opent, is er een invoerveld bovenaan op de pagina die aangeeft naar welke branch je wilt laten pullen en welke je het van wilt laten pullen. Als je de “Edit” knop rechts van dat invoerveld klikt kan je niet alleen de branches wijzigen, maar ook welke fork.

Hier kan je redelijk eenvoudig aangeven om jouw nieuwe branch in een andere Pull Request te mergen of in een andere fork van het project.

Als we hier over “meldingen” spreken in de context van GitHub, bedoelen we de specifieke manier waarop GitHub probeert om met je in contact te blijven als er gebeurtenissen zijn en er zijn een aantal manieren waarop je dit kunt configureren. Als je naar de “Notification center” tab van de instellingen pagina gaat, kan je een aantal opties zien die je hebt.

De twee keuzes zijn om de berichten via “Email” en via “Web” te ontvangen en je kunt een van twee, geen of beide selecteren als je actief deelneemt aan zaken en voor activiteiten op repositories die je volgt.

Als je een branch anders dan “master” gebruikt als je standaard branch waarvan je wilt dat mensen er Pull Requests op openen of die ze standaard zien, kan je dat in de instellingen pagina van je repository wijzigen onder de “Options” tab.

Eenvoudigweg de standaard branch in de dropdown wijzigen en dat wordt vanaf dat moment de standaard-branch voor alle belangrijke handelingen, inclusief welke branch er standaard uitgechecked wordt als iemand de repository kloont.

Als je een project wilt overdragen aan een andere gebruiker of organisatie in GitHub, is er een “Transfer ownership” optie onderaan dezelfde “Options” tab van de instellingen pagina van je repository die je dat kan laten doen.

Dit is handig als je een project verlaat en iemand anders wilt het overnemen, of je project wordt groter en je wilt het in een organisatie onderbrengen.

Niet alleen verplaatst dit de repostory met al zijn volgers en sterren naar een andere plaats, het richt ook een redirect (doorverwijzing) van jouw URL naar de nieuwe plaats. Het zal ook de clones en fetches van Git doorverwijzen, niet alleen de web-aanvragen.