Beheer en administratie van vestigingen in GIT

EEN tak in Git het is een tak van onze repository, het is een manier om een ​​alternatief pad naar het hoofdpad te genereren. Dit stelt ons in staat om nieuwe oplossingen te verkennen zonder de basis van het programma of de applicatie die we gebruiken te hoeven wijzigen.
Maar het concept van tak Het is niet erg duidelijk wanneer we deze tool gaan gebruiken die de versies van onze projecten bestuurt. Meestal worden in andere versiecontrolesystemen de gevolgen van een project met dit concept niet meegenomen.
Velen zullen al gebruiken Git en ze hebben niet meer aandacht besteed aan takken, en in zekere zin is het begrijpelijk, want bij het hanteren van een single tak en als de ontwikkeling door één persoon wordt uitgevoerd, zou er geen overlast moeten zijn.
Maar wat als deze persoon enkele experimentele functies wil testen die ervoor kunnen zorgen dat hun project mislukt of gewoon de stabiliteit van het project aantast, sommigen zullen zeggen dat een vork van het project en blijf experimenteren en als de verbetering succesvol is, denk er dan over na om wat er in de vork is gedaan op te nemen in het hoofdproject. Dit is echt een beetje een lange en onnodige klus.
In het bovenstaande geval maakt u gewoon een nieuwe tak binnen het betreffende project kunnen we alle gewenste veranderingen en experimenten doorvoeren en op het einde eenvoudig door een samenvoegen of fusie met de tak initial of main zullen we al onze wijzigingen hebben toegevoegd.
een ander gevalEen ander geval is wanneer we een werkteam hebben waar twee mensen die aan dezelfde code werken conflicten kunnen veroorzaken, dit is waar Git brengt zijn kracht naar voren. We kunnen een structuur maken van drie takken bijvoorbeeld een vertakking voor elke ontwikkelaar en een eenwording tak. Op deze manier kan elke ontwikkelaar zijn wijzigingen opnemen en wanneer ze denken dat ze deze kunnen bijdragen aan het project, sturen ze ze naar de tak van eenwording en dus de andere persoon of de andere leden van het team hebben er toegang toe.
We begrijpen al de redenen die ons ertoe brengen om te gebruiken takken en we zijn bekend met het concept, nu gaan we een deel zien dat essentieel is voor het gebruik van deze functie van: Git en is om een ​​naam te geven aan onze tak.
Tak naamDoor de naam is dat we zullen weten waar we op dit moment staan, deze naam is totaal willekeurig, dat wil zeggen dat elke gebruiker van Git je kunt je naam noemen takken zoals u wenst binnen uw project. Gebruikelijk Git Maak een tak genaamd meester Standaard en dit is over het algemeen degene die de stabiele en bugvrije versie van het project bevat, maar we kunnen het hernoemen of zelfs verwijderen als we daar zin in hebben, hoewel het raadzaam is om dit niet te doen.
Omdat we zoekwildcards kunnen gebruiken, kunnen we onze takken hiërarchisch bijv. Imp_Bug / 89 of Impl_Bug / 23. Dit stelt ons in staat om ze te lokaliseren en te ordenen met thema's. Laten we eens kijken hoe we het uitgelegde naar onze testrepository brengen:
In dit geval hebben we een filiaalmeester en we hebben er meerdere gemaakt takken die zijn voor het oplossen van bugs, als we het commando uitvoeren git branch in de console Git in de map van ons project zullen we een lijst krijgen met alle bestaande vestigingenLaten we eens kijken hoe het eruit ziet als we het uitvoeren:

We zien dan de lijst van al onze takken en in een andere kleur zien we de tak waarin we ons op dat juiste moment bevinden. Maar wat als we er veel hebben? takken en we hoeven alleen de te filteren bug resolutie takkenWelnu, dat is waar het zoeken met wildcards in het spel komt. Als we bijvoorbeeld op deze manier willen zoeken, moeten we een opdracht uitvoeren die lijkt op de volgende:

git show-branch impl_bug / *

Laten we eens kijken hoe dit eruit ziet op onze console:

We kunnen dan merken dat alle takken en aan de ene kant hebben we de opmerking van de laatste verbinden dat werd in hen gedaan.
Omdat de filiaal naamgeving Het is iets totaal willekeurigs en naar de mening van de gebruiker is er vaak verwarring binnen een team, daarom kunnen we enkele aanbevelingen en best practices volgen, op deze manier zullen we betere gebruikers van de tool zijn:

• Hoewel we het /-teken in de naam van onze branches kunnen gebruiken, kan dit niet het laatste teken van een naam zijn.
• We kunnen geen punt plaatsen (.) na een schuine streep (/).
• We kunnen geen twee punten op een rij plaatsen (… ) binnen een naam.
• We mogen geen speciale tekens gebruiken (~ : ? * [ ) aangezien deze karakters een betekenis hebben binnen de syntax van Git en ze kunnen gevoelig zijn voor fouten.
• We mogen ook geen spaties of controletekens hebben ASCII.

Als we deze richtlijnen volgen, zullen we het juiste gebruik binnen onze repository handhaven, en de andere teamleden zullen ons bedanken dat we het leven voor hen gemakkelijker hebben gemaakt.
Als we een takken lijst en we zijn in een tak maar we willen naar een andere gaan, we hoeven alleen de volgende opdracht te gebruiken:

git checkout branch-naam

Hiermee veranderen we tak onmiddellijk, waardoor er probleemloos aan verschillende onderdelen van het project kan worden gewerkt. Laten we eens kijken hoe we kunnen van tak wisselen binnen onze testrepository:

Zoals we hebben gemerkt, is het iets heel eenvoudigs, maar als we een wijziging aanbrengen binnen deze branche en we maken het niet verbinden wanneer we proberen over te schakelen naar een andere, krijgen we een foutmelding en Git Het vertelt ons dat we iets moeten doen, want als dat niet het geval is, kunnen de wijzigingen verloren gaan:

Wanneer dit probleem zich voordoet, moeten we een verbinden en dan door naar de volgende tak we zullen de inhoud van de ander zien tak.
Om een ​​nieuwe branch aan te maken zullen we doorgaan met het gebruik van het commando uitchecken, maar in dit geval moeten we de . toevoegen -b optie, hiermee maken we een kopie van de huidige branch en genereren we een geheel nieuwe. Laten we eens kijken hoe het eruit ziet op onze console:

We merken hoe eens de nieuwe tak gemaakt direct Git brengt ons naar hem toe en we kunnen direct aan de slag.
Hoewel het niet erg gebruikelijk is, zijn er gevallen waarin we willen een tak verwijderen uit onze repository en Git staat ons toe om dit te doen, alleen kunnen we de branch waarin we ons momenteel bevinden niet verwijderen om inconsistenties met de tool te voorkomen. Om deze bewerking uit te voeren, is het net zo eenvoudig als het toepassen van de volgende opdracht:

git branch -d branch-naam

BeperkingenEr zijn echter enkele beperkingen, we kunnen bijvoorbeeld geen tak wat is er mis mee begaat dat hij tak van waar we proberen te wissen heeft het niet, met het Git helpt het verlies van informatie te voorkomen, als we een tak van deze kenmerken willen verwijderen, moeten we dat doen samenvoegen in onze tak of ga naar een die die wel heeft begaat.
Laten we eens kijken hoe de uitvoering van deze opdracht eruitziet in de console:

Aan het einde van de uitvoering zien we hoe Git bevestigt de eliminatie van de overeenkomstige tak.
Er zijn momenten dat we dezelfde regel hebben aangeraakt in een bestand in twee verschillende takken, dit op het moment van doen samenvoegen het zal een conflict voor ons veroorzaken. Git Het helpt ons door een onderscheid te maken tussen het conflict in het bestand, dus bij het oplossen ervan moeten we een nieuwe verbinden en een nieuwe samenvoegen. In het betreffende bestand wordt de differentiatie als volgt weergegeven:

 elke regel <<<<<< >>>>>> dev: NewChange 

Als we het conflict willen oplossen, moeten we de inhoud van Git, dat wil zeggen, de regels met <<<<< Y >>>>, dus laten we de verandering die we willen of verenigen alles, door dit al te doen Git zal ons niet langer de fout presenteren en we zullen in staat zijn om de samenvoegen gebruikelijk.
BelangrijkEen van de dingen die belangrijk is om te doen, is het genereren van a gedeelde nomenclatuur, dat wil zeggen een structuur van namen vaststellen waaronder de takken afhankelijk van zijn functie binnen het project, zullen we op die manier veel meer orde hebben, natuurlijk moet deze nomenclatuur de best practices volgen die aan het begin van de tutorial worden genoemd.
Hiermee voltooien we deze tutorial, we zullen in staat zijn om veel meer uit onze repository te halen in Git en daarmee ons team op een geweldige manier te managen. We moeten de basis al hebben gedekt voor het beheer van takken in Git, hiermee kunnen we onze wijzigingen adequaat administreren zodat we conflicten tot een minimum kunnen beperken, zeker wanneer we in teams van twee of meer personen werken.Vond je deze Tutorial leuk en heb je eraan geholpen?Je kunt de auteur belonen door op deze knop te drukken om hem een ​​positief punt te geven