6.3 GitHub - Förvalta ett projekt

Någon gör en ändring i din kod och skickar en ändringsförfrågan till dig. Du bör få ett e-postmeddelande som informerar om den nya ändringsförfrågan och det bör se ut ungefär som E-postavisering om en ny ändringsförfrågan.

Det finns några saker att lägga märke till i det här e-postmeddelandet. Det ger dig en liten diffstatistik — en lista över filer som har ändrats i ändringsförfrågan och hur mycket. Det ger dig en länk till ändringsförfrågan på GitHub. Det ger dig också några URL:er du kan använda från kommandoraden.

Om du tittar på raden som säger git pull <url> patch-1 är det ett enkelt sätt att sammanfoga en fjärrgren utan att lägga till ett fjärrkodförråd. Vi tog upp detta kort i Checka ut fjärrgrenar. Om du vill kan du skapa och byta till en ämnesgren och sedan köra detta kommando för att sammanfoga ändringsförfrågans ändringar.

De andra intressanta URL:erna är .diff- och .patch-adresserna, som ger sammanfogad diff respektive ändringspatchversion av ändringsförfrågan. Du skulle rent tekniskt kunna sammanfoga ändringsförfrågans arbete med något som:

Som vi beskrev i GitHub-flödet kan du nu ha en dialog med personen som öppnade ändringsförfrågan. Du kan kommentera specifika kodrader, kommentera hela incheckningar eller kommentera hela ändringsförfrågan, och använda GitHub-anpassad Markdown överallt.

Varje gång någon annan kommenterar ändringsförfrågan får du fortsatt e-postaviseringar så att du vet att det händer något. De kommer var och en att ha en länk till ändringsförfrågan där aktiviteten pågår, och du kan också svara direkt på e-postmeddelandet för att kommentera i ändringsförfrågans tråd.

När koden är där du vill ha den och du vill sammanfoga den kan du antingen dra ner koden och sammanfoga den lokalt, antingen med syntaxen git pull <url> <gren> som vi såg tidigare, eller genom att lägga till avgreningen som fjärrkodförråd och uppdatera och sammanfoga.

Om sammanslagningen är trivial kan du också bara trycka på knappen "Sammanfoga" på GitHubs webbplats. Det gör en icke-snabbspolad sammanslagning, vilket skapar en sammanslagningsincheckning även om en snabbspolning varit möjlig. Det betyder att oavsett vad skapas en sammanslagningsincheckning varje gång du trycker på sammanslagningsknappen. Som du ser i Sammanslagningsknapp och instruktioner för att sammanfoga en ändringsförfrågan manuellt ger GitHub all denna information om du klickar på hintlänken.

Om du bestämmer dig för att inte sammanfoga kan du också bara stänga ändringsförfrågan och personen som öppnade den får en avisering.

Om du hanterar många ändringsförfrågningar och inte vill lägga till en massa fjärrkodförråd eller göra engångsdragningar varje gång finns det ett snyggt knep som GitHub låter dig använda. Det här är lite avancerat och vi går igenom detaljerna mer i Refspecen, men det kan vara mycket användbart.

GitHub exponerar ändringsförfrågegrenar för ett kodförråd som en slags pseudogrenar på servern. Som standard får du dem inte när du klonar, men de finns där på ett mer dolt sätt och du kan komma åt dem ganska enkelt.

För att demonstrera detta använder vi ett lågnivåkommando (plumbing‑kommando, som vi läser mer om i Lågnivådel och användardel) som heter ls-remote. Det kommandot används normalt inte i vardagliga Git-operationer, men det är användbart för att visa vilka referenser som finns på servern.

Om vi kör detta kommando mot "blink"-kodförrådet vi använde tidigare får vi en lista över alla grenar, taggar och andra referenser i kodförrådet.

Om du är i ditt kodförråd och kör git ls-remote origin eller vilket fjärrkodförråd du vill kontrollera ser det liknande ut.

Om kodförrådet ligger på GitHub och du har några öppna ändringsförfrågningar får du dessa referenser med prefixet refs/pull/. Det här är i praktiken grenar, men eftersom de inte ligger under refs/heads/ får du dem inte normalt när du klonar eller uppdaterar från servern — uppdateringen ignorerar dem normalt.

Det finns två referenser per ändringsförfrågan - den som slutar på /head pekar på exakt samma incheckning som den sista incheckningen i ändringsförfrågans gren. Så om någon öppnar en ändringsförfrågan i vårt kodförråd och deras gren heter bug-fix och pekar på incheckningen a5a775, kommer vi i vårt kodförråd inte ha någon gren bug-fix (den ligger i deras avgrening), men vi kommer ha pull/<pr#>/head som pekar på a5a775. Det betyder att vi ganska enkelt kan dra ner varje ändringsförfrågegren i ett svep utan att behöva lägga till en massa fjärrkodförråd.

Nu kan du till exempel uppdatera referensen direkt.

Det här säger till Git: "Anslut till fjärrkodförrådet origin och uppdatera referensen refs/pull/958/head." Git lyder och uppdaterar allt du behöver för att bygga referensen, och lägger en pekare till den incheckning du vill ha i .git/FETCH_HEAD. Du kan följa upp med git merge FETCH_HEAD in i en gren du vill testa i, men sammanslagningsmeddelandet ser lite konstigt ut. Om du granskar många ändringsförfrågningar blir det dessutom tröttsamt.

Det finns också ett sätt att uppdatera alla ändringsförfrågningar och hålla dem uppdaterade varje gång du ansluter till fjärrkodförrådet. Öppna .git/config i din favoritredigerare och leta efter fjärrkodförrådet origin. Den bör se ut ungefär så här:

Raden som börjar med fetch = är en "referensspecifikation". Det är ett sätt att mappa namn på fjärrkodförrådet till namn i din lokala .git-katalog. Den här berättar för Git att "det som ligger i fjärrkodförrådet under refs/heads ska hamna i mitt lokala kodförråd under `refs/remotes/origin`". Du kan ändra detta avsnitt för att lägga till ytterligare en referensspecifikation:

Den sista raden säger till Git: "Alla referenser som ser ut som refs/pull/123/head ska lagras lokalt som refs/remotes/origin/pr/123." Om du nu sparar filen och kör git fetch:

Nu representeras alla ändringsförfrågningar från fjärrkodförrådet lokalt med referenser som fungerar ungefär som spårande grenar; de är skrivskyddade och uppdateras när du gör en uppdatering. Det gör det väldigt enkelt att testa koden från en ändringsförfrågan lokalt:

Den vaksamme noterar head i slutet av fjärrdelen av referensspecifikationen. Det finns också en refs/pull/#/merge-referens på GitHub-sidan, som representerar den incheckning som skulle skapas om du trycker på knappen "Sammanfoga" på webbplatsen. Det gör att du kan testa sammanslagningen innan du ens trycker på knappen.

Du kan inte bara öppna ändringsförfrågningar som riktar sig mot huvudgrenen eller master-grenen, du kan öppna en ändringsförfrågan mot vilken gren som helst i nätverket. Faktum är att du till och med kan rikta mot en annan ändringsförfrågan.

Om du ser en ändringsförfrågan som rör sig i rätt riktning och du har en idé om en ändring som beror på den, eller om du inte är säker på att idén är bra, eller om du helt enkelt inte har skrivrättigheter till målgrenen, kan du öppna en ändringsförfrågan direkt mot den.

När du öppnar en ändringsförfrågan finns det en ruta högst upp på sidan som anger vilken gren du begär att dra in till och vilken du begär att dra in från. Om du klickar på knappen "Edit" till höger om rutan kan du ändra inte bara grenarna utan även vilken avgrening.

Här kan du ganska enkelt ange att sammanfoga din nya gren i en annan ändringsförfrågan eller en annan avgrening av projektet.

När vi pratar om aviseringar i GitHub menar vi ett särskilt sätt som GitHub försöker nå dig när händelser inträffar, och det finns flera sätt du kan konfigurera det. Om du går till fliken "Aviseringscenter" från inställningssidan kan du se några av de alternativ du har.

De två valen är att få aviseringar via "E-post" och via "Webb", och du kan välja antingen, inget eller båda för sådant du aktivt deltar i och för aktivitet i kodförråd du följer.

Om du använder en annan gren än "master" som standardgren som du vill att folk ska öppna ändringsförfrågningar mot eller se som standard kan du ändra det på inställningssidan för ditt kodförråd under fliken "Options".

Ändra standardgrenen i rullgardinen så blir den standard för alla större operationer framöver, inklusive vilken gren som växlas till som standard när någon klonar kodförrådet.

Om du vill flytta ett projekt till en annan användare eller en organisation i GitHub finns ett alternativ "Transfer ownership" längst ned på samma flik "Options" i kodförrådets inställningar som låter dig göra detta.

Det här är användbart om du överger ett projekt och någon vill ta över det, eller om ditt projekt växer och du vill flytta det till en organisation.

Detta flyttar inte bara kodförrådet tillsammans med alla följare och stjärnor till en annan plats, det sätter också upp en omdirigering från din URL till den nya platsen. Det omdirigerar också klonningar och uppdateringar i Git, inte bara webbförfrågningar.