@CodenlynDamilola Ale
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
Opret din gratis konto for at låse op for din brugerdefinerede læseoplevelse.