Du ska publicera en ändring på webbplatsen, men terminalen visar filer du inte väntade dig och en commit innehåller kanske för mycket. Git-kommandon hjälper dig oftast att reda ut läget utan att börja om, men rätt val beror på om ändringen bara finns i arbetskatalogen eller redan har delats med andra.
Snabbguide till Git-kommandon för vardagsjobb
- Kontrollera först med
git statusochgit diffinnan du ändrar något. - Granska urvalet med
git diff --stagedföre commit. - Hämta säkert med
git fetch; integrera separat när du vet vad som har ändrats. - Välj rätt ångra-kommando:
restoreför filer,revertför delade commits,resetför lokal historik.
Börja med status innan du ändrar något
En kort kontroll kan spara dig från att råka lägga upp en halvfärdig sida eller en lokal inställningsfil. Kör git status först: kommandot visar vilken branch du är på och om filer är ändrade, nya eller redo att committas.
För att se själva innehållet använder du git diff för ändringar som ännu inte är staged, alltså valda för nästa commit. Efter git add visar git diff --staged vad som faktiskt kommer med. Jag tycker att den sista kontrollen är värd vanan, särskilt när webbprojektet innehåller både textändringar och automatiskt genererade filer.
Kommandon för att skapa och dela ändringar
När statusen är begriplig blir arbetsflödet ganska rakt. En commit sparar ett urval av ändringar som en punkt i projektets historik; den skickas inte automatiskt till en server.
| Uppgift | Kommando | Vad det gör |
|---|---|---|
| Skapa ett lokalt repo | git init | Startar Git-hantering i katalogen. |
| Hämta ett repo | git clone | Kopierar ett befintligt repo till datorn. |
| Välja filer | git add filnamn | Lägger filens ändringar i stagingområdet. |
| Välja delar av en fil | git add -p | Låter dig välja ändringar stycke för stycke. |
| Skapa commit | git commit -m "Beskrivning" | Sparar det staged urvalet i historiken. |
| Skicka commits | git push | Publicerar lokala commits till fjärrrepon. |
| Visa historiken | git log --oneline --graph | Visar commits i kompakt grafisk form. |
Om du exempelvis ändrar sidans rubrik och samtidigt får med en lokal konfigurationsfil kan git add -p låta dig välja bara rubrikändringen. Granska sedan git diff --staged och committa. Det är ett mer kontrollerat val än att reflexmässigt stagea allt med git add ..
Välj branch när arbetet behöver hållas isär
En branch låter dig utveckla en ändring utan att blanda in den direkt i huvudlinjen. Skapa och byt till en ny branch med git switch -c feature/ny-landningssida; byt tillbaka med git switch main.
När arbetet är klart kan du föra in branchens commits med git merge feature/ny-landningssida. Om en annan branch redan innehåller commits som saknas lokalt kan git rebase main lägga om din lokala commitserie ovanpå den. Git-dokumentationen beskriver rebase som att commits återappliceras på en ny bas; eftersom det skriver om commit-historik bör du undvika att rebase:a commits som redan delas med andra.
Fetch och pull gör olika saker
En vanlig överraskning är att git pull gör mer än att hämta information. git fetch hämtar uppdateringar från fjärrrepon utan att integrera dem i din aktuella branch, medan git pull hämtar och integrerar ändringarna.
För en webbplatsbranch där du vill se vad teamet har publicerat innan du blandar in det, kör git fetch och inspektera sedan skillnaden. När du redan har granskat läget kan git pull --ff-only vara ett tydligt val: kommandot avbryter i stället för att skapa en merge om din branch inte kan uppdateras som en enkel framflyttning. Den officiella Git-referensen listar kommandona för hämtning, integrering och delning.
Ångra rätt sak med restore, reset eller revert
De tre kommandona låter snarlika, men påverkar olika delar av Git. git restore återställer filinnehåll, git reset flyttar branchens position eller ändrar stagingområdet, och git revert skapar en ny commit som tar tillbaka effekten av en tidigare commit.
| Situation | Trolig innebörd | Gör så här |
|---|---|---|
| En filändring ska bort, men är inte committad | Arbetskopian innehåller oönskat innehåll. | git restore filnamn |
| En fil ska ur staging, men ändringen ska finnas kvar | Filen är vald för commit av misstag. | git restore --staged filnamn |
| En felaktig commit har redan delats | Andra kan redan ha hämtat committen. | git revert |
| En lokal commit ska tas bort ur den egna historiken | Historiken behöver flyttas tillbaka. | Kontrollera först läget; använd git reset med omsorg. |
Det avgörande är alltså om committen redan är offentlig. Git-dokumentationen rekommenderar en ny återställande commit när ändringen har delats, medan reset ändrar historikens position. Jag skulle välja revert för en delad commit, eftersom den metoden inte kräver att teamets redan publicerade historik skrivs om. Mer om skillnaderna finns i dokumentationen för git revert.
Tre kontroller som gör kommandolistan säkrare
Kommandon som raderar filer eller skriver om historik förtjänar en paus innan du kör dem. Om du är osäker, börja med att läsa status och diff; de visar vad Git faktiskt tänker ändra.
- Före commit: kör
git statusochgit diff --staged. - Före integration: kör
git fetch, granska brancherna och välj sedan merge eller pull. - Före historikändring: kontrollera om committen har pushats eller används av andra.
- Vid tillfälligt avbrott: spara ändringar med
git stash push -m "pågående arbete"och återta dem senare medgit stash pop.
Om terminalen fortfarande känns som en vägg av kommandon, skriv git help , till exempel git help restore. En bra snabbguide ska hjälpa dig att välja nästa säkra steg, inte locka dig att köra det första kommando som ser bekant ut.