Git — versionshantering

Git sparar ögonblicksbilder av hela projektet. Varje commit är ett läge du kan gå tillbaka till, med ett meddelande som säger varför.

De tre platserna en fil kan vara på:

arbetskatalog  --git add-->  staging  --git commit-->  historik
 (dina filer)               (det du                   (permanent)
                          tänker spara)

De kommandon du faktiskt använder:

Kommando	Gör
git status	vad har ändrats?
git add <fil>	lägg till i nästa commit
git commit -m "..."	spara ögonblicksbilden
git log --oneline	visa historiken
git diff	vad skiljer?
git switch -c <namn>	ny gren
git merge <gren>	slå ihop

En gren är en egen utvecklingslinje. Du kan prova något galet utan att förstöra det som fungerar, och kasta bort det om det inte blev något.

Varför ML-arbete kräver versionshantering mer än vanlig kod. Ett resultat är reproducerbart bara om du vet alla delar som gav det:

Vad	Hur det versioneras
Kod	Git, som vanligt
Hyperparametrar	konfigurationsfil i Git, inte hårdkodat i en notebook
Data	hash eller versionsnummer i Git; själva datan hos DVC, LakeFS eller ett artefaktlager
Miljö	requirements.txt med låsta versioner, eller en container-tagg
Modellvikter	artefaktlager, med en länk till commiten
Slumpfrö	i konfigurationen

Att spara koden men inte hyperparametrarna ger ett resultat du aldrig kan återskapa. Regeln: allt som påverkar resultatet ska gå att peka ut med ett commit-id.

AI-grafen gör precis det — varje labbkörning loggar commit, frö, indata-hash och miljö-tagg.

Vad som INTE ska ligga i Git:

Nej	Varför	I stället
Hemligheter, API-nycklar	historiken är permanent — en borttagen nyckel finns kvar	Vault, miljövariabler
Stora datafiler	repot blir ohanterligt	DVC, objektlagring
Modellvikter	samma sak	artefaktlager
.ipynb_checkpoints, __pycache__	brus i varje diff	.gitignore

Den första raden är viktig och underskattad: en nyckel som någon gång committats ska betraktas som läckt, även om den tagits bort i en senare commit. Den finns kvar i historiken och i alla kloner. Rätt åtgärd är att byta nyckeln.

Merge-konflikter uppstår när två grenar ändrat samma rader. Git markerar dem:

<<<<<<< HEAD
lr = 0.001
=======
lr = 0.01
>>>>>>> experiment

Du redigerar filen till det du vill ha, tar bort markörerna, och git add + git commit. Konflikter är inte ett fel — de är Git som ber dig fatta ett beslut som den inte kan fatta åt dig.

Gör hela flödet i terminalen. Tio minuter, och du har provat allt som räknas.

mkdir experiment && cd experiment && git init

# Första commiten
echo "lr = 0.001" > config.py
git add config.py
git commit -m "Utgångsläge: lr 0.001"

# Prova något på en gren
git switch -c hogre-lr
echo "lr = 0.01" > config.py
git commit -am "Prova lr 0.01"

# Under tiden ändras huvudgrenen
git switch main
echo "lr = 0.003" > config.py
git commit -am "Prova lr 0.003"

# Slå ihop → konflikt
git merge hogre-lr
# CONFLICT (content): Merge conflict in config.py

cat config.py          # titta på markörerna
echo "lr = 0.01" > config.py     # bestäm dig
git add config.py && git commit -m "Välj lr 0.01 efter jämförelse"

git log --oneline --graph --all

Tre kommandon som räddar dig när något gått fel:

Läge	Kommando
Ångra ändringar i en fil (inte committad)	git restore <fil>
Ta bort en fil från staging	git restore --staged <fil>
Se vad du gjorde, även efter en misslyckad reset	git reflog

git reflog är den bästa nyheten för den som just trott sig ha förlorat arbete: Git glömmer nästan aldrig något på en vecka.