Tutoriel Git en PDF (Avancé)

Git est un système de gestion de version 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 commandes de configuration (~/.gitconfig), des opérations de staging (git add), des commits et de réécriture d'historique (git commit --amend, git rebase) est essentielle pour collaborer sur des projets scientifiques comme CHIMERE. Ce tutoriel est fourni au format PDF gratuit et contient des exercices pratiques prêts à exécuter sur un dépôt réel.

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.

Les 3 zones de Git

• 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 (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.

🎯 Ce que vous allez apprendre

• Configurer Git et l'identité utilisateur — paramétrer le fichier ~/.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.

📑 Sommaire du document

• Configuration et identité
• Gestion des commits et de l'index
• Branches et navigation
• Réécriture d'historique (Rebase/Amend)
• Collaboration et dépôts distants
• Résolution de conflits

🚀 Configuration de votre premier dépôt (git init & clone)

Utilisez git init pour créer un dépôt local dans un projet nouveau ou vide : la commande initialise le répertoire .git et permet d'ajouter ensuite des fichiers à l'index. Préférez git clone <url> lorsque vous récupérez une copie d'un dépôt existant : clone crée une copie complète du dépôt distant, avec les branches et la configuration distante déjà référencée. Le choix dépend donc du point de départ — création ex nihilo ou duplication d'un projet existant — et conditionne l'étape suivante du workflow.

🔧 Workflow collaboratif sur GitHub et GitLab

Pour lier un dépôt local à une plateforme hébergée, exécutez git remote add origin <url>, puis git push -u origin <branche> pour publier la branche initiale. Sur GitHub ou GitLab, privilégiez les branches thématiques et les demandes de fusion (pull/merge requests) pour révision. Synchronisez régulièrement avec git fetch puis git merge ou git pull selon votre stratégie. Ces pratiques facilitent la revue de code, la CI/CD et la traçabilité des contributions dans un workflow multi-contributeurs.

💡 Pourquoi choisir ce cours ?

Ce tutoriel, signé Régis Briant, Youngseob Kim et Dmitry Khvorostyanov, combine explications techniques et mises en pratique sur le code CHIMERE, ce qui le rend 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, conflits et multi-remote. Les annexes fournissent une fiche de référence (aide-mémoire git) et un focus sur la réécriture d'historique (git rebase), utiles pour un usage avancé en production.

👤 À qui s'adresse ce cours ?

• Public cible : développeurs et ingénieurs travaillant sur projets scientifiques (ex. CHIMERE), 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.

Gestion des conflits et collaboration avancée

Les conflits de fusion surviennent lorsque des modifications concurrentes touchent les mêmes lignes ou fichiers lors d'une opération de synchronisation (git pull, git merge ou git rebase). Le diagnostic commence par git status, qui liste les fichiers en conflit, puis l'édition manuelle des fichiers concernés pour conserver ou combiner les changements souhaités. Après résolution, validez l'état avec git add puis terminez par un git commit (ou git rebase --continue si en rebase). En cas d'erreur, git merge --abort ou git rebase --abort permet de revenir à l'état antérieur.

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 de conflit (<<<<<<, =======, >>>>>>), 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"

❓ 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 le 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.