Sådan opsamles dine lokale filer med Git del 1

Grener og arbejdsgang

Git er et vigtigt værktøj for enhver udvikler, det holder din kodehistorie i skak og hjælper med at forstå, hvad der blev gjort i går uden at narre ud.

At arbejde med et team kræver lidt mere end “git add” og “git commit”, så lad os begynde at udforske den smukke verden af ​​Git.

At få det grundlæggende er ikke så svært, og når du først kommer ind i det, bliver det endnu lettere.

Denne artikels rækkevidde

Når du arbejder med et team, bør brug af Git ikke tage halvdelen af ​​din kodningstid, så lad os se ned nogle grundlæggende regler for Git og Github-etikette, så du kan bruge din tid på kodning i stedet for at klone repoen endnu en gang.

Del 1 fokuserer på, hvordan du skal styre din arbejdsgang med Git for at undgå de mest almindelige problemer.

Værktøj

Du har ikke brug for smarte værktøjer eller kommandoer for at bruge Git effektivt, for denne artikel og dem, der skal følges, skal jeg bare bruge Git selv og min valg af kodeditor (med Git-integration).

Git-klient Dette er alt det Git, vi har brug for, bare standardklienten.

Visual Studio Code eller enhver anden editor med Git-integration, det vil gøre dit liv så meget lettere.

Grundlæggende

Lad os først starte med det grundlæggende i Github-etikette (vi kan tilpasse og bygge videre på disse, de er ikke sat i sten, men et godt udgangspunkt).

master branch du vil aldrig røre ved det, dette er produktion og bør opdateres sjældent, når alt testes og fungerer.

udviklingsgren dette er vores udviklingsgren, du koder ikke her, du sender pull-anmodninger her for at blive kontrolleret af andre medlemmer af dit team og fusioneret. Hvis du parrer meget, og dev-teamet er i orden med det, kan du springe den markerede del ud og flette selv anmodningen om pull, men alligevel skal du ikke skubbe til kode her.

Så hvor skal jeg kode, hvis jeg ikke kan gøre noget! Hold din kanon cowboy, lad os komme ind i det næste.

Tyg den cigar, Clint.

Hvad du skal gøre, når du vil arbejde på noget

$ git klon git@github.com: Kornil / simple-react-app.git

Dette er begyndelsen, du gør det en gang og aldrig igen.

Herefter skal vi arbejde på grene. Som standard vil du være på mastergrenen. KOM ud derfra.

Udvikling af $ git checkout

Dette er bedre er det ikke? Du er nu i udviklingsgrenen, dette er den gren, du altid skal henvise til, hun er dit livs kærlighed, og du vil behandle hende med den respekt, hun fortjener.

Hvordan?

$ git check -b myNewBranch

Dette vil skabe en ny lokal filial kaldet myNewBranch og skifte til den, den er baseret på udviklingsgrenen i dette tilfælde, siden vi var der.

Når du kører "git branch", vil du se, at du faktisk er inde i denne nye gren. Dette er kun på din maskine, sig ”Hej!” Til din nye arbejdsgren.

For de visuelle elever.

Navngivne grene

At navngive grene er et vigtigt aspekt af kodning med andre devs og endda for dit fremtidige selv, lad os se på, hvordan vi kan tilnærme os dette.

myNewBranch forklarer ikke noget, og det løser ikke vores problemer, vi har brug for en navnekonvention:

"bug / fast-all-caps"
"-Funktion / gigant-ænder-modal"
"refactor / add-prop-typer"
"Stil / alt-er-sort"

Type / kort beskrivelse

typer

Vi definerer 4 grundlæggende filialtyper: bug, funktion, refactor og stil: henholdsvis til bugfixes, nye funktioner, code refactoring og design / css-ting, når typen kommer navnet, skal den specificeres oven på grenstypen.

$ git check -b stil / pink-knapper

Dette fortæller dig og dine venner alt hvad du skal kode i denne nye gren.

F-! Jeg glemte at oprette en ny gren, inden jeg begyndte at rodde rundt, og jeg er stadig i udvikling!

Bare rolig ikke Leo, vi kan løse dette. Der er 2 måder, vi kan bruge til at komme os efter denne katastrofe:

For det første, hvis du ikke har begået noget:

$ git stash

Gemmer alle dine ændringer (ikke forpligtet eller iscenesættes) et eller andet sted og fjerner dem fra din gren.

Nu er din udviklingsgren ren, så bare kør

$ git check -b funktion / gummi-duck-cta
$ git stash pop

Du opretter en ny lokal filial og indsætter her alle dine ændringer. Husk, at stash er som kopipapir, enormt nyttigt, men samtidig definitivt, hvis du "git stash" endnu en gang, kan du sige farvel til din første stash. HVIL I FRED.

Anden måde, hvis du allerede har foretaget dine ændringer:

Udvikling af $ git push-oprindelse: fix / your-smart-fix

Gem din kode i den nyligt materialiserede fix / din-smart-fix gren i dit Github-projekt (forudsat at du arbejdede med udviklingsgrenen).

Slet nu udviklingsgrenen og få den tilbage igen så ren som den burde være.

$ git checkout master
$ git branch -D udvikling
$ git hent
Udvikling af $ git checkout // valgfrit, bare for at se, at det er rent
$ git checkout fix / din-smart-fix

Lad os gennemgå dette hurtigt:

Først skal du skifte til mastergren (din sikre gren), derefter sletter vi udviklingsgrenen, henter hver gren fra Github (behøver ikke bekymre dig, at du ikke vil se dem med "git branch") og skifte til udvikling igen. Nu kan du køre “git status” for at kontrollere, at udviklingen er ren, og fra det kan du gå tilbage til din arbejdsgren, let nok ikke?

Brug af Visual Studio til at se smart ~ ish ud

Visual Studio er mere end en redaktør, det er som en banan for en abe, du skal ikke leve uden den. Lad os se, hvad det kan gøre for os.

Keder du dig ved at bruge "git add."? Vil du kun begå 3 filer, fordi alt resten er et rod, og du ved, at du bliver slået, hvis du prøver at forgifte Github-depotet med den snavs? Her kommer VSCode!

Se på dette rod!

Jeg gik ind i et kodningsraseri og modificerede for mange filer uden at forpligte sig en gang, men jeg vil ikke, at mine kolleger skal lide under mig, jeg vil bare opdele min kode i flere forpligtelser, så det bliver lettere at læse.

Men først og fremmest, hvad er disse breve til højre?

(M) ← filen blev ændret efter den sidste forpligtelse.

(D) ← filen blev slettet efter den sidste forpligtelse.

(U) ← dette er en splinterny fil.

Hjælper dette? Lidt, men alligevel, lad os komme på arbejde! Når jeg holder musepekeren på filen, vil jeg tilføje to ikoner til, lad os se, hvad de gør.

Den første er en pil, den vender tilbage til alle dine ændringer til det sidste engagement (min favoritknap!).

Det andet er et plussymbol, ved at klikke på det er som at køre “git add .gitignore”, det tilføjer vores filer til det næste engagement, vi kan bruge denne praktiske funktion til kun at tilføje de filer, vi ønsker til dette engagement, og holde resten der.

Efter at have klikket på plus-ikonet ser vi dette.

Nu er der 2 forskellige rækker, den sædvanlige kaldes ændringer og en ny til den fil, vi tilføjede, kaldte iscenesatte ændringer. Iscenesat betyder fil, der vil blive begået med det næste “git commit”, men som du kan se, har vi et nyt ikon, et minustegn! Dette kan også være praktisk, da det ustrapper vores ændringer og sætter filen tilbage til ændringer, hvor vi kan beslutte, om vi bare spiller scene / unstage, eller hvis vi vil gendanne det forrige engagement.

Konklusion eller TLDR

Lav nye grene, referer til udvikling som basen for dine filialer, begå ofte, brug klare beskeder, fremsæt anmodninger mod udvikling, beder dit team om at kontrollere din kode og derefter flette til udvikling.

Du kan finde del 2 af denne serie her og del 3 her.