In onze vorige tutorials voor de git-versiebeheersoftware hebben we de essentiële basisopdrachten voor het gebruik van git geleerd, zoals en hoe je met Github.com kunt werken om een repository op te zetten en onze projectcode naar de website te pushen.
Nu is het tijd om daadwerkelijk met GitHub (en git) te gaan werken zoals ze bedoeld zijn gebruikt: wijzigingen in het project veilig opzij zetten en ze weer samenvoegen in het oorspronkelijke project zodra ze correct zijn gebleken. Of in ieder geval niet rampzalig.
Inmiddels begrijp je dat git elke versie van je project opslaat als een momentopname van de code, precies zoals het was op het moment dat je het vastlegde. In wezen een tijdlijn maken van versies van een project naarmate het vordert, zodat je kunt teruggaan naar een eerdere versie in het geval een ramp toeslaat.
De manier waarop git, en GitHub, deze tijdlijn beheren – vooral wanneer meer dan één persoon werkt in het project en brengt wijzigingen aan – door middel van branches. Een branch is in wezen een unieke reeks codewijzigingen met een unieke naam. Elke repository kan een of meer vertakkingen hebben. De hoofdtak – degene waar alle wijzigingen uiteindelijk weer in worden samengevoegd, en wordt master genoemd. Dit is de officiële werkende versie van je project, en degene die je ziet als je de projectrepository bezoekt op github.com/yourname/projectname.
Knoei niet met de master. Als je wijzigingen aanbrengt in de hoofdtak van een groepsproject terwijl andere mensen er ook aan werken, zullen je on-the-fly veranderingen uitvloeien om iedereen te beïnvloeden en heel snel zullen er samenvoegconflicten, huilen, scheurende kledingstukken zijn, en plagen van sprinkhanen. Het is zo serieus.
Waarom is de meester zo belangrijk om niet mee te rotzooien? Eén woord: de master branch is inzetbaar. Het is uw productiecode, klaar om de wereld in te rollen. De master branch is bedoeld om stabiel te zijn, en het is het sociale contract van open source software om nooit iets onder de knie te krijgen dat niet getest is, of dat de build verstoort. De hele reden dat GitHub werkt, is dat het altijd veilig is om vanuit de master te werken.
Branching Out
In plaats daarvan gebruikt iedereen branches die van master zijn gemaakt om te experimenteren, bewerkingen en toevoegingen en wijzigingen aan te brengen , voordat ze die branch uiteindelijk terug in de master rollen zodra ze zijn goedgekeurd en waarvan bekend is dat ze werken. Master wordt dan bijgewerkt om al het nieuwe spul te bevatten.
Om aan iets nieuws in een project te gaan werken, of om bestaande dingen te veranderen, maak je een branch van de stable master branch aan. Laten we verder werken met het voorbeeldproject dat is gemaakt voor onze vorige tutorial, good ol ’studious_octo_carnival. Open nu alstublieft uw versie op uw computer en cd in de directory.
Stap 1: inventariseer.
Voordat we nieuwe branches aanmaken, willen we controleren of er andere bestaande branches zijn . We weten van de meester af, maar wie weet wat onze projectmedewerkers van plan zijn, die ondeugende apen? We kunnen dus alle bestaande branches bekijken door “git branch -a” in terminal te typen, wat git vertelt dat we ALLE branches in dit project willen zien, zelfs degene die niet in onze lokale werkruimte staan.
Hiermee wordt uitvoer geretourneerd die u in het onderstaande codevoorbeeld ziet. Het uiterlijk kan enigszins variëren, afhankelijk van uw besturingssysteem en terminaltoepassing, maar de informatie is uiteindelijk hetzelfde. Het sterretje naast ‘master’ in de eerste regel van de uitvoer geeft aan dat we momenteel op die tak. De tweede regel vertelt ons dat er op onze remote, genaamd origin, een enkele branch is, ook wel master genoemd. (Onthoud dat onze afstandsbediening de GitHub-opslagplaats voor dit project is).
Stap 2: maak een nieuwe branch
Nu we weten hoe we branches moeten bekijken, gaan we er een maken! Houd gaandeweg in gedachten dat we onze master branch hebben, ons oorspronkelijke project. We gaan nu een nieuwe versie van het project maken, een branch, om mee te spelen en lokaal wijzigingen aan te brengen op onze computer – terwijl de originele versie van het project, de master, veilig ongemoeid blijft daarboven op GitHub. We geven de nieuwe branch een beschrijvende naam om ons eraan te herinneren wat we van plan zijn te doen terwijl we erin werken. In dit geval wordt het een simpel “Hallo Wereld” dingetje, dus laten we het hello_octo noemen.
Om deze nieuwe branch aan te maken, typ je “git checkout -b branchNameHere” (dus, in ons geval, “git checkout -b hello_octo”).
Ervan uitgaande dat niemand anders al een branch heeft gemaakt met de naam “hello_octo”, retourneert git “Switched to a new branch ‘hello_octo’.” (In het geval dat er al een branch met die naam bestaat, zou git ons in plaats daarvan vertellen “fatal: A branch genaamd ‘hello_octo’ bestaat al.” Geen probleem, doe gewoon git checkout -b opnieuw met een nieuwe naamvariatie). / p>
We kunnen ook het git checkout commando gebruiken om heen en weer te schakelen tussen onze twee branches. Typ “git checkout branchName” om naar die branch te gaan.Dus “git checkout master” neemt je mee naar master terwijl “git checkout hello_octo” je terugbrengt naar hello_octo branch.
Als je probeert over te schakelen naar een branch die niet bestaat, zoals “git checkout hello_kitty”, zal git je laten weten dat dit een no-go is:
Hoe weet git in welke branch je je momenteel bevindt? Git let altijd op wat je doet en houdt een speciale pointer bij met de naam HEAD. Zoals de naald op een kompas altijd naar het noorden wijst, geeft HEAD altijd de lokale branch waar je momenteel op zit.
(We hadden ook onze branch kunnen maken met behulp van het git commando “git branch branchNameHere”, en er dan naar overschakelen met git checkout. De handige kleine snelkoppeling met de “-b” in “git checkout -b branchNameHere” maakt beide de branch aan EN schakelt er naartoe. Ik kan je niet vertellen hoeveel new-to-git coders foutmeldingen en frustratie genereren omdat ze zich simpelweg niet hebben herinnerd om naar hun nieuwe branch te gaan na het maken van i t. Daarom houden we vast aan git checkout -b, mmmkay?)
Veranderingen aanbrengen in onze werkende branch
Nu we meerdere branches hebben – onze werkende branch om wijzigingen aan te brengen, en onze master branch blijft veilig ongemoeid – we kunnen aan het werk. In ons scenario gaan we onze “hello_octo” branch gebruiken voor het maken en testen van onze wijzigingen, en deze dan terug pushen naar de master branch op GitHub.
Vergeet niet om ervoor te zorgen dat je op jouw werkende branch, en niet master, met de goede oude git branch -a.
Stap 3. Maak een nieuw leeg bestand aan, genaamd “hello_octo_world”:
(Dit lege bestand is alleen voor demonstratiedoeleinden, dus maak je geen zorgen dat er geen bestandsextensie naam / type is).
Aangezien het gloednieuw is, klopt nu staat dit bestand alleen op uw branch. Gebruik het “ls” commando om het te bekijken:
Onthoud echter dat we ons in onze werkende branch, hello_octo, bevinden waar we hebben dit nieuwe ding gemaakt. De master weet niets over hello_octo, omdat het veilig is geïsoleerd van alle willekeurige veranderingen die we hier op de werkende tak aanbrengen. Het is nog steeds dezelfde serene ongewijzigde master waarmee we begonnen:
Stap 4: Stage en leg ons nieuwe bestand vast in de werkende branch.
Nu is het tijd om ons nieuwe bestand op de werkende branch te stagen (toevoegen) en vast te leggen. (Klinkt bekend?). Dit zal deze nieuwe entiteit aan de werkende branch koppelen ter voorbereiding om het uiteindelijk naar master te verplaatsen. Dit bestand bestaat nu op de hello_octo branch; zoals we hierboven zagen, bestaat het momenteel niet in de master branch.
Op dit punt heb je zojuist een momentopname van wijzigingen aan de branch In een real-world project zijn er waarschijnlijk meer wijzigingen en werk te doen. Dit is wanneer je dit zou gaan doen, gaandeweg op logische punten commits maken. Onthoud dat commits op GitHub je opeenvolgende saves vertegenwoordigen. Elke commit heeft een bijbehorend commit-bericht, wat een beschrijving is die specifiek uitlegt wat je daar hebt gedaan en waarom. Commit-berichten leggen de geschiedenis van uw wijzigingen vast, zodat u in de toekomst, evenals andere projectmedewerkers, kunt begrijpen wat u hebt gedaan en waarom.
Code tussen branches samenvoegen
Zodra we zijn eindelijk klaar met alle wijzigingen en toevoegingen – en alles werkt * – het is tijd om samen te voegen. Het interessante deel komt nadat we terugschakelen naar onze master branch (wat – zeg het met mij! – we doen met “git checkout master”). “Hello_octo_world” lijkt te ontbreken, maar dat is het niet – momenteel bestaat het op onze werkomgeving. branch en we zijn op onze master branch. Ik laat je dit opnieuw zien omdat het de kern vormt van het begrijpen van branches in git:
Nu: in deze oefening , “hello_octo_world” staat voor elke wijziging in een bestand (of de toevoeging van een geheel nieuw bestand) dat alle testen op onze ontwikkelingstak heeft doorstaan en klaar is om in productie te gaan. Het proces van het verplaatsen van code tussen de takken (vaak van ontwikkeling naar production) staat bekend als merging.
Heel belangrijk: bij het mergen moeten we in de branch zijn waarnaar we willen mergen. In feite zullen we git vertellen, “Zie je dat nieuwe ding? Het is oké om het nu hierheen te brengen. ”
Stap 5: Wijzigingen in de werkende branche samenvoegen
In dit geval, omdat we willen mergen vanuit onze werkende branch, waar de” hello_octo_world ” bestand bestaat, voor onze master branch moeten we op de master staan.
Eenmaal op de master branch hoeven we alleen maar het merge commando uit te voeren. De beste manier om dit te doen is door ” git merge –no-ff ”- de extra” –no-ff “vertelt git dat we alle vastleggingsberichten willen behouden voorafgaand aan het samenvoegen Dit zal het bijhouden van wijzigingen in de toekomst gemakkelijker maken:
Terug naar GitHub
Het laatste dat we nu moeten doen, is GitHub laten weten dat we aan het rondhangen zijn met meester hier beneden over onze lokale ontwikkelingsomgeving.
Met andere woorden, het is tijd voor git push. Je hebt dit!
De git-uitvoer bevestigt dat het samenvoegen van je ontwikkeltak naar de masterbranch op je lokale omgeving, is nu gekopieerd naar de server op afstand: “master → master.”
En dat is het! We hebben met succes een werkende branch gemaakt die gescheiden is van master. Wijzigingen aangebracht. Staged en gecommitteerd die wijzigingen. terug naar de master in onze lokale werkomgeving. Vervolgens tenslotte alles naar GitHub geduwd zodat alle versies van ons project overal hetzelfde zijn!
Een laatste opmerking
Enige opruiming is nu in orde: aangezien we onze hello_octo branch met succes hebben samengevoegd, hebben we deze niet langer nodig. Om een samengevoegde branch te verwijderen, typ je gewoon “git branch -d branchName”:
Geen zorgen: als je per ongeluk een branch probeert te verwijderen die nog niet is samengevoegd, zal git een foutmelding geven.
Dus! Tot dusver hebben we een extreem vereenvoudigd voorbeeldproject gebruikt, omdat op dit punt het belangrijkste is om de git-workflow te begrijpen en te assimileren. Samenvoegen komt in de echte wereld veel meer kijken dan dit – wat gebeurt er bijvoorbeeld als u foutmeldingen krijgt omdat uw samenvoeging conflicten heeft? Geen zorgen, nieuwe git-ster, we komen er.
Je huiswerk: maak (“touch”) wat meer nieuwe bestanden in het voorbeeldproject en oefen met het aanbrengen van wijzigingen, enscenering, vastleggen en uiteindelijk samenvoegen terug. Zorg ervoor dat u begrijpt waar uw HEAD naar wijst – dwz wat uw huidige branch is. Voer alleen wijzigingen door in uw werkende branch.
Omdat, onthoud: Don’t. Mess. With. The. Master .