Git — version control

Git saves snapshots of the whole project. Every commit is a state you can go back to, with a message that says why.

The three places a file can be:

working directory  --git add-->  staging  --git commit-->  history
   (your files)                 (what you                 (permanent)
                              mean to save)

The commands you actually use:

Command	Does
git status	what has changed?
git add <file>	add it to the next commit
git commit -m "..."	save the snapshot
git log --oneline	show the history
git diff	what differs?
git switch -c <name>	a new branch
git merge <branch>	merge it

A branch is a development line of its own. You can try something wild without breaking what works, and throw it away if it came to nothing.

Why ML work needs version control more than ordinary code does. A result is reproducible only if you know all the parts that produced it:

What	How it is versioned
Code	Git, as usual
Hyperparameters	a config file in Git, not hard-coded in a notebook
Data	a hash or version number in Git; the data itself in DVC, LakeFS or an artefact store
Environment	requirements.txt with pinned versions, or a container tag
Model weights	an artefact store, with a link to the commit
Random seed	in the config

Saving the code but not the hyperparameters gives you a result you can never recreate. The rule: everything that affects the result must be identifiable by a commit id.

AI-grafen does exactly that — every lab run logs the commit, the seed, the input hash and the environment tag.

What should NOT live in Git:

No	Why	Instead
Secrets, API keys	the history is permanent — a deleted key is still there	Vault, environment variables
Large data files	the repo becomes unmanageable	DVC, object storage
Model weights	the same	an artefact store
.ipynb_checkpoints, __pycache__	noise in every diff	.gitignore

The first line is important and underestimated: a key that has ever been committed must be treated as leaked, even if it was removed in a later commit. It is still in the history and in every clone. The right response is to rotate the key.

Merge conflicts arise when two branches have changed the same lines. Git marks them:

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

You edit the file into what you want, remove the markers, and git add + git commit. Conflicts are not an error — they are Git asking you to make a decision it cannot make for you.

Do the whole flow in the terminal. Ten minutes, and you have tried everything that counts.

mkdir experiment && cd experiment && git init

# The first commit
echo "lr = 0.001" > config.py
git add config.py
git commit -m "Starting point: lr 0.001"

# Try something on a branch
git switch -c higher-lr
echo "lr = 0.01" > config.py
git commit -am "Try lr 0.01"

# Meanwhile the main branch changes
git switch main
echo "lr = 0.003" > config.py
git commit -am "Try lr 0.003"

# Merge → a conflict
git merge higher-lr
# CONFLICT (content): Merge conflict in config.py

cat config.py          # look at the markers
echo "lr = 0.01" > config.py     # make up your mind
git add config.py && git commit -m "Choose lr 0.01 after comparing"

git log --oneline --graph --all

Three commands that save you when something has gone wrong:

Situation	Command
Undo changes in a file (not committed)	git restore <file>
Take a file out of staging	git restore --staged <file>
See what you did, even after a botched reset	git reflog

git reflog is the best news there is for someone who has just thought they lost their work: Git almost never forgets anything within a week.