Bases de Git pour data scientists : suivre, valider et collaborer

Le contrôle de version sans le jargon du génie logiciel — la boucle quotidienne qui rend vos analyses R et Python reproductibles, récupérables et partageables.

Un guide Git pratique pour les data scientists qui vivent dans R et Python. Apprenez le modèle mental (répertoire de travail, indexation, commit, historique), la boucle quotidienne — git status, git add, git commit, git log — un vrai .gitignore pour la data science, le branchement léger, et l’envoi vers GitHub ou GitLab.

Date de publication

26 juin 2026

Modifié

7 juillet 2026

AstucePoints clés
  • Git répond à « qu’est-ce qui a changé, et quand ? » — la question à laquelle toute analyse reproductible doit répondre. Il enregistre des instantanés de votre projet pour que vous puissiez voir, comparer et annuler n’importe quel changement que vous ayez jamais fait.
  • Le modèle mental tient en trois endroits : votre répertoire de travail (les fichiers que vous éditez) → la zone d’indexation (les changements que vous avez marqués pour enregistrement) → un commit (un instantané permanent dans l’historique de votre projet).
  • La boucle quotidienne, c’est quatre commandes : git status (ce qui a changé) → git add (l’indexer) → git commit -m "…" (l’enregistrer) → git log (revoir l’historique). Vous les lancerez des dizaines de fois par jour.
  • Un .gitignore tient le superflu à l’écart — fichiers de données, .Rhistory, __pycache__/, secrets .env, sorties générées. Ce que vous ne validez pas compte autant que ce que vous validez.
  • Les branches vous laissent essayer en toute sécurité. git checkout -b experiment vous donne une copie parallèle à casser ; fusionnez-la si ça marche, jetez-la sinon.
  • Les dépôts distants vous connectent à GitHub/GitLab — git clone, git push, git pull — pour la sauvegarde et la collaboration. Ne poussez jamais de secrets ni de grandes données.

Introduction

Votre analyse n’est pas reproductible si vous ne pouvez pas dire ce qui a changé et quand. Vous ajustez un modèle, les chiffres bougent, et trois semaines plus tard vous ne vous rappelez plus si vous avez retiré les valeurs aberrantes avant ou après la mise à l’échelle — ni quelle version a produit la figure qui se trouve maintenant dans votre article. « Final_v2_REALLY_final.R » n’est pas du contrôle de version ; c’en est l’absence.

Git est ce qui vous permet de combler cet écart. C’est un outil qui prend des instantanés de votre projet à la demande, étiquette chacun avec un message, et conserve toute la séquence pour que vous puissiez revenir en arrière, comparer et annuler. Pour une plateforme dont toute la promesse est si ça s’affiche, ça s’exécute, Git est la couche en dessous : c’est ce qui vous permet (à vous, à un collaborateur, et à votre vous futur) de reproduire exactement l’état qui a produit un résultat.

Cette leçon est le cœur pratique, destinée à quelqu’un qui vit dans R et Python, pas à quelqu’un qui livre du logiciel. Nous couvrirons le modèle mental, la boucle de commit quotidienne, un .gitignore réglé pour les projets de data science, le branchement léger, et la connexion à GitHub ou GitLab. Nous passons sur les rouages profonds — vous n’en avez pas besoin pour les gains du quotidien.

Chaque commande ici est réelle — copiez-la et exécutez-la dans votre terminal. Il n’y a pas d’exécution dans le navigateur sur cette page ; Git vit dans votre shell.

Le modèle mental : les trois endroits où peut se trouver un fichier

Git est bien moins déroutant une fois qu’on garde une image en tête. Un changement apporté à un fichier traverse trois endroits :

  1. Répertoire de travail — les vrais fichiers sur le disque que vous êtes en train d’éditer. RStudio, VS Code, un notebook : c’est là que vous travaillez.
  2. Zone d’indexation (l’« index ») — un sas où vous marquez quels changements vous voulez inclure dans votre prochain instantané. Vous indexez les changements que vous êtes prêt à enregistrer et laissez le reste.
  3. Historique du dépôt — la série permanente de commits. Chaque commit est un instantané étiqueté ; une fois enregistré, il reste.

Vous éditez dans le répertoire de travail, indexez ce qui est prêt avec git add, puis le validez dans l’historique. La zone d’indexation est la partie que les débutants négligent, mais c’est la plus utile : elle vous laisse valider juste le code du modèle maintenant et le graphique à moitié fini plus tard, au lieu d’un seul instantané fouillis.

Installer et configurer — une seule fois

Installez Git depuis git-scm.com (macOS et Linux l’ont souvent déjà ; vérifiez avec git --version). Puis dites à Git qui vous êtes. Git estampille chaque commit avec un nom et un courriel, alors définissez-les une fois pour toutes globalement — c’est une configuration unique par machine, pas par projet :

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Rien ne s’affiche ; Git écrit cela dans ~/.gitconfig. Désormais chaque commit que vous faites vous est attribué. Tant que vous y êtes, définissez un éditeur par défaut sensé et le nom de branche par défaut pour que les nouveaux dépôts démarrent sur main :

git config --global init.defaultBranch main
git config --global core.editor "nano"   # or "code --wait" for VS Code

Pour confirmer que tout est en place, listez votre configuration. La sortie affiche votre nom, votre courriel et votre éditeur — relisez-la pour attraper les fautes de frappe :

git config --list

Commencer à suivre un projet

Déplacez-vous dans le dossier de votre projet et transformez-le en dépôt Git. git init crée un répertoire caché .git/ où Git stocke tout l’historique — vos fichiers ne changent pas, ils deviennent simplement suivables :

cd my-analysis
git init

Vous verrez Initialized empty Git repository in …/my-analysis/.git/. Le dossier est maintenant un dépôt, mais rien n’est encore suivi. (Si au contraire vous partez d’un projet qui vit déjà sur GitHub/GitLab, vous feriez un git clone — couvert plus bas — et git init est fait pour vous.)

La boucle quotidienne : status → add → commit → log

C’est la boucle que vous lancerez toute la journée. Commencez par demander à Git ce qui a changé. git status est la commande que vous taperez le plus — elle montre quels fichiers sont nouveaux, modifiés ou indexés :

git status

Sur un dépôt tout neuf, elle liste chaque fichier comme non suivi (en rouge), ce qui signifie que Git les voit mais ne les enregistre pas encore. Ensuite, indexez les changements que vous voulez prendre en instantané. Utilisez un nom de fichier pour indexer un seul fichier, ou . pour tout indexer dans le dossier courant :

git add analysis.R
git add .            # stage everything that changed

Rien ne s’affiche, mais git status montre maintenant ces fichiers en vert sous « Changes to be committed » — ils sont indexés et prêts. Maintenant validez l’instantané avec un court message décrivant ce que vous avez fait. Le message est pour votre vous futur, alors soyez précis :

git commit -m "Add data-cleaning script and initial model"

Git affiche un résumé — la branche, un identifiant de commit court, et combien de fichiers ont changé. Cet instantané est maintenant permanent dans votre historique. Enfin, revoyez l’historique. git log liste les commits du plus récent au plus ancien ; l’option --oneline le garde lisible :

git log --oneline

Vous verrez une ligne par commit — l’identifiant court et votre message — une chronologie lisible du projet. Voilà toute la boucle de base : éditer → git status → git add → git commit -m → git log, répétée au fil du travail. Validez par petits blocs logiques (une correction ou une fonctionnalité à la fois), pas une fois par semaine dans un gros pâté — ce sont les petits commits qui rendent possible le « annuler juste ce changement ».

Voir et annuler les changements

Deux commandes de plus gagnent leur place chaque jour. git diff montre les lignes exactes que vous avez changées depuis le dernier commit — lisez-la avant d’indexer, pour confirmer que vous validez bien ce que vous croyez :

git diff

Et si vous avez fait des dégâts dans un fichier et voulez jeter vos modifications non validées, restaurez-le à la dernière version validée (cela écarte les changements, alors soyez sûr) :

git restore analysis.R

Le fichier revient d’un coup à son dernier état validé. Cela — récupérer une version connue comme saine en une seule commande — est le bénéfice quotidien de valider souvent.

.gitignore : tenir le superflu et les secrets à l’écart

Tout ce qui se trouve dans un dossier de projet n’a pas sa place dans Git. Les données brutes peuvent être énormes, les fichiers .env contiennent des secrets, et les sorties générées sont régénérées à partir de la source. Un fichier .gitignore liste des motifs que Git doit faire comme s’il ne les avait jamais vus — ils n’apparaîtront pas dans git status et ne peuvent pas être validés par accident.

Créez un fichier nommé .gitignore à la racine de votre projet. En voici un réaliste pour un projet de data science R/Python :

# Data — too big and/or sensitive to version (track code that produces it, not the data)
data/
*.csv
*.parquet
*.rds
*.xlsx

# Secrets — API keys, DB credentials, tokens. NEVER commit these.
.env
.Renviron
*.pem

# R session cruft
.Rhistory
.RData
.Rproj.user/

# Python session cruft
__pycache__/
*.pyc
.ipynb_checkpoints/
.venv/
env/

# Rendered / generated output (regenerated from source)
*.html
/_site/
/output/
/renv/library/

Avec ça en place, git status reste propre et concentré sur la source qui compte — vos scripts, notebooks et fichiers .qmd — au lieu de se noyer dans les fichiers de données et les caches. Ajustez selon votre goût : si un petit jeu de données de référence doit vraiment être suivi, retirez son motif (ou ajoutez-le en liste blanche avec !data/lookup.csv).

Une bonne règle générale : validez le code qui produit un résultat, pas le résultat. Quiconque dispose de votre code et d’une trace de votre source de données peut reproduire la sortie ; il ne peut pas la rétroconcevoir à partir d’un plot.png égaré.

Le branchement — gardé léger

Une branche est une ligne de travail parallèle. Celle par défaut est main. Quand vous voulez essayer quelque chose de risqué — une approche de modélisation différente, un gros remaniement — créez une branche pour que main reste propre et fonctionnel. Créez et basculez sur une nouvelle branche en une seule étape :

git checkout -b try-random-forest

Vous êtes maintenant sur try-random-forest. Validez librement ici ; main reste intact. Listez vos branches à tout moment (le * marque celle sur laquelle vous êtes) :

git branch

Si l’expérience marche, fusionnez-la. Basculez sur main, puis tirez-y les commits de la branche :

git checkout main
git merge try-random-forest

Si l’expérience était une impasse, basculez simplement sur main et supprimez la branche — aucun mal de fait :

git checkout main
git branch -d try-random-forest

Voilà assez de branchement pour la plupart des travaux solo de data science : une branche éphémère pour tout ce dont vous n’êtes pas sûr, fusionnée ou écartée. Les flux d’équipe (pull requests, revue) s’appuient exactement là-dessus.

Dépôts distants : GitHub et GitLab

Jusqu’ici tout vit sur votre ordinateur portable. Un dépôt distant est une copie de votre dépôt hébergée sur GitHub ou GitLab — pour la sauvegarde, pour le partage, pour la collaboration. Il y a deux façons de se connecter.

Si le projet démarre sur votre machine, créez un dépôt vide sur GitHub/GitLab (n’ajoutez pas de README — c’est le vôtre, local, qui l’emporte), puis liez-le. git remote add origin nomme cette copie hébergée origin ; le premier push envoie vos commits et -u mémorise le lien :

git remote add origin https://github.com/you/my-analysis.git
git push -u origin main

Vos commits sont maintenant sur GitHub/GitLab. Après ce premier push, envoyer du nouveau travail là-haut se résume à :

git push

Si le projet existe déjà sur GitHub/GitLab, copiez-le chez vous avec git clone — cela télécharge tout l’historique et configure origin pour vous en une seule étape :

git clone https://github.com/someone/their-project.git

Pour récupérer les changements qu’un collaborateur (ou vous, sur une autre machine) a poussés, lancez pull — il récupère les nouveaux commits et les fusionne dans votre branche :

git pull

Le rythme de collaboration est simple : git pull avant de commencer (récupérer le dernier état), faites votre travail et validez, puis git push pour partager. Pour tout ce que vous poussez vers un dépôt distant partagé, les règles ci-dessous sur ce qu’il ne faut pas valider comptent encore plus — un secret poussé sur GitHub est un secret divulgué.

Ce qu’il ne faut PAS valider

Trois choses restent hors de Git, toujours :

  • Les secrets. Clés d’API, mots de passe de bases de données, jetons, fichiers .env / .Renviron. Un secret validé reste dans votre historique pour toujours, même après que vous ayez supprimé la ligne — et si vous avez poussé, supposez qu’il est compromis et changez-le. Gardez les secrets dans des variables d’environnement et placez dans le .gitignore les fichiers qui les contiennent.
  • Les grandes données. Git stocke chaque version de chaque fichier ; un jeu de données de 2 Go validé dix fois, c’est 20 Go de dépôt. Suivez le code et la source de vos données, pas les données elles-mêmes. Pour des données réellement versionnées, utilisez un outil conçu pour ça (Git LFS, DVC) — pas Git tout seul.
  • Les sorties générées. Rapports HTML, _site/, artefacts compilés, __pycache__/. Ils sont reproductibles à partir de la source, donc les valider ne crée que du bruit et des conflits de fusion. Validez le .qmd, pas le .html qu’il génère.

Le fil conducteur : Git est fait pour la source de vérité, pas pour ses sous-produits. Réussissez ça et votre dépôt reste petit, propre et sûr à partager.

Problèmes courants

Vous avez validé un secret ou un énorme fichier de données. D’abord, ajoutez le chemin fautif au .gitignore pour que ça cesse de se produire. Puis arrêtez de suivre le fichier sans le supprimer du disque — git rm --cached .env arrête de suivre .env mais laisse votre copie locale — et validez cette suppression. Notez que le fichier vit toujours dans l’historique des commits antérieurs ; si c’était un secret, changez la clé (traitez-la comme divulguée), et s’il était déjà poussé, vous aurez besoin d’outils de réécriture d’historique (git filter-repo) pour le nettoyer. La vraie solution est de le mettre dans le .gitignore avant le premier commit.

echo ".env" >> .gitignore
git rm --cached .env
git commit -m "Stop tracking .env (now gitignored)"

« You are in ‘detached HEAD’ state. » Vous avez lancé git checkout avec un identifiant de commit au lieu d’un nom de branche, donc vous regardez un instantané passé sans branche attachée — tous les commits que vous faites ici peuvent être perdus. Pas de panique : pour revenir à la normale, basculez simplement sur une branche, git checkout main. Si vous avez fait des changements que vous voulez garder en état détaché, créez d’abord une branche : git checkout -b keep-this-work.

Un conflit de fusion. Quand git merge (ou git pull) trouve les mêmes lignes modifiées de deux façons, il s’arrête et marque le heurt à l’intérieur du fichier avec les marqueurs <<<<<<<, =======, >>>>>>>. C’est normal, pas un échec. Ouvrez le fichier, choisissez ce que doit être la version finale, supprimez les lignes de marqueurs, puis faites git add du fichier et git commit pour terminer la fusion. git status liste exactement quels fichiers doivent être résolus.

« fatal: not a git repository. » Vous avez lancé une commande Git dans un dossier qui n’est pas suivi. Soit vous êtes dans le mauvais répertoire (cd dans votre projet), soit vous ne l’avez jamais initialisé — lancez git init, ou git clone le dépôt distant s’il vit sur GitHub/GitLab. Vérifiez où vous êtes avec git status : un dossier suivi rapporte sa branche ; un dossier non suivi vous renvoie cette erreur.

Questions fréquentes

Cela dépend de si vous voulez garder les changements. Pour annuler le commit mais garder vos modifications (dé-valider, en laissant les fichiers indexés), lancez git reset --soft HEAD~1. Pour l’annuler et désindexer aussi les modifications (garder les fichiers, mais comme changements non indexés), utilisez git reset HEAD~1. Pour écarter le commit et ses changements entièrement, git reset --hard HEAD~1 — destructif, donc seulement sur des commits que vous n’avez pas poussés. Si le commit est déjà poussé vers un dépôt distant partagé, ne réécrivez pas l’historique ; faites plutôt un nouveau commit qui l’inverse avec git revert HEAD, ce qui est sûr pour les collaborateurs.

Trois catégories : les données (data/, *.csv, *.rds, *.parquet — trop grandes ou sensibles pour être versionnées), les secrets (.env, .Renviron, tout ce qui contient des clés ou des mots de passe), et le superflu de session/généré (.Rhistory, .RData, .Rproj.user/, __pycache__/, *.pyc, .ipynb_checkpoints/, .venv/, et les sorties générées comme *.html ou /_site/). Le principe directeur : validez le code qui produit les résultats, pas les résultats ni les données brutes. Voyez l’exemple complet plus haut dans cette leçon, et ajustez-le — vous pouvez mettre en liste blanche un petit jeu de données de référence avec une ligne !data/lookup.csv.

git fetch télécharge les nouveaux commits du dépôt distant mais ne change pas vos fichiers de travail — il met à jour votre trace locale de ce qui se trouve sur le distant pour que vous puissiez l’inspecter d’abord (avec git log origin/main, par exemple). git pull est git fetch plus git merge : il télécharge et fusionne aussitôt ces commits dans votre branche courante, mettant à jour vos fichiers. Pull est la commande pratique du quotidien ; fetch est celle vers laquelle vous vous tournez quand vous voulez voir ce qui arrive avant de l’intégrer. Si un pull provoquait un conflit, faire un fetch d’abord vous laisse regarder avant de sauter.

Indexez sélectivement. git add uniquement les fichiers que vous voulez dans cet instantané — git add model.R report.qmd — et laissez le reste non indexé. Ensuite git commit enregistre uniquement les fichiers indexés ; les changements non indexés restent dans votre répertoire de travail pour un commit ultérieur. C’est exactement à ça que sert la zone d’indexation : elle vous laisse découper une session de travail fouillis en commits propres et logiques. Vérifiez git status avant de valider pour confirmer que seuls les fichiers voulus sont en vert.

Non. Git fonctionne entièrement sur votre machine — vous pouvez init, valider, brancher, et avoir tout l’historique de version sans compte et sans internet. GitHub et GitLab sont des services d’hébergement qui ajoutent une copie distante pour la sauvegarde et la collaboration (et une interface web pour la revue). Utilisez Git en local dès le premier jour pour les bénéfices d’annulation/historique ; ajoutez un dépôt distant GitHub ou GitLab quand vous voulez une sauvegarde ou avez besoin de partager avec d’autres.

Testez vos connaissances

Tâche 1. Vous venez de créer un nouveau dossier d’analyse avec clean.R, un fichier data/raw.csv (200 Mo), et un .env contenant un mot de passe de base de données. Esquissez les commandes pour mettre tout cela sous contrôle de version correctement — en suivant le code mais ni les données ni le secret.

Deux de ces trois fichiers ne devraient jamais être validés. Quel fichier créez-vous avant votre premier git add pour vous en assurer ?

Créez le .gitignore d’abord, puis initialisez et validez. Les données et le secret n’entrent jamais dans l’historique :

cd my-analysis
printf "data/\n*.csv\n.env\n" > .gitignore
git init
git add .gitignore clean.R
git commit -m "Initial commit: cleaning script (data and secrets gitignored)"

git status devrait maintenant montrer uniquement clean.R et .gitignore comme suivis ; data/raw.csv et .env sont ignorés et n’apparaîtront pas. Faire le .gitignore avant le premier add est ce qui garde le fichier de 200 Mo et le mot de passe hors de votre historique pour de bon.

Tâche 2. Vous êtes sur main et voulez essayer un modèle plus risqué sans perturber votre analyse en cours. Décrivez le flux de travail à base de branches, du début jusqu’à garder ou écarter l’expérience.

Une seule commande crée la branche et y bascule à la fois. La fusion se fait depuis main, pas depuis la branche d’expérience.

git checkout -b try-rf      # branch off main and switch to it
# ... edit, git add, git commit on this branch ...

# If it worked, merge it back into main:
git checkout main
git merge try-rf

# If it didn't, just abandon it:
git checkout main
git branch -d try-rf

main reste propre et exécutable tout du long. L’expérience vit sur sa propre branche ; vous ne la repliez dans main que si elle vaut la peine d’être gardée, et l’écarter est une seule commande.

Vous lancez git add results.csv puis git commit -m "save results", mais le fichier était déjà listé dans votre .gitignore. Que se passe-t-il ?

Il est validé quand même. .gitignore empêche seulement Git de suivre automatiquement les fichiers non suivis (et de les montrer dans git status) ; il ne bloque pas un git add explicite. Une fois que vous forcez l’ajout d’un fichier ignoré, Git le suit et le commit l’inclut. Pour le tenir à l’écart, ne faites pas git add dessus — et si vous l’avez validé par accident, arrêtez de le suivre avec git rm --cached results.csv et validez cette suppression.

Conclusion

Git transforme « qu’est-ce qui a changé, et quand ? » d’une supposition en un fait. Maîtrisez la boucle de quatre commandes — git status, git add, git commit, git log — gardez un .gitignore sensé, branchez quand vous n’êtes pas sûr, et poussez vers GitHub ou GitLab pour la sauvegarde et la collaboration, et votre analyse devient récupérable, partageable et véritablement reproductible. Vous n’avez pas besoin de la panoplie complète de l’ingénieur logiciel ; ce cœur du quotidien est ce qui fait le travail.

À voir aussi : Choisir un IDE — l’IDE où vous lancerez ces commandes · Des notebooks aux rapports reproductibles — rendez le travail lui-même reproductible.

Réutilisation

Citation

BibTeX
@online{2026,
  author = {},
  title = {Bases de Git pour data scientists : suivre, valider et
    collaborer},
  date = {2026-06-26},
  url = {https://www.datanovia.com/learn/programming/setup/git-basics},
  langid = {fr}
}
Veuillez citer ce travail comme suit :
“Bases de Git pour data scientists : suivre, valider et collaborer.” 2026. June 26. https://www.datanovia.com/learn/programming/setup/git-basics.