progit · jnavila · Apr 30, 2025 · Mar 28, 2025
diff --git a/C-git-commands.asc b/C-git-commands.asc
@@ -48,7 +48,7 @@ En plus des instructions de configuration dans <<ch01-getting-started#ch_editor>
 .Liste exhaustive de commandes de configuration de  `core.editor`
 [cols="1,2",options="header"]
 |==============================
-|Editeur | Commande de configuration
+|Éditeur | Commande de configuration
 |Atom |`git config --global core.editor "atom --wait"`
 |BBEdit (Mac, with command line tools) |`git config --global core.editor "bbedit -w"`
 |Emacs |`git config --global core.editor emacs`

diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc
@@ -10,7 +10,7 @@ Ces variables peuvent être stockées dans trois endroits différents :
 
 1. `[chemin]/etc/gitconfig` : Contient les valeurs pour tous les utilisateurs et tous les dépôts du système.
   Si vous passez l'option `--system` à `git config`, il lit et écrit ce fichier spécifiquement.
-  Parce que c'est un fichier de configuration au niveau système, vous aurez besoin de privilèges admnistrateur ou super-utilisateur pour le modifier.
+  Parce que c'est un fichier de configuration au niveau système, vous aurez besoin de privilèges administrateur ou super-utilisateur pour le modifier.
 2. Fichier `~/.gitconfig` : Spécifique à votre utilisateur.
   Vous pouvez forcer Git à lire et écrire ce fichier en passant l'option `--global` et cela affecte _tous_ les dépôts avec lesquels vous travaillez sur ce système.
 3. Fichier `config` dans le répertoire Git (c'est-à-dire `.git/config`) du dépôt en cours d'utilisation : spécifique au seul dépôt en cours.

diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc
@@ -3,7 +3,7 @@
 
 (((alias)))
 Avant de clore ce chapitre sur les bases de Git, il reste une astuce qui peut rendre votre apprentissage de Git plus simple, facile ou familier : les alias.
-Nous n'y ferons pas référence ni ne les considèrerons utilisés dans la suite du livre, mais c'est un moyen de facilité qui mérite d'être connu.
+Nous n'y ferons pas référence ni ne les considérerons utilisés dans la suite du livre, mais c'est un moyen de facilité qui mérite d'être connu.
 
 Git ne complète pas votre commande si vous ne la tapez que partiellement.
 Si vous ne voulez pas avoir à taper l'intégralité du texte de chaque commande, vous pouvez facilement définir un alias pour chaque commande en utilisant `git config`.(((commandes git, config)))

diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc
@@ -3,7 +3,7 @@
 
 Vous pouvez principalement démarrer un dépôt Git de deux manières.
 
-1. Vous pouvez prendre un répertoire existant et le transformer en dépot Git.
+1. Vous pouvez prendre un répertoire existant et le transformer en dépôt Git.
 2. Vous pouvez _cloner_ un dépôt Git existant sur un autre serveur.
 
 Dans les deux cas, vous vous retrouvez avec un dépôt Git sur votre machine locale, prêt pour y travailler.

diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc
@@ -5,7 +5,7 @@ Vous devez faire quelques modifications et valider des instantanés de ces modif
 
 Souvenez-vous que chaque fichier de votre copie de travail peut avoir deux états : sous suivi de version ou non suivi.
 Les fichiers suivis sont les fichiers qui appartenaient déjà au dernier instantané ; ils peuvent être inchangés, modifiés ou indexés.
-En résumé, les fichiers suivis sont ceux que Git connait.
+En résumé, les fichiers suivis sont ceux que Git connaît.
 
 Tous les autres fichiers sont non suivis — tout fichier de votre copie de travail qui n'appartenait pas à votre dernier instantané et n'a pas été indexé.
 Quand vous clonez un dépôt pour la première fois, tous les fichiers seront sous suivi de version et inchangés car Git vient tout juste de les extraire et vous ne les avez pas encore édités.
@@ -219,7 +219,7 @@ Renseigner un fichier `.gitignore` avant de commencer à travailler est généra
 Les règles de construction des patrons à placer dans le fichier `.gitignore` sont les suivantes :
 
 * les lignes vides ou commençant par `#` sont ignorées ;
-* les patrons standards de fichiers sont utilisables et seront appliqués recursivement dans tout l'arbre de travail ;
+* les patrons standards de fichiers sont utilisables et seront appliqués récursivement dans tout l'arbre de travail ;
 * si le patron commence par une barre oblique (`/), le patron n'est pas récursif ;
 * si le patron se termine par une barre oblique (`/`), il indique un répertoire ;
 * un patron commençant par un point d'exclamation (`!`) indique des fichiers à inclure malgré les autres règles.

diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc
@@ -140,11 +140,11 @@ $ git log --pretty=oneline
 a6b4c97498bd301d84096da251c98a07c7723e65 Début de l'écriture support
 0d52aaab4479697da7686c15f77a3d64d9165190 Un truc de plus
 6d52a271eda8725415634dd79daabbc4d9b6008e Fusion branche 'experimental'
-0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc ajout d'une fonction de validatn
-4682c3261057305bdd616e23b64b0857d832627b ajout fichier afaire
-166ae0c4d3f420721acbb115cc33848dfcc2121a début de l'ecriture support
+0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc ajout d'une fonction de validation
+4682c3261057305bdd616e23b64b0857d832627b ajout fichier a_faire
+166ae0c4d3f420721acbb115cc33848dfcc2121a début de l'écriture support
 9fceb02d0ae598e95dc970b74767f19372d61af8 mise à jour rakefile
-964f16d36dfccde844893cac5b347e7b3d44abbc validation afaire
+964f16d36dfccde844893cac5b347e7b3d44abbc validation a_faire
 8a5cbc430f1a9c3d00faaeffd07798508422908a mise à jour lisezmoi
 ----
 

diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc
@@ -2,7 +2,7 @@
 === Gestion des branches
 
 (((branches, gestion)))
-Maintenant que vous avez créé, fusionné et supprimé des branches, regardons de plus près les outils de gestion des branches qui s'avèreront utiles lors d'une utilisation intensive des branches.
+Maintenant que vous avez créé, fusionné et supprimé des branches, regardons de plus près les outils de gestion des branches qui se révéleront utiles lors d'une utilisation intensive des branches.
 
 La commande `git branch` permet en fait bien plus que la simple création et suppression de branches.(((commandes git, branche)))
 Si vous la lancez sans argument, vous obtenez la liste des branches courantes :

diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc
@@ -15,8 +15,8 @@ image::images/basic-rebase-1.png[Historique divergeant simple]
 Comme nous l'avons déjà expliqué, le moyen le plus simple pour intégrer ces branches est la fusion via la commande `merge`.
 Cette commande réalise une _fusion à trois branches_ entre les deux derniers instantanés (_snapshots_) de chaque branche (C3 et C4) et l'ancêtre commun le plus récent (C2), créant un nouvel instantané (et un _commit_).
 
-.Fusion pour intégrer des travaux aux historiques divergeants
-image::images/basic-rebase-2.png[Fusion pour intégrer des travaux aux historiques divergeants]
+.Fusion pour intégrer des travaux aux historiques divergeant
+image::images/basic-rebase-2.png[Fusion pour intégrer des travaux aux historiques divergeant]
 
 Cependant, il existe un autre moyen : vous pouvez prendre le _patch_ de la modification introduite en `C4` et le réappliquer sur `C3`.
 Dans Git, cette action est appelée "rebaser" (_rebasing_).

diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc
@@ -148,13 +148,13 @@ Branch correctionserveur set up to track remote branch correctionserveur from or
 Switched to a new branch 'correctionserveur'
 ----
 
-En fait, c'est tellement habituel qu'il y a même un raccourci de ce racccouci.
+En fait, c'est tellement habituel qu'il y a même un raccourci de ce raccourci.
 Si le nom de branche que vous essayez d'extraire (a) n'existe pas et (b) correspond à un seul nom sur un seul distant, Git va créer une branche de suivi pour vous :
 
 [source,console]
 ----
 $ git checkout correctionserveur
-Branch serverfix set up to track remote branch correctionserveur from origin.
+Branch correctionserveur set up to track remote branch correctionserveur from origin.
 Switched to a new branch 'correctionserveur'
 ----
 Pour créer une branche locale avec un nom différent de celui de la branche distante, vous pouvez simplement utiliser la première version avec un nom différent de branche locale :

diff --git a/book/04-git-server/sections/generating-ssh-key.asc b/book/04-git-server/sections/generating-ssh-key.asc
@@ -17,7 +17,7 @@ authorized_keys2  id_dsa       known_hosts
 config            id_dsa.pub
 ----
 
-Recherchez une paire de fichiers appelés _quelquechose_ et _quelquechose_`.pub` où le _quelquechose_ en question est généralement `id_dsa` ou `id_rsa`.
+Recherchez une paire de fichiers appelés _quelque_chose_ et _quelque_chose_`.pub` où le _quelque_chose_ en question est généralement `id_dsa` ou `id_rsa`.
 Le fichier en `.pub` est la clé publique tandis que l'autre est la clé privée.
 Si vous ne voyez pas ces fichiers (ou n'avez même pas de répertoire `.ssh`), vous pouvez les créer en lançant un programme appelé `ssh-keygen` fourni par le paquet SSH sur les systèmes Linux/macOS et MSysGit pour Windows :
 

diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc
@@ -21,7 +21,7 @@ Si vous utilisez un pare-feu, il sera nécessaire de rediriger le port 9418 sur
 
 Transformer ce processus en _daemon_ peut s'effectuer de différentes manières qui dépendent du système d'exploitation sur lequel il est lancé.
 
-Puisque `systemd` est le système d'init le plus habitituel sur les distributions Linux modernes, vous pouvez l'utiliser pour cela.
+Puisque `systemd` est le système d'init le plus habituel sur les distributions Linux modernes, vous pouvez l'utiliser pour cela.
 Placez simplement un fichier `/etc/systemd/system/git-daemon.service` avec le contenu suivant :
 
 [source,console]

diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc
@@ -128,8 +128,8 @@ Clonage dans 'simplegit'...
 ...
 $ cd simplegit/
 $ vim lib/simplegit.rb
-$ git commit -am 'Eliminer une valeur par défaut invalide'
-[master 738ee87] Eliminer une valeur par défaut invalide
+$ git commit -am 'Éliminer une valeur par défaut invalide'
+[master 738ee87] Éliminer une valeur par défaut invalide
  1 files changed, 1 insertions(+), 1 deletions(-)
 -----
 
@@ -261,7 +261,7 @@ commit 738ee872852dfaa9d6634e0dea7a324040193016
 Author: John Smith <jsmith@example.com>
 Date:   Fri May 29 16:01:27 2009 -0700
 
-    Eliminer une valeur par defaut invalide
+    Éliminer une valeur par défaut invalide
 
 -----
 
@@ -485,8 +485,8 @@ Elle valide donc encore et pousse ses changements sur le serveur :
 
 [source,console]
 -----
-$ git commit -am 'details regles'
-[fonctionA ed774b3] details regles
+$ git commit -am 'details règles'
+[fonctionA ed774b3] details règles
  1 files changed, 1 insertions(+), 1 deletions(-)
 $ git push
 ...

diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc
@@ -107,7 +107,7 @@ image::images/scripting-04-webhook-debug.png[Webhook debug]
 
 L'autre fonctionnalité intéressante est que vous pouvez redéclencher la livraison de n'importe quel message pour tester votre service.
 
-Pour plus d'information sur l'écriture de crochets web et tous les différents types d'événement que vous pouvez écouter, rendez-vous à la documentation du Developpeur GitHub à l'adresse https://docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks[].
+Pour plus d'information sur l'écriture de crochets web et tous les différents types d'événement que vous pouvez écouter, rendez-vous à la documentation du Développeur GitHub à l'adresse https://docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks[].
 
 ==== L'interface de programmation (_API_) GitHub
 

diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc
@@ -54,7 +54,7 @@ Voici à quoi ressemblerait un `.gitconfig` si vous utilisiez un fichier d'ident
 ==== Sous le capot
 
 Comment tout ceci fonctionne-t-il ?
-La commande d'origine de Git pour le système d'assistants d'indentification est `git credential`, qui accepte une commande comme argument, puis d'autres informations via stdin.
+La commande d'origine de Git pour le système d'assistants d'identification est `git credential`, qui accepte une commande comme argument, puis d'autres informations via stdin.
 
 Un exemple peut aider à mieux comprendre cela.
 Supposons qu'un assistant d'identification a été configuré et que l'assistant a stocké les identifiants pour `mygithost`.

diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc
@@ -92,7 +92,7 @@ Bisecting: 6 revisions left to test after this
 Git trouve qu'il y a environ 12 _commits_ entre celui que vous avez marqué comme le dernier bon connu (v1.0) et la version courante qui n'est pas bonne, et il a récupéré le _commit_ du milieu à votre place.
 À ce moment, vous pouvez dérouler vos tests pour voir si le bogue existait dans ce _commit_.
 Si c'est le cas, il a été introduit quelque part avant ce _commit_ médian, sinon, il l'a été évidemment après.
-Il apparait que le bogue ne se reproduit pas ici, vous le dites à Git en tapant `git bisect good` et continuez votre périple :
+Il apparaît que le bogue ne se reproduit pas ici, vous le dites à Git en tapant `git bisect good` et continuez votre périple :
 
 [source,console]
 ----

diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc
@@ -1,10 +1,10 @@
 [[s_sect_rerere]]
 === Rerere
 
-La fonctionalité `git rerere` est une fonction un peu cachée.
+La fonctionnalité `git rerere` est une fonction un peu cachée.
 Le nom vient de l'anglais _reuse recorded resolution_ (« _ré_ utiliser les _ré_ solutions en _re_ gistrées ») et comme son nom l'indique, cela permet de demander à Git de se souvenir comment vous avez résolu un conflit sur une section de diff de manière que la prochaine fois qu'il rencontre le même conflit, il le résolve automatiquement pour vous.
 
-Il existe pas mal de scénarios pour lesquels cette fonctionalité peut se montrer efficace.
+Il existe pas mal de scénarios pour lesquels cette fonctionnalité peut se montrer efficace.
 Un exemple mentionné dans la documentation cite le cas d'une branche au long cours qui finira par fusionner proprement mais ne souhaite pas montrer des fusions intermédiaires.
 Avec `rerere` activé, vous pouvez fusionner de temps en temps, résoudre les conflits, puis sauvegarder la fusion.
 Si vous faites ceci en continu, alors la dernière fusion devrait être assez facile parce que `rerere` peut quasiment tout faire automatiquement pour vous.

diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc
@@ -49,7 +49,7 @@ $ git show 1c002dd4b536e7479f
 $ git show 1c002d
 ----
 
-Git peut déterminer une référence SHA-1 tout à la fois la plus courte possible et non ambigüe.
+Git peut déterminer une référence SHA-1 tout à la fois la plus courte possible et non ambiguë.
 Ajoutez l'option `--abbrev-commit` à la commande `git log` et le résultat affiché utilisera des valeurs plus courtes mais uniques ; par défaut Git retiendra 7 caractères et augmentera au besoin :
 
 [source,console]
@@ -83,7 +83,7 @@ Voici un exemple pour vous donner une idée de ce qui pourrait provoquer une col
 Si tous les 6,5 milliards d'humains sur Terre programmaient et que chaque seconde, chacun produisait du code équivalent à l'historique entier du noyau Linux (6,5 millions d'objets Git) et le poussait sur un énorme dépôt Git, cela prendrait 2 ans pour que ce dépôt contienne assez d'objets pour avoir une probabilité de 50 % qu'une seule collision SHA-1 existe.
 Ainsi, une collision organique de SHA-1 est moins probable que tous les membres de votre équipe de programmeurs soient attaqués et tués par des loups dans des incidents sans relation la même nuit.
 
-Si vous y dédiiez plusieurs milliers de dollars de puissance de calcul, il searit possible de synthétiser deux fichiers avec la même empreinte, comme prouvé par https://shattered.io/[] en février 2017.
+Si vous y dédiiez plusieurs milliers de dollars de puissance de calcul, il serait possible de synthétiser deux fichiers avec la même empreinte, comme prouvé par https://shattered.io/[] en février 2017.
 Git évolue vers l'utilisation de SHA256 comme algorithme par défaut d'empreinte, qui est beaucoup plus résilient aux attaques par collision, et a déjà du code en place pour amenuiser cette attaque (bien qu'il ne puisse pas totalement éliminer cette faiblesse)
 ====
 
@@ -366,7 +366,7 @@ $ git log refA refB ^refC
 $ git log refA refB --not refC
 ----
 
-Ceci vous fournit un système de requêtage des révisions très puissant, pour vous aider à saisir ce qui se trouve sur vos branches.
+Ceci vous fournit un système de requête des révisions très puissant, pour vous aider à saisir ce qui se trouve sur vos branches.
 
 [[s_triple_dot]]
 ===== Triple point

diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc
@@ -150,7 +150,7 @@ En complément, vous pouvez configurer `git log` pour vérifier toutes les signa
 $ git log --pretty="format:%h %G? %aN  %s"
 
 5c3386c G Scott Chacon  commit signé
-ca82a6d N Scott Chacon  changed the verison number
+ca82a6d N Scott Chacon  changed the version number
 085bb3b N Scott Chacon  removed unnecessary test code
 a11bef0 N Scott Chacon  first commit
 ----

diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc
@@ -11,7 +11,7 @@ Remiser prend l'état en cours de votre répertoire de travail, c'est-à-dire le
 .Migrer vers `git stash push`
 ====
 Courant fin octobre 2017, il y a eu de longues discussions sur la liste de diffusion Git, pour rendre obsolète la commande `git stash save` au profit de l'alternative existante `git stash push`.
-La raison principale en est que `git stash push` introduit une option pour remiser des _specificateurs de chemin_ sélectionnés, ce que `git stash save` ne sait pas faire.
+La raison principale en est que `git stash push` introduit une option pour remiser des _spécificateurs de chemin_ sélectionnés, ce que `git stash save` ne sait pas faire.
 
 `git stash save` ne va disparaître immédiatement, donc ne vous inquiétez pas.
 Néanmoins il serait préférable de commencer à migrer vers l'alternative `push` pour bénéficier des nouvelles fonctionnalités.

diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc
@@ -434,7 +434,7 @@ nothing to commit, working tree clean
 
 Notez que pour rester en sécurité, vous devriez lancer `git submodule update` avec le drapeau `--init` au cas où les commits de ProjetPrincipal que vous venez de tirer ont ajouté des nouveaux sous-modules, et le drapeau `--recursive` si certains sous-module ont des sous-modules imbriqués.
 
-Si vous souhaitez automatiser ce processsus, vous pouvez ajouter le drapeau `--recurse-submodules` à la commande `git pull` (depuis Git 2.14).
+Si vous souhaitez automatiser ce processus, vous pouvez ajouter le drapeau `--recurse-submodules` à la commande `git pull` (depuis Git 2.14).
 Cela forcera Git à lancer  `git submodule update` juste après le tirage, de manière à mettre à jour les sous-modules dans l'état correct.
 De plus, si vous voulez que Git tire toujours avec `--recurse-submodules`, vous pouvez régler l'option de configuration `submodule.recurse` à true (cela marche pour `git pull` depuis Git 2.15).
 Cette option forcera Git à utiliser le drapeau `--recurse-submodules` pour toutes les commandes qui le supportent (à part `clone`).
@@ -969,7 +969,7 @@ Cela peut être vraiment déroutant, donc c'est toujours une bonne idée de touj
 Pour les versions anciennes de Git qui n'ont pas de drapeau `--recurse-submodules`, après l'extraction, vous pouvez utiliser `git submodule update --init --recursive` pour placer les sous-modules dans le bon état.
 
 Par chance, vous pouvez indiquer à Git (>=2.14) de toujours utiliser le drapeau `--recurse-submodules` en paramétrant l'option de configuration `submodule.recurse` : `git config submodule.recurse true`.
-Comme noté ci-dessus, cela forcera auss Git à parcourir récursivement les sous-modules pour toute commande qui accepte l'option `--recurse-submodules` (excepté `git clone`).
+Comme noté ci-dessus, cela forcera aussi Git à parcourir récursivement les sous-modules pour toute commande qui accepte l'option `--recurse-submodules` (excepté `git clone`).
 
 ===== Basculer d'un sous-répertoire à un sous-module
 

diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc
@@ -172,7 +172,7 @@ Si vous avez fait une faute de frappe en tapant une commande Git, il vous affich
 [source,console]
 ----
 $ git chekcout master
-git : 'chekcout' n'est pas une commande git. Voir 'git --help'.
+git : 'checkout' n'est pas une commande git. Voir 'git --help'.
 
 Vouliez-vous dire cela ?
         checkout
@@ -184,7 +184,7 @@ Si vous positionnez le paramètre `help.autocorrect` à 1, Git va réellement la
 [source,console]
 ----
 $ git chekcout master
-ATTENTION : vous avez invoqué une commande Git nommée 'chekcout' qui n'existe pas.
+ATTENTION : vous avez invoqué une commande Git nommée 'checkout' qui n'existe pas.
 Continuons en supposant que vous avez voulu dire 'checkout'
 dans 0.1 secondes automatiquement...
 ----