Lägg till fil i git repot

Ditt kursrepo är ett git repo och de filer du skapar behöver du också lägga till i git repot via de kommandon som git erbjuder.

git status

Börja med att kontrollera status för ditt repo med kommandot git status.

git status

Det kan se ut så här.

Image description — Bild: Kontrollera status på ditt repo med git status.

Texten säger att filen .editorconfig ännu inte är en del av ditt repo.

git add

Låt oss lägga till filen som saknas med kommandot git add.

git add .editorconfig

Som ett alternativ kan du lägga till samtliga filer som ännu inte är en del av repot, enligt rapporten från git status.

git add .

När du lagt till filen kan du köra git status igen.

Det kan se ut så här.

Nu är filen en del av repot, men ändringarna är ännu inte committade.

git commit

För att spara ändringarna till git repot så kör vi kommandot git commit och samtidigt anger vi ett commit-meddelande om vad ändringen innebär. Dessa meddleande blir en del av repots commit-historik som berättar en historia om hur repot har utvecklats och förändrats.

git commit -m "Add the file .editorconfig with default settings for the course"

Kör git status när du committat, för att se hur läget ser ut.

Det kan se ut så här.

Du kan nu utläsa från git status att din lokala branch är ett steg före din remote origin/main som innebär att din lokala kopia har en ändring mer än den version av repot som ligger på GitHub.

När du committar bör det vara commits som du kan beskriva i ett enkelt och tydligt meddelande. Om det blir svårt att skriva ett kort meddelande om din commit så innehåller den troligen för mycket saker. Men så här i början är det viktigare att göra många commits än att skriva perfekta meddelanden till commit-historiken, det kommer med träningen.

Här är ett par korta regler när det kommer till commit-meddelanden.

Börja med stor bokstav
Sluta ej med punkt

git push

För att ladda upp ändringarna till GitHub, din remote, så använder du kommandot git push. Då kommer samtliga lokala ändringar att laddas upp till din remote (GitHUb) så att både din remote och din lokala version är “i synk” och har samma innehåll och samma commit-historik.

Kör nu kommandot git push.

git push

Det kan se ut så här.

Du kan se hur utskriften från git status berättar att din lokala branch är i synk med din remote.

git pull

Om läget hade varit det motsatta, att den version som ligger på GitHub är mer aktuell än din lokala kopia, då löser du det med kommandot git pull som laddar ned ändringarna från din remote på GitHub.

Du kan köra kommandot nu, inget kommer att hända eftersom din remote (GitHub) och din lokala version av git repot är “i synk”.

git pull

Det kan se ut så här.

Om du är osäker på att du är i synk så kan du alltid göra git status tillsammans med git pull och git push tills du är i sync. Ta det som en vana att alltid pusha ditt jobb till din remote, innan du lämnar din dator, så slipper du glömma det.

git log

Den här delen är överkurs men kan vara intressant att jobba igenom.

För varje commit du gör till ett git repo så sparas det i en git commit historik, en git logg. Man kan få fram en översikt av dessa commit-meddelanden med kommandot git log.

Kör följande kommando för att se hur en commit-historik kan presenteras.

git log
# Tryck på "q" för att avsluta utskriften.

Så här kan det till exempel se ut. Din egen utskrift kan se annorlunda ut, beroende av hur din egen historik ser ut.

Man kan förändra utskriften från kommandot genom att skicka argument till kommandot, så här.

git log --oneline --graph --decorate
# Tryck på "q" för att avsluta utskriften.

Det kan se ut så här.

Om du inte kommer ihåg det långa kommandot så kan du skapa ett git alias för det, så blir det lättare att skriva det i fortsättningen. Så här skapar du ett git alias för det långa kommandot, när aliaset är skapat så räcker det att skriva git gl för att visa historiken.

# Create a git alias to view the log
git config --global alias.lg "log --oneline --graph --decorate"

# Execute the git alias
git lg

Nu räcker det alltså om du i fortsättningen skriver git lg för att se den formatterade varianten av git commit historik.

Nu i början är det kanske inte så intressant att titta i historiken, men ju mer du använder git och ju mer erfaren du blir så kan det också bli allt viktigare att ha koll på hur din commit historik ser ut.