Tutoriel Git en PDF (Avancé | CHIMERE)

Git est un système de gestion de versions distribué qui stocke l'historique sous forme d'objets immuables identifiés par des SHA1 et organise le travail via trois zones distinctes : Working Directory (répertoire de travail), Staging Area (index) et Local Repository (.git). La maîtrise des fichiers de configuration (~/.gitconfig), des opérations de staging (git add), des commits et de la réécriture d'historique (git commit --amend, git rebase) est essentielle pour collaborer efficacement sur des projets scientifiques. Le document inclut des exercices pratiques prêts à exécuter sur un dépôt réel et une fiche de référence pour usage avancé.

Contrairement aux systèmes centralisés comme SVN, Git permet un travail déconnecté et une gestion de branches ultra-légère, idéale pour le workflow CHIMERE.

Prêt à passer à la pratique ? Téléchargez le tutoriel Git en PDF pour consulter ces commandes hors-ligne.

Le dossier caché .git créé par git init contient l'intégralité de la base de données du projet : objets (blobs, trees, commits), références (refs) et la configuration locale. Conserver ce répertoire à la racine du projet garantit l'intégrité de l'historique et permet de restaurer des états antérieurs via les références stockées.

Comprendre les zones de Git

Git distingue trois espaces formels : le répertoire de travail, l'index (staging) et le dépôt local. L'index sert de zone de sélection explicite : il permet d'assembler un ensemble précis de modifications pour un commit atomique, indépendamment des modifications non indexées du Working Directory. Manipuler l'index avec git add et git reset permet de composer des commits cohérents, faciliter la revue et limiter les risques lors de réécritures d'historique. Adopter une stratégie claire d'indexation améliore la traçabilité et la reproductibilité des états du dépôt.

• Répertoire de travail (Working Directory) — copie des fichiers tels qu'ils apparaissent sur le disque. Les modifications y sont éditées avant d'être indexées.
• Index / Staging Area — zone intermédiaire qui collecte les changements préparés pour le prochain commit. Utiliser git add pour constituer l'ensemble précis à committer.
• Dépôt local (.git) / Local Repository — base de données immuable contenant les commits, arbres et blobs. Les références (refs) pointent vers les commits utilisés pour restaurer des états ou partager des objets.

Cycle de vie d'un fichier : index vs Working Directory

Comprendre le passage d'un fichier entre les trois zones évite des erreurs fréquentes. Voici un schéma textuel suivi d'une explication des états et des commandes associées :

Working Directory (modifié / non suivi)
        |
    git add
        ↓
Staging Area (index) — fichier prêt à être validé
        |
    git commit
        ↓
Local Repository (.git) — snapshot commité (objet commit)

États courants et commandes utiles :

• Non suivi → fichier ajouté au répertoire de travail : git add le place dans l'index.
• Modifié → modifications dans le Working Directory ; répéter git add pour mettre à jour l'index.
• Indexé → prêt pour git commit qui crée un commit référencé dans .git.
• Annuler un ajout → git reset HEAD <fichier> retire le fichier de l'index sans toucher au Working Directory.
• Restaurer un état → git checkout -- <fichier> ou git restore selon la version de Git.

Ce cycle illustre la séparation entre modifications locales, sélection explicite des changements à commettre et enregistrement immuable dans la base de données du dépôt — principe central de la gestion de versions décentralisée.

Objectifs pédagogiques

• Configurer Git et l'identité utilisateur — paramétrer ~/.gitconfig pour définir user.name, user.email et core.editor ; modification de la configuration globale et locale et activation de la coloration avec git config color.ui auto.
• Initialiser et suivre un projet (git init / add / commit) — distinction entre fichiers suivis, non suivis et index ; utilisation de git status, git add, git commit, ainsi que git rm et git mv pour supprimer ou déplacer des fichiers tout en mettant à jour l'index.
• Branchement et navigation (branch / checkout) — création et basculement de branches légères avec git branch et git checkout -b ; isolation d'expérimentations sans polluer la branche principale main.
• Réécriture d'historique et secours (rebase / amend / reflog) — usage de git commit --amend, git rebase et consultation de git reflog pour corriger des commits locaux ou récupérer des références perdues.
• Collaboration et dépôts distants (remote / fetch / pull / push) — lier un dépôt local à des remotes (git remote add), synchroniser et publier des changements ; résolution de conflits et organisation d'un workflow multi-remote.
• Outils de visualisation et diagnostics — exploiter gitk --all, git diff, git blame et git cherry-pick pour inspecter et intégrer des changements précisément.

Commandes Git essentielles pour débuter

Les commandes ci‑dessous couvrent les opérations élémentaires à maîtriser après git init : création du dépôt, indexation des modifications, validation des snapshots et publication vers un remote. Le tableau compare l'intention de chaque commande avec un exemple d'usage pour un dépôt local standard.

Git Fetch vs Git Pull : quelle différence ?

Dans un workflow de gestion de versions décentralisé, git fetch et git pull servent à synchroniser avec un dépôt distant mais avec des conséquences différentes. git fetch télécharge les objets et met à jour les branches de suivi à distance sans modifier les branches locales, ce qui permet d'inspecter les changements avant intégration. git pull effectue par défaut un fetch suivi d'une opération de fusion ou de rebase et applique immédiatement les modifications sur la branche courante. Pour un tutoriel git débutant, privilégier git fetch avant de décider de la stratégie d'intégration réduit les risques de conflits inattendus.

Différence entre git fetch et git pull

• git fetch : récupère les commits distants vers les branches de suivi sans toucher à la branche courante.
• git pull : combine fetch + merge (ou rebase) et met à jour la branche locale, ce qui peut nécessiter une résolution de conflits immédiate.

Résolution de conflits et synchronisation

Lors d'une synchronisation (par exemple après un git pull), des conflits surviennent si des modifications concurrentes touchent les mêmes portions de code. La procédure standard consiste à diagnostiquer les fichiers en conflit avec git status, éditer les marqueurs de conflit, tester les corrections localement puis finaliser la résolution par git add et git commit (ou git rebase --continue si vous êtes en rebase). Avant toute opération destructrice, conservez une copie du dépôt local et coordonnez la réécriture d'historique avec les autres contributeurs.

Résolution des conflits de fusion

Procédure pas à pas pour une résolution manuelle après un git pull infructueux :

1. Exécuter git status pour identifier les fichiers marqués "both modified".
2. Ouvrir chaque fichier en conflit et rechercher les marqueurs (<<<<<<, =======, >>>>>>), puis éditer pour conserver la version correcte ou fusionner manuellement les contenus.
3. Tester localement les modifications compilables ou les suites de tests automatisés.
4. Valider la résolution : git add <fichier> pour chaque fichier résolu, puis git commit (ou git rebase --continue).
5. Si nécessaire, utiliser git mergetool pour une interface d'aide à la fusion ou git reset --hard pour annuler des modifications non désirées (avec précaution).

# Exemple minimal : résoudre puis valider
git status
# modifier les fichiers signalés
git add fichier_conflit.c
git commit -m "Résolution des conflits de fusion"

Manipulation des fichiers et de l'index Git

Comprendre l'impact des opérations sur le système de fichiers et sur l'index évite les erreurs courantes lors du déplacement ou de la suppression de fichiers suivis. Utiliser les commandes dédiées met à jour l'index et le répertoire de travail de façon cohérente.

Gestion des fichiers : git rm et git mv

git rm supprime un fichier du répertoire de travail et de l'index (ou uniquement de l'index avec --cached), tandis que git mv réalise un renommage/déplacement en une seule opération (équivalent d'un mv suivi d'un git add et git rm). Ces commandes facilitent le suivi des modifications et conservent l'historique lisible.

# Supprimer un fichier du dépôt et du disque
git rm fichier_obsolete.txt
git commit -m "Supprime fichier_obsolete.txt"

# Renommer un fichier et mettre à jour l'index
git mv ancien_nom.c nouveau_nom.c
git commit -m "Renommage ancien_nom.c => nouveau_nom.c"

Bonnes pratiques Git en équipe

• Nommage des branches : privilégier des préfixes explicites (feature/, fix/, hotfix/, chore/) et inclure un identifiant d'issue si pertinent (feature/123-ajout-parser).
• Messages de commit : utiliser l'impératif pour le titre, limiter le sujet à ~50 caractères, laisser une ligne vide avant un corps explicatif et référencer les issues ou tickets.
• Conventional Commits : adopter un standard (ex. Conventional Commits) facilite l'automatisation (CI, changelogs) et la lecture de l'historique.
• Petits commits atomiques : préférez des commits ciblés et testés plutôt que des gros commits multifonctions.

Bonnes pratiques de workflow collaboratif

Pour un workflow git collaboratif efficace, séparez les responsabilités entre branches locales et branches partagées, publiez fréquemment via git push et récupérez les changements avec git fetch suivi d'une révision avant git merge. Favorisez les demandes de fusion (pull/merge requests) pour revue de code, exécutez la CI sur les branches de feature et documentez la stratégie de fusion (merge vs rebase). Ces pratiques renforcent la traçabilité et réduisent les risques liés à la réécriture d'historique dans un contexte de gestion de versions décentralisée.

Outils graphiques pour la gestion de conflits

L'usage d'outils graphiques accélère la résolution de conflits git et améliore la lisibilité des diffs. git mergetool permet d'ouvrir un outil de fusion configuré (meld, kdiff3, etc.). Les éditeurs modernes comme Visual Studio Code proposent un éditeur de fusion intégré affichant les blocs en conflit et des actions accessibles au clavier. Des clients graphiques tels que GitKraken, Sourcetree ou Fork offrent une vue visuelle de l'historique, des branchements et des conflits, facilitant la navigation et la sélection des modifications à conserver. L'utilisation conjointe d'un outil graphique et de la ligne de commande permet d'équilibrer précision et productivité lors de la résolution de conflits git.

Pourquoi choisir ce cours ?

Rédigé par Régis Briant, Youngseob Kim et Dmitry Khvorostyanov, le contenu combine explications techniques et mises en pratique sur le code CHIMERE, adapté aux développements scientifiques. L'approche pragmatique présente des commandes illustrées, des visualisations avec gitk et des exercices pas à pas relatifs à des dépôts réels pour expérimenter push/pull, résolution de conflits et multi-remote. Les annexes fournissent une fiche de référence et un focus sur la réécriture d'historique utile en production.

Public cible et prérequis

• Public cible : développeurs et ingénieurs travaillant sur projets scientifiques, responsables d'intégration et contributeurs gérant du code Fortran/Makefile en collaboration sur des dépôts partagés.
• Prérequis : maîtrise de la ligne de commande Unix, connaissance pratique des commandes de base (git init, git add, git commit, git branch) et accès à un environnement shell pour exécuter les exercices.

Foire Aux Questions (FAQ)

Quand privilégier git rebase plutôt que git merge ?

Le rebase produit un historique linéaire, facilitant la lecture de l'arbre de développement et l'usage de git bisect. Attention : rebase réécrit l'historique partagé et doit être évité sur des branches déjà publiées sans coordination avec les autres contributeurs.

Comment récupérer un commit supprimé ou perdu ?

Utilisez git reflog pour retrouver la référence SHA1 du commit perdu, puis restaurez-le avec git checkout <SHA1> pour inspection ou git cherry-pick <SHA1> pour réappliquer les modifications dans une branche. Pour compléter cet apprentissage, consultez les ressources complémentaires listées en fin de document, comme notre cours Programmation en langage Python en PDF (Intermédiaire) ou notre Cours POO en Java en PDF (Avancé).