Hvis du skriver software til at leve i 2018, så kan jeg med tillid sige, at du kender Git. værktøj oprettet af Linus Torvalds er blevet synonymt med versionskontrol. Og uden tvivl er en af Gits bedste funktioner, hvordan det fjerner smerten ved forgrening og fletning. Der er flere måder, du kan oprette en filial i Git på. I dette indlæg vil vi “gennemgå nogle af dem. Derefter slutter vi med en lille refleksion over Gits forgreningsmodel og forgrening generelt.

Oprettelse af en gren fra mester

Du opretter grene i Git, ikke overraskende, ved hjælp af filialkommandoen. Som mange andre Git-kommandoer er “gren” meget kraftfuld og fleksibel. Udover oprettelse af grene kan den også bruges til at liste og slette dem, og du kan yderligere tilpasse kommandoen ved at anvende en bred liste over parametre. Vi begynder med den første måde at oprette en filial på. Lad os sige, at du vil oprette en ny mappe, der hedder “min-app”, indtaste den og starte et nyt Git-arkiv. Sådan gør du det nøjagtigt:

mkdir my-appcd my-appgit init

Nu har du et nyt, tomt Git-arkiv. Men tomme arkiver er kedelige. Så hvad med at oprette en ny markdown-fil med “Hello World!” skrevet i den?

echo Hello World! > file.md

Hvis du kører “git status”, skal du se en meddelelse om, at din fil ikke er sporet:

Usporede filer er dog også ukølede, så lad os spore det:

git add file.md

Og endelig, lad os skabe vores første forpligtelse:

git commit -m "First commit"

Vi har nu et arkiv med en gren, der har nøjagtigt en forpligtelse. Det lyder måske ikke som mest spændende ting i verden (fordi det virkelig ikke er det), men det er bestemt mindre kedeligt end at have en repo uden nogen forpligtelser overhovedet, ikke? Lad os sige, at uanset årsag skal du ændre filen “s indhold. Men du behøver ikke har lyst til at gøre det. Hvad hvis noget går galt, og du på en eller anden måde ødelægger det smukke, uberørte indhold i din fil? (Ja, jeg ved, det er bare en dum fil med “Hello World!” I den, men brug de vidunderlige kræfter i din fantasi og tænk på filen som en proxy for et langt mere komplekst projekt.) Løsningen på dette dilemma. opretter naturligvis en ny gren:

git branch exp

Så nu har vi en ny gren kaldet “exp” til eksperimentering Nogle mennesker, der er vant til at bruge forskellige versioneringssystemer, især centraliserede, kan sige, at filialerne har det samme “indhold.” Dette er dog ikke helt nøjagtigt, når man taler om Git. Tænk på grene som referencer, der peger på en given forpligtelse.

Oprettelse af en gren fra et engagement

Antag, at vi uanset årsag opgiver vores eksperiment uden at tilføje en eneste forpligte sig til den nye filial. Lad os gå tilbage til master og slette exp-grenen:

git checkout mastergit branch -d exp

Nu hvor vi er tilbage til en enkelt gren, lad os tilføje nogle forpligtelser til det for at simulere det arbejde, der udføres:

Forestil dig, at når du har gjort alt dette “arbejde”, lærer du, at du uanset årsag skal gå tilbage i tiden til når der var kun to linjer i filen og skabte nye ændringer fra da af. Men på samme tid skal du bevare de fremskridt, du allerede har gjort. Med andre ord, du vil oprette en gren fra en tidligere forpligtelse. Hvordan ville du gøre det ? I Git har hver forpligtelse en unik identifikator. Så du kan nemt se dette ved hjælp af kommandoen “git log”. For at oprette en ny gren baseret på en bestemt forpligtelse skal du blot sende dens hash som en parameter til grenkommandoen:

git branch new-branch 7e4decb

Som en ekstraordinær behøver du ikke engang hele hashen mest af tiden. Bare de første fem eller seks tegn gør det.

Oprettelse af en gren fra et tag

Hvis du er lidt mere erfaren med Git, skal du være fortrolig med begrebet tags. Du bruger tags til at indikere, at en given forpligtelse er vigtig eller speciel på en eller anden måde. F.eks. bruges tags generelt til at angive de faktiske versioner af et produkt. Hvis du har arbejdet i din applikation i et stykke tid og du mener, det er tid til at frigive version 1.0, hvad du typisk gør, er at bumpe versionsnumrene, hvor det er nødvendigt, begå disse ændringer og derefter tilføje et tag til det specifikke tidspunkt. For at oprette et tag kører du normalt noget som dette:

git tag -a v1.0 -m "First major version"

Parameteren “-a” angiver, at dette går at være et kommenteret tag. I modsætning til et let tag er dette et fuldt blæst Git-objekt, der indeholder stykker information, såsom kommissærens navn og e-mail, tidsstemplet og en besked. Nu har du et mærke, en indikation af, at dette særlige punkt i historien er specielt og har et navn. Pæn. Du kan fortsætte med at arbejde som normalt ved at oprette og foretage ændringer, der vil være en del af 1.1-versionen. Indtil en fejlrapport kommer ind. Nogle klienter, der blev opdateret til 1.0 version af produktet siger, at en importfunktion ikke fungerer efter hensigten. Nå, du kan teoretisk rette fejlen i mastergrenen og distribuere den. Men så modtager klienterne funktioner, der potentielt er uprøvede og ufuldstændige. Det “er nej -ingen. Så hvad laver du? Svaret: Du opretter en ny gren fra det tag, du har oprettet for at angive den største version. Du løser problemet der, bygger og implementerer. Og du bør sandsynligvis flette dette tilbage til master bagefter, så de næste udgivelser indeholder rettelsen Hvordan vil du gøre det? Let:

git branch <NAME-OF-THE-BRANCH> <TAG>

Mere specifikt ved hjælp af vores tidligere eksempel:

git branch fix-bug-123 v1.0

Derefter kan du tjekke din nye filial som normalt. Eller endnu bedre, du kan gøre det hele i et trin:

git checkout -b fix-bug-1234 v1.0

Oprettelse af en filial i løsrevet hovedtilstand

Har du nogensinde ønsket at gå tilbage i tiden? Med Git er dette muligt … i det mindste med hensyn til filerne i vores arkiv. Du kan til enhver tid tjekke en forpligtelse, hvis du kender dens hash:

git checkout <SHA1>

Efter at have kørt det, viser Git dig en nysgerrig besked:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Når du tjekker ud en forpligtelse, går du ind i en særlig tilstand c alled, som du kan se, “løsrevet HEAD”. Mens du kan begå ændringer i denne tilstand, hører disse forpligtelser ikke til nogen gren og bliver utilgængelige, så snart du tjekker en anden gren. Men hvad hvis du vil beholde disse forpligtelser? Svaret er overraskende at bruge kommandoen “checkout” igen for at oprette en ny gren:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

Og selvfølgelig ved du nu, at du kan skrive sidste to linjer som en enkelt kommando:

git checkout -b new-branch-to-keep-commits

Temmelig let, ikke?

Bare fordi du kan … Betyder det ikke, at du burde

Gits forgreningsmodel er en af dens salgsargumenter. Det gør, hvad der i andre kildekontrolsystemer er en smertefuld og endda langsom proces til en brise. Man kan sige at Git med succes har demokratiseret forgrening til masserne. Men der er en alvorlig fare. På grund af den billige forgrening i Git kan nogle udviklere falde i fælden med at arbejde med ekstremt langvarige grene eller anvende arbejdsgange eller forgreningsmodeller, der forsinker rist. Vi som industri har været der. Vi har gjort det. Det fungerer ikke. I stedet omfavne arbejdsgange, der anvender ekstremt kortvarige filialer. Du har en sikker sandkasse, hvor du kan kode uden frygt for at ødelægge ting eller spilde dine kolleger tid. Men spørger du, “Hvordan distribuerer jeg kode med delvist gennemførte funktioner?” I så fald er det med flag til undsætning. Git-grene er et kraftfuldt værktøj. Brug dem klogt og misbrug dem ikke. Og når de ikke er nok, skal du bruge kontinuerlig levering / kontinuerlig integration sammen med funktionsflag – herunder specialværktøjer til din rådighed – så dine applikationer kan komme til det næste niveau.