Hantering och administration av filialer i GIT

A gren i Git det är en gren av vårt arkiv, det är ett sätt att generera en alternativ väg till huvudvägen. Detta gör att vi kan utforska nya lösningar utan att behöva ändra basen för programmet eller applikationen som vi kör.
Men begreppet gren Det är inte särskilt tydligt när vi börjar använda det här verktyget som styr versionerna av våra projekt. Vanligtvis i andra versionskontrollsystem tas konsekvenserna av ett projekt med detta koncept inte.
Många kommer redan att använda Git och de har inte ägnat mer uppmärksamhet åt grenar, och på ett sätt är det förståeligt sedan hanteringen av en singel gren och om utvecklingen utförs av en enda person bör det inte finnas några besvär.
Men vad händer om den här personen vill testa några experimentella funktioner som kan få sitt projekt att misslyckas eller helt enkelt påverka projektets stabilitet, kommer vissa att säga att en gaffel av projektet och fortsätt experimentera och om förbättringen är framgångsrik, fundera sedan på att införliva det som gjordes i gaffeln i huvudprojektet. Det här är verkligen ett långt och onödigt jobb.
I ovanstående fall helt enkelt skapa en ny gren inom det aktuella projektet kan vi göra alla önskade förändringar och experiment och i slutet helt enkelt genom att göra en sammanfoga eller fusion med gren initial eller main kommer vi redan att ha anslutit oss till alla våra ändringar.
Ett annat fallEtt annat fall är när vi har ett arbetslag där två personer som arbetar med samma kod kan generera konflikter, det är här Git tar fram sin kraft. Vi kan skapa en struktur av tre grenar till exempel a gren för varje utvecklare och a föreningsgren. På detta sätt kan varje utvecklare ta sina ändringar och när de känner att de kan bidra med dem till projektet skickar de dem till gren om förening och därmed kan den andra personen eller de andra medlemmarna i teamet komma åt dem.
Vi förstår redan orsakerna som får oss att använda grenar och vi är bekanta med konceptet, nu ska vi se en del som är avgörande för användningen av denna funktion av Git och är att sätta ett namn på vår gren.
FilialnamnGenom namnet är att vi kommer att veta var vi står för tillfället, detta namn är totalt godtyckligt, det vill säga varje användare av Git du kan namnge din grenar som du vill inom ditt projekt. Vanligtvis Git skapa en gren kallad bemästra Som standard är det i allmänhet den som innehåller den stabila och buggfria versionen av projektet, men vi kan byta namn på det eller till och med radera det om vi känner för det, även om det är lämpligt att inte göra det.
Eftersom vi kan använda jokertecken kan vi namnge våra grenar hierarkiskt, till exempel Imp_Bug / 89 eller Impl_Bug / 23. Detta gör att vi kan hitta och organisera dem med teman. Låt oss se hur vi tar det förklarade till vårt testförråd:
I det här fallet har vi en filialmästare och vi har skapat flera grenar som är för att lösa buggar, om vi kör kommandot git gren i konsolen Git i mappen för vårt projekt kommer vi att få en lista med alla befintliga filialerLåt oss se hur det ser ut när vi kör det:

Vi ser sedan listan över alla våra grenar och i en annan färg ser vi den gren där vi befinner oss i det rätta ögonblicket. Men tänk om vi har mycket grenar och vi behöver bara filtrera bugupplösning grenarTja, det är där jokertecken -sökningen spelar in. Om vi ​​till exempel vill söka på det här sättet måste vi göra ett kommando som liknar följande:

git show-branch impl_bug / *

Låt oss se hur det ser ut på vår konsol:

Vi kan då märka att alla grenar och på ena sidan har vi den sista kommentaren begå som gjordes i dem.
Eftersom det filialnamn Det är något helt godtyckligt och enligt användarens uppfattning är det många gånger förvirring inom ett team, det är därför vi kan följa några rekommendationer och bästa praxis, på så sätt blir vi bättre användare inom verktyget:

• Även om vi kan använda / -symbolen i namnet på våra grenar, kan detta inte vara det sista tecknet i ett namn.
• Vi kan inte sätta en punkt (.) efter en snedstreck (/).
• Vi kan inte placera två poäng i rad (… ) inom ett namn.
• Vi får inte använda specialtecken (~ : ? * [ ) eftersom dessa tecken har en betydelse inom syntaxen för Git och de kan vara benägna att göra misstag.
• Vi ska inte heller ha tomma mellanslag eller kontrolltecken ASCII.

Om vi ​​följer dessa riktlinjer kommer vi att upprätthålla korrekt användning i vårt förvar, liksom de andra teammedlemmarna kommer att tacka oss för att de har gjort livet enklare för dem.
Om vi ​​har en grenar lista och vi är i en gren men vi vill gå till en annan, vi måste bara använda följande kommando:

git checkout filialnamn

Med detta kommer vi att förändras gren omedelbart och därmed kunna arbeta på olika delar av projektet utan problem. Låt oss se hur vi kan byta gren i vårt testförråd:

Som vi märkte är det något ganska enkelt, men om vi gör en förändring inom denna gren och vi inte gör det begå när vi försöker byta till en annan får vi ett fel och Git Det säger oss att vi måste göra något, för om inte kan ändringarna gå förlorade:

När detta problem uppstår måste vi göra en begå och sedan gå vidare till nästa gren vi kommer att se innehållet i den andra gren.
För att skapa en ny gren kommer vi att fortsätta använda kommandot kolla uppmen i det här fallet måste vi lägga till -b alternativ, med detta kommer vi att göra en kopia av den aktuella grenen och generera en helt ny. Låt oss se hur det ser ut på vår konsol:

Vi märker hur en gång skapade den nya grenen omedelbart Git tar oss till honom och vi kan börja arbeta direkt.
Även om det inte är särskilt vanligt finns det fall där vi önskar ta bort en gren från vårt förvar och Git tillåter oss att göra det, bara vi kan inte radera grenen där vi befinner oss för tillfället, för att undvika inkonsekvenser med verktyget. För att utföra denna operation är det lika enkelt som att tillämpa följande kommando:

git branch -d branch -name

BegränsningarDet finns dock vissa begränsningar, till exempel kan vi inte ta bort a gren Vad är fel med det begår att han gren från där vi försöker radera den inte har, med den Git hjälper till att undvika förlust av information, om vi vill ta bort en gren av dessa egenskaper måste vi göra det sammanfoga i vår gren eller gå till en som har sådana begår.
Låt oss se hur körningen av detta kommando ser ut i konsolen:

I slutet av dess utförande ser vi hur Git bekräftar eliminering av motsvarande gren.
Det finns tillfällen då vi har rört samma rad i en fil i två olika grenar, detta vid tidpunkten för att göra sammanfoga det kommer att generera en konflikt för oss. Git Det hjälper oss genom att etablera en differentiering av konflikten i filen, så när vi löser den måste vi göra en ny begå och en ny sammanfoga. Differentieringen visas enligt följande i filen i fråga:

 valfri rad <<<<<< >>>>>> dev: NewChange 

Om vi ​​vill lösa konflikten måste vi ta bort innehållet i Git, det vill säga linjerna med <<<<< Y >>>>, så vi lämnar den förändring vi vill eller förenar allt, genom att göra detta redan Git kommer inte längre att presentera felet för oss och vi kommer att kunna göra det sammanfoga vanligtvis.
ViktigEn av de saker som är viktiga att göra är att generera en delad nomenklatur, det vill säga upprätta en namnstruktur under vilken grenar beroende på dess funktion inom projektet, så kommer vi att få mycket mer ordning, naturligtvis måste denna nomenklatur följa de bästa metoder som nämns i början av handledningen.
Med detta avslutar vi denna handledning, vi kommer att kunna få ut mycket mer av vårt förvar i Git och med det hantera vårt team på ett bra sätt. Vi måste redan ha basen täckt för hanteringen av grenar i Git, med detta kan vi göra en adekvat administration av våra förändringar så att vi kan hålla konflikter till ett minimum, särskilt när vi arbetar i team om två eller fler personer.Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng