Contrôle de version
Git enregistre les versions des fichiers pour comparer les modifications, travailler sur des branches et retrouver du travail sauvegardé. Il est distribué : un clone complet ordinaire récupère l’historique du projet, permettant commits et comparaisons en local sans réseau. Un clone superficiel omet volontairement l’historique ancien ; un clone partiel peut différer le téléchargement de certains objets.
GitHub, GitLab et des services similaires hébergent les dépôts Git et ajoutent pull requests, suivi des tickets, contrôle d’accès et automatisation. Git fonctionne sans eux. L’introduction de Pro Git explique cette distinction.
Les trois états locaux
Créez un nouveau répertoire d’exercice dans un terminal compatible avec Bash. Les commandes de commit supposent que votre nom d’auteur et votre adresse électronique sont déjà configurés dans Git.
mkdir git-color-practice
cd git-color-practice
git init
printf 'blue\n' > color.txt
git add color.txt
git commit -m "Save blue"
printf 'green\n' > color.txt
git add color.txt
printf 'red\n' > color.txt
Arrêtez-vous ici. Le même fichier existe maintenant en trois versions :
git add a copié le contenu du fichier dans l’index au moment de son exécution. La modification suivante n’a pas mis cet index à jour. Quelle couleur un simple git commit enregistrera-t-il maintenant ? Que compareront git diff et git diff --staged ?
Voir la réponse et les extraits de différences
Le commit enregistrera green, pas red. git diff compare l’arbre de travail à l’index :
@@ -1 +1 @@
-green
+red
git diff --staged compare l’index à HEAD :
@@ -1 +1 @@
-blue
+green
git status --short affiche MM color.txt : le premier M indique une modification préparée, le second une modification non préparée.
Créez maintenant le commit sans relancer git add :
git commit -m "Save green"
git show HEAD:color.txt
cat color.txt
git show affiche green ; cat affiche toujours red. Le commit a enregistré l’index sans toucher à la modification ultérieure dans l’arbre de travail. Pour inclure red dans un prochain commit, préparez à nouveau le fichier.
Au quotidien, le cycle est le suivant :
git status
git diff
git add path/to/file
git diff --staged
git commit -m "Explain the change"
Le premier diff montre ce que vous pouvez préparer ; le diff de l’index montre ce que le commit enregistrera. Les examiner tous deux aide aussi à repérer fichiers générés, secrets et modifications sans rapport.
Branches et dépôts distants
Une branche est un nom mobile pointant vers un commit. Un dépôt distant est une URL nommée désignant un autre dépôt, souvent origin. Le dépôt d’exercice ci-dessus n’a pas encore de dépôt distant configuré ; les commandes distantes suivantes supposent que origin existe et que vous avez le droit d’y pousser.
git switch -c feature/name
git fetch origin
git log --oneline --decorate --graph --all
git push -u origin feature/name
git fetch télécharge l’historique distant et met à jour les références de suivi telles que origin/main, sans modifier l’arbre de travail ni intégrer les changements à votre branche courante. git pull combine fetch et intégration par fusion ou rebasage, selon les options et la configuration. Choisissez ce comportement avant de lancer pull.
Annuler la bonne chose
Avant une opération risquée sur l’historique, une branche ou une étiquette temporaire peut conserver le commit courant, mais pas les modifications préparées ou non préparées. Sauvegardez celles-ci séparément dans un commit ou un stash ; incluez explicitement les fichiers non suivis si nécessaire. Le reflog aide à retrouver de nombreuses anciennes positions de commits locaux, pas n’importe quel contenu de fichier non sauvegardé. La référence Git détaille les options de chaque commande.
Principes de base d’un dépôt
Un dépôt utile comprend généralement un README, une licence lorsque c’est approprié, un fichier .gitignore et une branche par défaut claire. La visibilité, les exigences de revue et les règles de déploiement relèvent du service d’hébergement et de la politique du dépôt ; Git ne les décide pas.