Administrasjon og administrasjon av filialer i GIT

EN gren i Git det er en gren av vårt depot, det er en måte å generere en alternativ vei til hovedbanen. Dette gjør at vi kan utforske nye løsninger uten å måtte endre basisen for programmet eller applikasjonen vi kjører.
Imidlertid er begrepet gren Det er ikke veldig klart når vi begynner å bruke dette verktøyet som styrer versjonene av prosjektene våre. Vanligvis i andre versjonskontrollsystemer blir konsekvensene av et prosjekt med dette konseptet ikke tatt.
Mange vil allerede bruke Git og de har ikke vært mer oppmerksom på grener, og på en måte er det forståelig siden når du håndterer en singel gren og hvis utviklingen blir utført av en enkelt person, bør det ikke være noen ulempe.
Men hva om denne personen vil teste noen eksperimentelle funksjoner som kan få prosjektet til å mislykkes eller bare påvirke stabiliteten til prosjektet, vil noen si at en gaffel av prosjektet og fortsett å eksperimentere, og hvis forbedringen er vellykket, så tenk på å inkludere det som ble gjort i gaffelen i hovedprosjektet. Dette er virkelig en litt lang og unødvendig jobb.
I ovennevnte tilfelle er det bare å lage en ny gren i det aktuelle prosjektet kan vi gjøre alle ønskede endringer og eksperimenter og til slutt ganske enkelt ved å gjøre en slå sammen eller fusjon med gren initial eller main vil vi allerede ha sluttet seg til alle våre endringer.
En annen sakEt annet tilfelle er når vi har et arbeidsteam der to personer som jobber med den samme koden kan generere konflikter, det er her Git får frem sin makt. Vi kan lage en struktur av tre grener for eksempel a gren for hver utvikler og a forening gren. På denne måten kan hver utvikler ta sine endringer, og når de føler at de kan bidra med dem til prosjektet, sender de dem til gren av forening og dermed kan den andre personen eller de andre medlemmene i teamet få tilgang til dem.
Vi forstår allerede årsakene som får oss til å bruke grener og vi er kjent med konseptet, nå skal vi se en del som er avgjørende for bruk av denne funksjonen til Git og er å sette et navn på vår gren.
FilialnavnGjennom navnet er at vi skal vite hvor vi står for øyeblikket, dette navnet er totalt vilkårlig, det vil si hver bruker av Git du kan navngi din grener som du ønsker i ditt prosjekt. Som oftest Git lage en gren kalt herre Som standard er dette vanligvis den som inneholder den stabile og feilfrie versjonen av prosjektet, men vi kan gi det nytt navn eller til og med slette det hvis vi har lyst til det, selv om det er tilrådelig å ikke gjøre det.
Fordi vi kan bruke jokertegn, kan vi navngi vårt grener hierarkisk, for eksempel Imp_Bug / 89 eller Impl_Bug / 23. Dette lar oss finne og organisere dem med temaer. La oss se hvordan vi tar det forklarte til vårt testlager:
I dette tilfellet har vi en filialmester og vi har laget flere grener som er for å løse feil, hvis vi utfører kommandoen git gren i konsollen Git inne i mappen til prosjektet vårt får vi en liste med alle eksisterende grenerLa oss se hvordan det ser ut når vi kjører det:

Vi ser da listen over alle våre grener og i en annen farge ser vi grenen der vi er i det rette øyeblikket. Men hva om vi har mye grener og vi trenger bare å filtrere feiloppløsningsgrenerVel, det er her jokertegnet søker inn. For eksempel, hvis vi vil søke på denne måten, må vi gjøre en kommando som ligner på følgende:

git show-branch impl_bug / *

La oss se hvordan dette ser ut på konsollen vår:

Vi kan da legge merke til at alle grener og på den ene siden har vi kommentaren fra den siste begå det ble gjort i dem.
Fordi det navngivning av grener Det er noe helt vilkårlig og etter brukerens mening er det mange ganger forvirring i et team, derfor kan vi følge noen anbefalinger og beste praksis, på denne måten blir vi bedre brukere i verktøyet:

• Selv om vi kan bruke symbolet / i navnet på grenene våre, kan dette ikke være det endelige tegnet i et navn.
• Vi kan ikke sette et poeng (.) etter en skråstrek (/).
• Vi kan ikke plassere to poeng på rad (… ) i et navn.
• Vi må ikke bruke spesialtegn (~ : ? * [ ) siden disse tegnene har en mening innenfor syntaksen til Git og de kan være utsatt for feil.
• Vi skal heller ikke ha tomme mellomrom eller kontrolltegn ASCII.

Hvis vi følger disse retningslinjene, vil vi opprettholde riktig bruk i vårt depot, så vel som de andre teammedlemmene vil takke oss for at de gjorde livet lettere for dem.
Hvis vi har en grener liste og vi er i en gren men vi vil gå til en annen, vi må bare bruke følgende kommando:

git checkout filialnavn

Med dette vil vi endre oss gren umiddelbart, og dermed kunne jobbe med ulike deler av prosjektet uten problemer. La oss se hvordan vi kan bytte gren i vårt testlager:

Som vi la merke til er det noe ganske enkelt, men hvis vi gjør en endring innenfor denne grenen og vi ikke gjør det begå når vi prøver å bytte til en annen, får vi en feilmelding og Git Det forteller oss at vi må gjøre noe, for hvis ikke kan endringene gå tapt:

Når dette problemet oppstår må vi gjøre en begå og deretter gå videre til neste gren vi vil se innholdet i den andre gren.
For å opprette en ny gren fortsetter vi å bruke kommandoen Sjekk utmen i dette tilfellet må vi legge til -b alternativ, med dette vil vi lage en kopi av den nåværende grenen og generere en helt ny. La oss se hvordan det ser ut på konsollen vår:

Vi merker hvordan en gang opprettet den nye grenen med en gang Git tar oss til ham, og vi kan begynne å jobbe direkte.
Selv om det ikke er veldig vanlig, er det tilfeller vi ønsker det slette en gren fra vårt depot og Git tillater oss å gjøre det, bare vi kan ikke slette grenen vi er i for øyeblikket, for å unngå inkonsekvenser med verktøyet. For å utføre denne operasjonen er det like enkelt som å bruke følgende kommando:

git branch -d branch -name

BegrensningerDet er imidlertid noen begrensninger, for eksempel kan vi ikke slette a gren hva er galt med det forplikter seg at han gren fra der vi prøver å slette den ikke har, med den Git bidrar til å unngå tap av informasjon, hvis vi vil slette en gren av disse egenskapene, må vi gjøre det slå sammen i vår gren eller gå til en som har dem forplikter seg.
La oss se hvordan utførelsen av denne kommandoen ser ut i konsollen:

På slutten av utførelsen ser vi hvordan Git bekrefter eliminering av den tilsvarende grenen.
Det er tider når vi har berørt den samme linjen i en fil i to forskjellige grener, dette på tidspunktet for å gjøre slå sammen det kommer til å skape en konflikt for oss. Git Det hjelper oss ved å etablere en differensiering av konflikten i filen, så når vi løser den må vi lage en ny begå og en ny slå sammen. Differensieringen vises som følger i den aktuelle filen:

 hvilken som helst linje <<<<<< >>>>>> dev: NewChange 

Hvis vi vil løse konflikten, må vi slette innholdet i Git, det vil si linjene med <<<<< Y >>>>, så vi forlater endringen vi ønsker eller forener alt ved å gjøre dette allerede Git vil ikke lenger presentere oss feilen, og vi kan gjøre det slå sammen som oftest.
ViktigEn av tingene som er viktig å gjøre er å generere en delt nomenklatur, det vil si etablere en navnestruktur som grener avhengig av funksjonen i prosjektet, vil vi på den måten ha mye mer orden, selvfølgelig må denne nomenklaturen følge de beste fremgangsmåtene nevnt i begynnelsen av opplæringen.
Når vi er ferdig med denne opplæringen, vil vi kunne få mye mer ut av depotet vårt Git og med det administrere teamet vårt på en flott måte. Vi må allerede ha grunnlaget dekket for forvaltningen av grener i GitMed dette kan vi gjøre en tilstrekkelig administrasjon av endringene våre slik at vi kan holde konflikter på et minimum, spesielt når vi jobber i team på to eller flere personer.Likte og hjalp du denne opplæringen?Du kan belønne forfatteren ved å trykke på denne knappen for å gi ham et positivt poeng