Les bases de Git

Un historique auquel on peut revenir

Git enregistre l'historique d'un projet sous forme de commits : des instantanés de tous les fichiers suivis, chacun avec un auteur, une heure et un message. Il permet de voir ce qui a changé et pourquoi, d'essayer une idée sans crainte et de revenir à une version qui fonctionnait. Un dossier sous le contrôle de Git est un dépôt (repository). Le travail quantitatif s'y appuie beaucoup : un résultat n'est fiable que si l'on peut dire exactement quelle version du code l'a produit.

# Start tracking a project (once)
git init

# See what changed, stage it, record it
git status
git add main.py README.md
git commit -m "Add the first backtest loop"

# Look back
git log --oneline
git diff                      # changes not yet staged

Les trois endroits où vit une modification

Une modification traverse trois zones. Vous éditez les fichiers dans le répertoire de travail. git add copie les changements choisis dans la zone d'index (le prochain instantané, en préparation). git commit enregistre l'instantané indexé dans l'historique du dépôt. Cela permet de valider ensemble seulement les changements liés, même si vous avez modifié beaucoup de fichiers. git status montre chaque fichier dans sa zone : modifié, indexé ou non suivi (nouveau et pas encore connu de Git).

# git status --porcelain prints two status letters, a space, then the path
status = """ M main.py
A  notes.md
?? scratch.txt
D  old.py"""

for line in status.splitlines():
    code, path = line[:2], line[3:]
    print(repr(code), path)
# ' M' main.py     (modified, not staged)
# 'A ' notes.md    (new, staged)
# '??' scratch.txt (untracked)
# 'D ' old.py      (deleted, staged)

Les branches

Une branche est un nom mobile pour une ligne de commits. Créez-en une par idée ou correctif (git switch -c fee-model), validez-y librement et, quand cela fonctionne, ramenez-la dans la ligne principale avec git merge (en général depuis la branche main). Les noms de branche peuvent contenir lettres, chiffres, -, _, / et ., mais pas d'espaces ni aucun de ~ ^ : ? * [ \, et ils ne peuvent ni commencer ou finir par / ni finir par .. Git signale les conflits quand deux branches ont modifié les mêmes lignes, et vous les résolvez à la main.

# Try an idea on its own branch, then bring it back
git switch -c fee-model
git commit -am "Use tiered fees"
git switch main
git merge fee-model

# List branches (the current one has a star)
git branch

Ce qu'il faut exclure, et comment annuler

Un fichier .gitignore liste les motifs que Git ne doit pas suivre : .venv/ (un dossier, écrit avec une barre finale), *.log (tout fichier correspondant à un joker), secrets.env. Excluez les environnements virtuels, les caches, les gros fichiers de données et surtout les secrets comme les clés d'API : tout ce qui est validé reste dans l'historique même si on le supprime ensuite. Pour annuler, git restore fichier jette les modifications non validées d'un fichier, et git revert <commit> ajoute un nouveau commit qui annule un ancien, ce qui est sûr sur les branches partagées. git push et git pull échangent des commits avec une copie distante, par exemple sur GitHub.

# .gitignore
.venv/
__pycache__/
*.log
secrets.env

# Undo safely
git restore main.py            # drop uncommitted edits to one file
git revert 3f2a9c1             # new commit that cancels an old one

# Share
git push origin main
git pull

• git init, git status, git add, git commit -m "...", git log --oneline.
• Une branche par idée : git switch -c nom, puis git merge.
• Utilisez .gitignore pour .venv/, caches, données et secrets ; annulez avec restore ou revert.

À suivre : les notebooks Jupyter, pour explorer des données de façon interactive, et comment les garder propres sous Git.

Lab : ce qui est noté

• Classer les fichiers d'un rapport git status avec parse_status25 pts
• Lire un listing git log --oneline avec parse_log25 pts
• Vérifier un nom de branche selon les règles de Git avec is_valid_branch_name25 pts
• Appliquer un .gitignore à une liste de fichiers avec not_ignored25 pts