5.3 Gedistribueerd Git - Het beheren van een project

Als je de patch ontvangen hebt van iemand die het gegenereerd heeft met de git diff of een Unix diff commando (wat niet wordt aangeraden, zie de volgende paragraaf), kun je het toepassen met het git apply commando. Aangenomen dat je de patch als /tmp/patch-ruby-client.patch opgeslagen hebt, kun je de patch als volgt toepassen:

Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een patch -p1 commando om de patch toe te passen, alhoewel het meer paranoïde is en minder "fuzzy matches" accepteert dan patch. Het handelt ook het toevoegen, verwijderen, en hernoemen van bestanden af als ze beschreven staan in het git diff formaat, wat patch niet doet. Als laatste volgt git apply een “pas alles toe of laat alles weg” model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot patch die gedeeltelijke patches kan toepassen, waardoor je werkdirectory in een vreemde status achterblijft. Over het algemeen is git apply terughoudender dan patch. Het zal geen commit voor je aanmaken — na het uitvoeren moet je de geïntroduceerde wijzigingen handmatig stagen en committen.

Je kunt ook git apply gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet — je kunt git apply --check uitvoeren met de patch:

Als er geen uitvoer is, dan zou de patch netjes moeten passen. Dit commando retourneert ook een niet-nul status als de controle faalt, zodat je het kunt gebruiken in scripts als je dat zou willen.

Als de bijdrager een Git gebruiker is en zo vriendelijk is geweest om het format-patch commando te gebruiken om de patch te genereren, dan is je werk eenvoudiger omdat de patch de auteur-informatie en een commit-bericht voor je bevat. Als het enigzins kan, probeer dan je bijdragers aan te moedigen om format-patch te gebruiken in plaats van diff om patches voor je te genereren. Je zou alleen `git apply hoeven te gebruiken voor oude patches en dergelijke zaken.

Om een patch gegenereerd met format-patch toe te passen, gebruik je git am (het commando wordt am genoemd, omdat het wordt gebruikt om "een serie van patches toe te passen [apply] uit een mailbox". Technisch is git am gemaakt om een mbox bestand te lezen, wat een eenvoudig gewone platte tekstformaat is om één of meer e-mail berichten in een tekstbestand op te slaan. Het ziet er ongeveer zo uit:

Dit is het begin van de uitvoer van het git format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je download dat in een mbox formaat, dan kan je git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan git am gebruiken om ze één voor één toe te passen.

Maar, als iemand een patch bestand heeft geüpload die gegenereerd is met git format-patch naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan git am doorgeven om het te applyen:

Je ziet dat het netjes is toegepast, en automatisch een nieuwe commit voor je heeft aangemaakt. De auteursinformatie wordt gehaald uit de From en Date velden in de kop van de e-mail, en het bericht van de commit wordt gehaald uit de Subject en de inhoud (voor de patch) van het mailbericht zelf. Bijvoorbeeld, als deze patch was toegepast van het mbox voorbeeld hierboven, dan zou de gegenereerde commit er ongeveer zo uit zien:

De Commit informatie toont de persoon die de patch toegepast heeft en de tijd waarop het is toegepast. De Author informatie toont de persoon die de patch oorspronkelijk gemaakt heeft en wanneer het gemaakt is.

Maar het is mogelijk dat de patch niet netjes toegepast kan worden. Misschien is jouw hoofdbranch te ver afgeweken van de branch waarop de patch gebouwd is, of is de patch afhankelijk van een andere patch, die je nog niet hebt toegepast. In dat geval zal het git am proces falen en je vragen wat je wilt doen:

Dit commando zet conflict markeringen in alle bestanden waar het problemen mee heeft, net zoals een conflicterende merge of rebase operatie. Je lost dit probleem op een vergelijkbare manier op — wijzig het bestand om het conflict op te lossen, stage het bestand en voer dan git am --resolved uit om door te gaan met de volgende patch:

Als je wilt dat Git iets meer intelligentie toepast om het conflict op te lossen, kun je een -3 optie eraan meegeven, dit zorgt ervoor dat Git een driewegs-merge probeert. Deze optie staat standaard niet aan omdat het niet werkt als de commit waarvan de patch zegt dat het op gebaseerd is niet in je repository zit. Als je die commit wel hebt — als de patch gebaseerd was op een gepubliceerde commit — dan is de -3 over het algemeen veel slimmer in het toepassen van een conflicterende patch:

In dit geval, zonder de -3 optie zou het als een conflict zijn beschouwd. Omdat de de -3 optie gebruikt is, is de patch netjes toegepast.

Als je een aantal patches van een mbox toepast, kun je ook het am commando in een interactieve modus uitvoeren, wat bij iedere patch die het vindt stopt en je vraagt of je het wilt applyen:

Dit is prettig wanneer je een aantal patches opgespaard hebt, omdat je de patch eerst kunt zien als je je niet kunt herinneren wat het is, of de patch niet toepassen omdat je dat al eerder gedaan hebt.

Als alle patches voor je topic branch zijn toegepast en gecommit zijn op je branch, kan je besluiten of en hoe ze te integreren in een branch met een langere looptijd.

Een eenvoudige workflow is om al dat werk direct in de master-branch te mergen. In dit scenario heb je een master-branch die feitelijk de stabiele code bevat. Als je werk in een topic branch hebt waaraan je gewerkt hebt, of dat iemand anders heeft bijgedragen en je hebt dat nagekeken, dan merge je het in de master branch, verwijdert de topic branch en herhaalt het proces.

Bijvoorbeeld, als we een repository hebben met werk in twee branches genaamd ruby_client en php_client, wat eruit ziet zoals Historie met een aantal topic branches. en mergen eerst ruby_client en daarna php_client, dan zal je historie er uit gaan zien zoals in Na het mergen van een topic branch..

Dat is waarschijnlijk de eenvoudigste workflow, maar het wordt problematisch als je werkt met grotere of stabielere projecten waar je heel voorzichtig moet zijn met wat je introduceert.

Als je belangrijkere projecten hebt, zou je kunnen denken aan een twee-fasen merge cyclus. In dit scenario heb je twee langlopende branches, master en develop, waarin je bepaalt dat master alleen wordt geupdate als een hele stabiele release wordt gemaakt en alle nieuwe code wordt geintegreerd in de develop-branch. Je pusht beide branches regelmatig naar de publieke repository. Elke keer heb je een nieuwe topic branch om in te mergen (Voor de merge van een topic branch.), je merget deze in develop (Na de merge van een topic branch.); daarna, als je een release tagt, fast-forward je master naar waar de nu stabiele develop-branch is (Na een project release.).

Op deze manier kunnen mensen, wanneer ze de repository van jouw project klonen, ervoor kiezen om je master uit te checken om de laatste stabiele versie te maken en eenvoudig up-to-date te blijven op die versie, of ze kunnen develop uitchecken, die het nieuweste materiaal bevat. Je kunt dit concept ook doortrekken, en een intergrate-branch hebben waar al het werk wordt gemerged. Dan, als de code op die branch stabiel is en de tests passeert, kan je dit op de develop-branch mergen, als dat dan enige tijd stabiel is gebleken kan je de master-branch fast-forwarden.

Het Git project heeft vier langlopende branches: master, next, en pu (proposed updates, voorgestelde wijzigingen) voor nieuw spul, en maint voor onderhoudswerk (maintenance backports). Als nieuw werk wordt geïntroduceerd door bijdragers, wordt het samengeraapt in topic branches in de repository van de beheerder op een manier die lijkt op wat we omschreven hebben (zie Een complexe reeks van parallelle bijgedragen topic branches beheren.). Hier worden de topics geëvalueerd om te bepalen of ze veilig zijn en klaar voor verdere verwerking of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in next gemerged, en wordt die branch gepusht zodat iedereen de geïntegreerde topics kan uitproberen.

Als de topics nog werk nodig hebben, dan worden ze in plaats daarvan gemerged in pu. Zodra vastgesteld is dat ze helemaal stabiel zijn, dan worden de topics opnieuw gemerged in master. De next en pu-branches worden dan opnieuw opgebouwd vanaf de master. Dit betekent dat master vrijwel altijd vooruit beweegt, next eens in de zoveel tijd gerebaset wordt, en pu nog vaker gerebaset wordt:

Als een topic branch uiteindelijk is gemerged in master, dan wordt het verwijderd van de repository. Het Git project heeft ook een maint-branch, die geforkt is van de laatste release om teruggewerkte (backported) patches te leveren in het geval dat een onderhoudsrelease nodig is. Dus als je de Git repository kloont, dan heb je vier branches die je kunt uitchecken om het project in verschillende stadia van ontwikkeling te evalueren, afhankelijk van hoe nieuw je alles wilt hebben of hoe je wil bijdragen; en de onderhouder heeft een gestructureerde workflow om nieuwe bijdragen aan de tand te voelen. De workflow van het Git project is gespecialiseerd. Om dit goed te begrijpen zou je het Git Beheerdersgids kunnen lezen.

Andere beheerders geven de voorkeur aan rebasen of bijgedragen werk te cherry-picken naar hun master branch in plaats van ze erin te mergen, om een vrijwel lineaire historie te behouden. Als je werk in een topic branch hebt en hebt besloten dat je het wil integreren, dan ga je naar die branch en voert het rebase commando uit om de wijzigingen op je huidige master branch te baseren (of develop, enzovoorts). Als dat goed werkt, dan kun je de master-branch fast-forwarden, en eindig je met een lineaire project historie.

De andere manier om geïntroduceerd werk van de ene naar de andere branch te verplaatsen is om het te cherry-picken. Een cherry-pick in Git is een soort rebase voor een enkele commit. Het pakt de patch die was geïntroduceerd in een commit en probeert die weer toe te passen op de branch waar je nu op zit. Dit is handig als je een aantal commits op een topic branch hebt en je er slechts één van wilt integreren, of als je alleen één commit op een topic branch hebt en er de voorkeur aan geeft om het te cherry-picken in plaats van rebase uit te voeren. Bijvoorbeeld, stel dat je een project hebt dat eruit ziet als dit:

Als je commit e43a6 in je master branch wilt pullen, dan kun je dit uitvoeren

Dit pullt dezelfde wijziging zoals geïntroduceerd in e43a6, maar je krijgt een nieuwe SHA-1 waarde, omdat de toepassingsdatum anders is. Nu ziet je historie er zo uit:

Nu kun je de topic branch verwijderen en de commits die je niet wilde pullen weggooien.

Als je veel gaat mergen en rebasen, of als je een langlopende topic branch onderhoudt heeft Git een optie genaamd “rerere” die je kan helpen.

Rerere staat voor “hergebruik het opgeslagen besluit” (Reuse Recorded Resolution) - het is een manier om het andmatige conflict situatie oplossen in te korten. Als rerere is ingeschakeld, zal Git een reeks van ervoor- en erna-plaatjes van succesvolle merges bijhouden en als het opmerkt dat er een conflict is dat precies lijkt op een die je al opgelost hebt, zal het gewoon de oplossing van de vorige keer gebruiken, zonder je ermee lastig te vallen.

Deze optie komt in twee delen: een configuratie instelling en een commando. De configuratie is een rerere.enabled instelling, en het is handig genoeg om in je globale configuratie te zetten:

Vanaf nu, elke keer als je een merge doet dat een conflict oplost, zal de oplossing opgeslagen worden in de cache voor het geval dat je het in de toekomst nodig gaat hebben.

Als het nodig is kan je interacteren met de rerere cache met het git rerere commando. Als het op zich aangeroepen wordt, zal Git de database met oplossingen controleren en probeert een passende te vinden voor alle huidige merge conflicten en deze proberen op te lossen (alhoewel dit automatisch wordt gedaan als rerere .enabled op true is gezet). Er zijn ook sub-commando’s om te zien wat er opgeslagen gaat worden, om specifieke oplossingen uit de cache te verwijderen, en om de gehele cache te legen. We zullen rerere meer gedetailleerd behandelen in Rerere.