En nybörjares guide till Git

För dig som har hört om Git, inte riktigt förstår vad det är. Eller har du kanske skrivit några kommandon med Git, men inte riktigt förstått helhetsbilden ännu?
Då är det här guiden för dig.

Jag har också varit där 🙋🏻‍♀️ Och jag tänkte berätta lite om min (lite krokiga) väg till att förstå och tycka om Git. Jag vill även ge några konkreta tips och råd på vägen. Så vi går igenom det här steg för steg och tillsammans löser vi mysteriet med Git 🕵🏻‍♀️

Vad är Git då?

Grunden med Git

Git är versionshantering av kod. Det används för både små som stora kodprojekt av enskilda utvecklare eller team med flera utvecklare som arbetar på samma projekt.

Git är både gratis och open source vilket gör att det är många utvecklare över hela världen som valt det för versionshantering. Det är ett mjukvaruprogram som du antingen har lokalt på din dator redan eller som du laddar ner och installerar. Sedan skapar du ett nytt repo, eller kopierar ned ett befintligt repo lokalt på din dator.

Här jobbar du i olika versioner av samma mapp som innehåller ditt kodprojekt ergo versionshantering. En utgår ifrån master som är originalmappen, den mapp som du också lägger upp live på nätet. Vi kommer prata mer om master, så att du får en förståelse för namnet och vad som sker på master.

Ett sätt att se på Git

Trots att jag jobbade med Git så förstod jag inte riktigt hela processen ändå. Jag hörde om git, jobbade med de vanligaste git kommandon och fick det förklarat för mig på olika sätt. Det var som en poletten trillade aldrig ner någon gång.
Tills jag såg git i användargränssnittet (GUI) Sourcetree. För mig som är visuellt lagd i huvudet så trillade poletten ner, till hälften i alla fall.

Sourctree visualiserar processen med de olika kommandona i Git som du annars bara skriver i Terminalen eller i Terminalen i din kodeditor. Här visar Sourcetree hur Git fungerar som ett träd, vilket brukar vara en vanligt liknelse för Git.

Ett träd kan grena ut sig åt olika håll (och i det här fallet kan grenarna även gå tillbaka in i trädet). Master är själva trädets stam, ursprunget som allt annat kretsar kring, den visas i blått på denna bild. Det går att uppdatera direkt till master och den får då en tidsstämpel med en kommentar om uppdateringen, som du kan se i bilden ovan. Det är när du har skapat en separat branch (gren = logiskt) som trädet git grenar ut sig. Den vill du sedan merge (sammanfoga) med det stora trädet när du har jobbat klart med grenen.

Kommer förklara detta mer ingående senare, så om du inte förstår det nu så är det helt okej. Fastna inte i de termerna nu. Bra att känna till, det går helt fint att arbeta med Git helt utan någon form av GUI.

Hur övervinner en osäkerheten 🤷🏻‍♀️

Tips nummer 1 – Hur ska jag komma ihåg allt?

Alla med kodkunskap kan arbeta med Git. Det är ett faktum. Precis som att git kommandona är alltid likadana. Och nej, utvecklare kan inte hålla dem alla i huvudet. Vi har en vag känsla av att git branch -D kanske tar bort en branch, eller var det git branch -d och googlar svaret.
Vi alla gör det. Lika bra att vara ärlig med det så ingen tror att vi alla sitter med en hel databas med git kommandon i huvudet.
Kan vara fint att hålla en samlad lista i t.e.x anteckningar med de git kommandon som du lär dig längs vägen. Då har du alltid en pålitligt resurs att vända dig till.

Tips nummer 2 – Olyckor sker. För oss alla.

Ytterligare ett faktum är att du kan råka radera en hel hemsida (det har hänt mig). Eller få en merge conflict som tar timmar att lösa och du behöver kalla in hjälp från kollegor (det har hänt mig).
Jag säger inte det här för att skrämmas utan jag vill att du ska vara medveten om fakta. Precis lika enkelt som det är att råka radera en hel hemsida så är det att återställa den. Och let’s face it – Ingenting kan explodera. Ju snabbare du inser det, desto mindre osäkerhet kommer råda.

Tips nummer 3 – Övning ger färdighet

Gör. Gör. Gör. Och så gör du lite mer. Till slut så sitter det.
Jag drog mig ofta för att pusha upp förändringar eftersom jag satt konstant med alla tankar om vad som kan gå fel. Ja, inte så konstigt att en hade en hel klump i magen varje gång som jag skulle köra git push innan jag gick hem för dagen. Det kanske bara ligger i min natur att bli neurotisk och nervös. Jag misstänker att det finns fler av oss därute som behöver höra det här.
Försök att låta bli att oroa dig för eventuella misstag. Gör. Och har det uppstått ett misstag? Lös det då. Majoriteten av gångerna så går allt som smort!

Tips nummer 4 – Branches

Tänk att branches är din bästa vän.
Att jobba i en branch är som att ta en kopia av hela repot som du sedan i lugn och ro kan arbeta vidare med. Här kan du add, commit och pusha upp till den enskilda branchen och det är inget som påverkar master.

Vi alla bakom skärmen är människor, vi begår misstag. En commit som pushas upp kanske inte är helt klar eller perfekt varje gång.
Se på Git som ett sätt att spara ditt arbete i slutet på dagen. Ett sätt att säkra att de arbetstimmar som du lagt på något finns kvar och inte försvinner. Och gör du då detta i en separat branch så behöver du inte känna stressen över att commit till master branchen. Det är ett sätt att få in vanan att arbeta med git i lugn och ro, i en egen del av repot.
Inte alla har råd med en så chill attityd men adoptera den i smyg ändå. Alla fel går att lösa.

Var börjar en med git?

Utöver att prata om det, så tänkte jag också visa hur en kan arbeta med git och lite av de vanligaste kommandona och var du kan börja. För att du faktiskt ska få lite matnyttig kunskap att ta med dig i ryggsäcken också.

Det kan se olika ut beroende på vilka olika språk, datorer och program som en använder. Fastna inte i de detaljerna som skiljer saker och ting åt, utan fokusera på helheten. I grund och botten är det mesta relativt likt.

För just den här guiden så kommer vi använda oss av Github som är en hemsida som kan lagra historiken av ditt projekt. Det finns andra liknande sidor såsom t.e.x Bitbucket, SourceForge, GitLab, etc.

Skapa ett nytt repo

Nu utgår vi ifrån att du har en mapp på rooten på din dator som heter Repos. Här samlar du alla dina repos. I mitt fall så sitter jag på en Mac och då ser det ut såhär:

• Rooten är Carolinas Macbook Air
• Namnlös är hårddisken
• Användare är mappen med de olika användarna på datorn, ex gäst eller ditt-namn
• carolinajsall är den användare som jag har på min dator
• Repos är mappen där jag förvarar alla mina kodprojekt

På Github kan du skapa ett nytt repo som du sedan ska kopiera ner till din dator. Om du inte redan har en användare på Github så kan du skapa en.

Då väljer jag knappen New för att skapa ett helt nytt repo för det kodprojekt som jag ska sätta upp nu.

Här ska vi nu ange namn på kodprojektet, en beskrivning av det (valfritt). Sedan också välja om det ska vara ett publikt repo eller privat. Väljer du publikt så kommer alla användare på Github att kunna söka fram ditt repo och titta på det, men det är du som bestämmer vem som kan lägga upp saker i ditt projekt.

Jag ska skapa en blogg, så då har jag valt att göra de här inställningarna just nu. Det går alltid att gå tillbaka och lägga repot publikt eller lägga till saker i efterhand.

• README är en fil där du kan berätta mer detaljerat om kodprojektet. Ex vilka kodspråk som används, hur har du valt att arbeta med ex namn på stylingen eller hur du önskar att andra människor använder det här projektet när de klonar ner det.
• .gitignore är precis vad det låter som. En fil där du kan ange olika filer som git ska ignorera när du pushar upp något till ditt repo. Det kan se olika ut vilka filer som en lägger in här. Är du osäker, välj ingen .gitignore och ta det sedan när du får användning för det.
• License här kan du välja vilken licens som ditt projekt ska ha. Är det ett open source projekt eller inte, det avgör lite vilken licens som projektet ska ha. Du behöver inte välja något här nu om du känner dig osäker. Det är bra att kolla på de olika förslagen på licenser och läsa på lite om dem. Du kan behöva den kunskapen i framtiden.

Klart – Nu har du skapat ditt första repo 🥳
Ganska fränt va? Nu vill jag att du klappar dig på axeln.

Jaha, hur får jag ner det på datorn då?

Kanske inte helt intiutivt. Nu trycker vi på knappen Code för att klona/kopiera ner vårt repo till den fysiska datorn.

Kanske inte helt intiutivt. Nu trycker vi på knappen Code för att klona/kopiera ner vårt repo till den fysiska datorn.

• HTTPS – Här kan du klona repot via URL:en som repot har.
• SSH – Eller så kan du välja att klona repot med hjälp av dina SSH nycklar. Det kräver dock att du har kopplat din användare med din publika SSH nyckel. Vi kommer prata mer om SSH nycklar, vad de är och hur de fungerar senare och då kan vi titta på hur en kan klona med hjälp av dem då.
• GitHub CLI – Ett tredje sätt att klona repot på, som jag inte ens går in på nu. Vi klarar oss fint med HTTPS eller SSH.

Jag väljer för enkelhetens skull att klona repot med HTTPS och kopierar då URL:en.

Nu öppnar vi ett terminalfönster i datorn. Säkerställ att du står i din mapp Repos i terminalen.
Du kan använda cd (change directory) för att byta mapp i Terminalen. Så ska du gå in i mappen Repos skriver du cd Repos.
Då kommer du se vilken mapp som du står i, ex user@rooten Repos ~
Sedan skriver du git clone och klistrar in URL:en till ditt github repo. Då ska du ha något som ser ut ungefär såhär:

Så kör vi det och då kommer du få ange ditt användarnamn på Github samt ditt lösenord. Och sedan kan ditt repo klonas och då ser det ut såhär:

Så går vi in i mappen Repos och kikar om vi har ett nytt projekt där?

Jajamensan – Woho! Klapp på axeln! 💪🏾

Om du nu tittar i mappen ditt-projekt-namn på datorn så kan du se att de filer som finns på Github är densamma. Så då ska vi testa och se om vi kan göra några ändringar i koden på datorn som visas på Github också. Då får du se hur kopplingen fungerar åt andra hållet också.

Det tar vi senare. Nu tror jag du och hjärnan behöver lite välförtjänt vila först.
Så hoppas jag att vi ses snart igen 👋🏼

 

Länk till original blogginlägget