Tips, du skal vide, før du vælger mellem GitHub Flow eller Git Flow

28. oktober 2019 2,982 læsninger

Damilola Ale Hacker Noon profilbillede

@CodenlynDamilola Ale

LinkedIn social ikonfacebook social ikonTwitter social ikongithub social ikon

Versionskontrol er blevet en vigtig del af softwareudviklingsprocessen. Versionsstyring hjælper med at registrere ændringer til et projekt over tid, så du kan huske specifikke versioner senere. Jeg vil tale om GitHub.

Da jeg startede som udvikler, begyndte jeg at bruge GitHub, fordi alle sagde, at det er nødvendigt for udviklere at have deres kode online. Med det i tankerne så jeg det som et sted at gemme alle mine projekter, så hvis mit system går ned, ville jeg kunne hente dem tilbage.

Sjovt ikke sandt?

Senere indså jeg, at GitHub var mere end blot det, det er et sted, hvor jeg kan se alle de fremskridt, jeg har gjort på hvert trin i opbygningen af mit projekt eller software. Det er også et sted, hvor alle i hele verden kan bidrage til projekter med forskellige idéer.

Omkring midten af året, da jeg startede hos Microverse, blev jeg introduceret til GitHub Flow. GitHub Flow opfordrer dig til at oprette feature-branches for hver funktion i din software. Når du mener, at din software eller dit projekt er klar til at blive vist eller brugt, opretter du en pull request og fusionerer til mastergrenen.

Cool ikke?

clone the project

til dit lokale repository.

cd

ind i repository

kontroller den gren, du er i øjeblikket på

Opret en ny

feature branch

Begynd at arbejde på din funktion, og når du er færdig,

add

,

commit

og

push

til funktionsgrenen

Gå til dit fjernrepositorium på GitHub og opret en pull request og sammenlæg, når du mener, at funktionen er færdig

På denne måde får du mulighed for at se alle de funktioner, du har oprettet, og hvad du har tilføjet i hver fase. Efterhånden som jeg kom videre, indså jeg, at mastergrenen primært var til produktion, og i det øjeblik du fletter en pull request, siger du, at den funktion er klar til at blive brugt eller set af alle.

Det var da jeg kom til den viden, at GitHub flow fungerer perfekt til små projekter, men hvad nu hvis jeg har et projekt med mere end én vigtig funktion, og jeg bruger GitHub flow, så siger jeg indirekte, at alle funktioner, der er flettet til mastergrenen, er klar til produktion, men hvis vi tænker over det, er de det så?

Fremlæggelse af én funktion for et projekt med mange funktioner giver ikke mening, og det er her Git Flow kommer ind i billedet. Det minder meget om GitHub flow, men introducerer en bedre måde at arbejde med versionskontrol på.

I Git Flow opretter vi en udviklingsgren og gør derefter udviklingsgrenen til standardgren, indtil vi er klar til produktion. På denne måde oprettes alle funktionsgrene fra udviklingsgrenen og flettes ind i udviklingsgrenen, når de er færdige.

Det giver mening, ikke? Nu får jeg kun mulighed for at fusionere til hovedgrenen, når jeg mener, at min software er klar til produktion med alle funktioner tilføjet.

Når du har klonet dit repository, opretter du en

development

gren

Kontroller, hvilken gren du arbejder på i øjeblikket

Forsøg at tilføje en fil, måske en HTML-fil, så du kan opdatere dit fjernrepository med udviklingsgrenen.

Gå til dit fjernrepositorium på GitHub , gå til indstillinger, klik på branches og gør development til standardgren

Nu, kan du oprette feature-branches fra

development

-grenen, oprette en pull request fra den og flette til

development

-grenen.

Når alle dine funktioner er klar, følger du de samme trin ovenfor, gør master til standard igen, opret en pull request fra udvikling til master og flette til produktion.

Jeg ved godt, at det har været en lang læsning, men jeg regner med, at vi nu burde vide, hvornår vi skal bruge GitHub flow eller Git Flow.

Tak for at du læste.

Tags

Tilmeld dig Hacker Noon

Opret din gratis konto for at låse op for din brugerdefinerede læseoplevelse.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.