Git Branches gebruiken om je programmeerproject te structureren

Films en televisie beelden programmering uit als een hectische activiteit Hollywood-hacks: de beste en slechtste hacking in films Hollywood-hacks: de beste en slechtste hacking in films Hollywood en hacking komen niet met elkaar overeen. Hoewel hacking in de echte wereld moeilijk is, moet je bij filmhacken vaak gewoon op een toetsenbord bonzen, alsof je vingers hun stijl verliezen. Lees verder . De timer van een bom telt af en de nerdige sidekick die tot dan toe een last was, werkt koortsachtig op een laptop. Code vliegt over het scherm totdat ze de laatste return-toets raakt met een tevredenstellend klapperen! De timer stopt en alles is weer goed in de wereld. Maar programmeren lijkt hier niet op. Het omvat ontwerpdocumenten, UI-mock-ups en codebeoordelingen. En bovenal gaat het om trial-and-error, vooral als je een beginner bent (zoals ik).

Nu ben je misschien al overtuigd van de waarde van het houden van je coderingsprojecten in bronbeheer Wat is Git en waarom zou je versiebeheer moeten gebruiken als je een ontwikkelaar bent Wat is Git en waarom zou je versiebeheer moeten gebruiken als je een ontwikkelaar bent Als webontwikkelaars werken we vaak vaak op lokale ontwikkelsites en uploaden we vervolgens alles wanneer we klaar zijn. Dit is prima als je alleen bent en de veranderingen klein zijn, ... Lees meer. Door al deze vallen en opstaan ​​toe te wijzen aan je repository, ontstaat een groot en slordig project, met veel herzieningen. De meeste commits die je maakt bevatten dingen die kapot zijn, dus waarom zou je het opslaan? De git tak functie kan helpen om al deze rommelige code weg te houden van de dingen waarvan u weet dat ze werken.

In dit artikel bekijken we wat vertakking van uw code betekent, hoe u dit moet doen en hoe u updates voor de code kunt beheren “hoofd” tak.

Een Git Branch creëren

We hebben geleerd van onze introductie tot bronbeheer Beheer uw bestandsversies zoals een programmeur met Git Beheer uw bestandsversies zoals een programmeur met Git Programmeurs hebben versiecontrolesystemen (VCS) gemaakt om beheersingsproblemen met bestandsversies op te lossen. Laten we de basis van versiebeheer bekijken met behulp van het topsysteem van vandaag, Git. Lees Meer dat u een nieuwe repository kunt maken met de volgende opdracht in een terminal:

git init

Wanneer u dit doet, wordt een verborgen map in uw huidige pad gemaakt, genaamd “.git.” Als u het niet kunt zien, kunt u enkele van onze eerdere artikelen over het verbergen van verborgen manieren raadplegen. Eenvoudige manieren om verborgen bestanden en mappen te tonen in Windows 10, 8.1 en 7 De eenvoudige manier om verborgen bestanden en mappen te tonen in Windows 10, 8.1 en 7 Wilt u verborgen bestanden en mappen in Windows zien? U kunt ze als volgt weergeven in Windows 10, 8.1 en 7, zodat niets voor u verborgen is. Meer bestanden lezen Verberg en vind elk bestand op Mac OS X Verberg en vind elk bestand op Mac OS X Er is geen eenvoudige manier om verborgen bestanden snel te verbergen of te onthullen op Mac OS X zoals er op Windows is - maar het is mogelijk. Lees verder . Deze map bevat alle informatie die nodig is om de revisiegeschiedenis van uw bestanden te behouden. Nadat u uw bestandsbeheerder hebt ingesteld om verborgen bestanden weer te geven, kunt u de map .git openen en een aantal submappen bekijken. Een daarvan wordt genoemd “scheidsrechters” (getoond in de afbeelding hieronder), en zijn “hoofden” subdirectory bevat overzichten voor alle vestigingen in uw project. In het begin heb je er slechts één, genaamd “meester.”

De refs-directory houdt de branch bij, maar niet de branch zelf. Tenminste, niet de tak die je bent momenteel gebruiken. Die bestanden worden bewaard in de werkdirectory (“~ / Temp / post-programmering-git-branch” in het bovenstaande voorbeeld) zodat u ze op een normale manier kunt openen. Als we dat precies doen, creëren we ons eerste bestand (genaamd “eerste bestand.txt”) in de werkdirectory, d.w.z.. buiten de .git-map. Vink dit aan met behulp van de vertrouwde commando's van de eerdere intro om het artikel te beheren Beheer uw bestandsversies zoals een programmeur met Git Beheer uw bestandsversies zoals een programmeur met Git Programmeurs hebben versiecontrolesystemen (VCS) gemaakt om problemen met bestandsversiebeheer op te lossen. Laten we de basis van versiebeheer bekijken met behulp van het topsysteem van vandaag, Git. Lees verder :

We kunnen nu zien dat de werkdirectory twee bestanden heeft, degene die we hebben gecommit en één automatisch gemaakt door git (het bevat het commit-bericht dat we zojuist hebben ingevoerd).

Laten we nu een nieuwe git branch maken genaamd “testing”:

git branch testen

De tak onderzoeken en erin werken

We kunnen het bovenstaande commando zonder enige naam geven om een ​​lijst van alle branches te krijgen, evenals die welke we momenteel gebruiken (d.w.z. “uitgechecked”):

Nu, als we de directorystructuur bekijken, zullen we zien “.git / refs / heads” heeft nu twee bestanden, elk voor één “meester” en “testing.”

Elk van deze is een lijst van de commits die de branch vormen. Als we bijvoorbeeld de “meester” tak met de “git log” opdracht, kunnen we een regel zien voor elke toewijzing aan die tak.

Het proces van “uitchecken” een branch betekent dat wijzigingen die u aanbrengt in bestanden deel zullen uitmaken van die branch, maar niet van andere branches. Stel dat we de test git branch bekijken met de volgende opdracht:

git checkout testen

Vervolgens voegen we een regel tekst toe aan first-file.txt, uiteraard daarna vastleggen. Als u teruggaat naar de hoofdtak, ziet u dat het bestand nog steeds leeg is (de kat command toont de inhoud van een bestand in de terminal):

Maar terug naar de “testing” branch, heeft het bestand nog steeds de toegevoegde tekst:

Maar alles wat we ooit in de juiste map zien, is het enkele bestand “eerste bestand.txt.” Waar zijn dan deze twee alternatieve versies van hetzelfde bestand? De .git-map is verantwoordelijk voor deze wijzigingen, maar niet op de manier die u zou verwachten.

Hoe Git dingen opslaat

Als je een repository zou onderzoeken voor andere versiecontrolesystemen zoals Subversion, zou je merken dat ze één kopie per revisie behouden voor elk afzonderlijk bestand. Dit betekent dat als u een repository van één bestand hebt en vervolgens twee branches maakt, de repo twee verschillende exemplaren van dat bestand bevat. Eigenlijk gebruik je het eigenlijk “svn kopie” als het commando om een ​​filiaal te maken in Subversion! Aan de andere kant, git werkt op het concept van “veranderingen.”

De uitvoer van het bovenstaande vertelt ons de volledige inhoud van “romp” (SVN's versie van “meester”) is gekopieerd. Een blik in een bestandsbeheerder bevestigt dit:

De “.git / objecten” map is wat al deze kleine veranderingen bevat, en elke wordt gevolgd met een ID. In de onderstaande afbeelding ziet u bijvoorbeeld bestanden met lange ID-stijlnamen. Elk leeft in een map met de naam twee hexadecimale tekens (8c en 8d hieronder).

Samen vormen deze map- en bestandsnamen de ID voor een bepaalde wijziging (eigenlijk een SHA1-hash). Je kunt hun inhoud verkennen met behulp van de git cat-file commando. Op basis van hun aangepaste datums kunnen we het begin zien “8d” kwam eerst, en het toont niets. Terwijl degene die begint “8c” bevat de tekstregel die we hebben toegevoegd aan het bestand in de “testing” tak.

De afhaalmaaltijd is dat git branches (inclusief de standaard “meester”) zijn niet gescheiden “mappen” kopieën van bestanden bevatten. Het zijn eerder lijsten met wijzigingen die in de loop van de tijd in bestanden zijn aangebracht. Dit is efficiënter qua opslag, maar het resultaat is hetzelfde. Alles wat je doet (pauze?) In een git branch blijft daar totdat je het samenvoegt.

Strategieën voor het samenvoegen naar de hoofdtak (om te verwijderen of niet om te verwijderen?)

Stel dat u een bestaand project had met een aantal bestanden, waar u vervolgens op vertakt “testing,” en hebben er wat aan gewerkt. Nu wil je die veranderingen terug in de “meester” tak. U kunt het volgende doen vanuit de “meester” tak:

git merge testen

Op voorwaarde dat er geen conflicten zijn, de verandering bestaande uit de nieuwe tekst zal zijn toegepast naar “meester.” Het resultaat is “eerste bestand.txt” zal identiek zijn in beide takken. Toch waren er nooit echt alternatieven versies van het bestand.

Nu komt de vraag, wat te doen met de tak? Er zijn twee gemeenschappelijke strategieën voor het omgaan met filialen.

1. Een daarvan is om een ​​git branch te houden “testing” om te spelen in (hierboven weergegeven). Je probeert een aantal dingen uit en, als je ze kunt laten werken, voeg de veranderingen dan weer samen “meester.” Dan kun je het werk aan die tak beëindigen, of er zelfs helemaal vanaf komen. Dit betekent jouw “meester” is de meest stabiele versie van de code, omdat deze alleen dingen bevat waarvan u weet dat ze werken. Je kunt deze benadering ook zien als gebruiken “kenmerk takken.” Dit komt omdat het hun doel is om een ​​(of meerdere) specifieke toevoegingen aan de code te verfijnen.
2. Een andere aanpak is om al je hoofdwerk in de “meester” branch, commits maken onderweg. Als je eenmaal tevreden bent met de functionaliteit, creëer je een branch binnenin die je bug-fixing en dergelijke doet. Dit resulteert in meer van a “releasetak” (hieronder weergegeven), omdat ze eindigen met de release. Het betekent ook jouw “meester” tak is meestal de meest onstabiele versie van uw code.

Gebruik de methode die het beste voor u is

De eerste aanpak hier komt vaker voor bij het werken met git. De andere functies (met name tags) maken het gemakkelijk om een ​​bepaalde momentopname van de code te markeren als “stal.” Het leent zich ook beter voor grotere, samenwerkende projecten. Maar wanneer je aan je eigen persoonlijke projecten werkt, voel je dan vrij om te gebruiken wat je het meest logisch vindt. Het geweldige aan git gebruiken is dat je al je veranderingen vastlegt, zodat je altijd terug kunt gaan om iets te vinden. En het organiseren van je project met git branches maakt dat een beetje makkelijker om te doen.

Hoe benader je branches in je projecten? Gebruik je ze om te experimenteren en daarna achteraf te vernietigen? Of vertegenwoordigen ze een gedetailleerde geschiedenis van uw werk aan het project?

Laat het ons hieronder weten in de comments als je slimme manieren hebt om met branches in je git-projecten om te gaan!