Alignement avec le nommage des fichiers en anglais

Author: jnavila

A-git-in-other-environments.asc

@@ -11,6 +11,12 @@ include::book/A-git-in-other-environments/sections/guis.asc[]
 
 include::book/A-git-in-other-environments/sections/visualstudio.asc[]
 
+include::book/A-git-in-other-environments/sections/visualstudiocode.asc[]
+
+include::book/A-git-in-other-environments/sections/jetbrainsides.asc[]
+
+include::book/A-git-in-other-environments/sections/sublimetext.asc[]
+
 include::book/A-git-in-other-environments/sections/bash.asc[]
 
 include::book/A-git-in-other-environments/sections/zsh.asc[]

B-embedding-git-in-your-applications.asc

@@ -12,3 +12,7 @@ include::book/B-embedding-git/sections/command-line.asc[]
 include::book/B-embedding-git/sections/libgit2.asc[]
 
 include::book/B-embedding-git/sections/jgit.asc[]
+
+include::book/B-embedding-git/sections/go-git.asc[]
+
+include::book/B-embedding-git/sections/dulwich.asc[]

C-git-commands.asc

@@ -53,7 +53,7 @@ image::images/git-osx-installer.png[installateur de Git pour macOS]
 
 Vous pouvez aussi l'installer comme sous-partie de l'installation de GitHub pour macOS.
 Leur outil Git graphique a une option pour installer les outils en ligne de commande.
-Vous pouvez télécharger cet outil depuis le site web de GitHub pour macOS, à http://mac.github.com[].
+Vous pouvez télécharger cet outil depuis le site web de GitHub pour macOS, à https://desktop.github.com[].
 
 ==== Installation sur Windows
 

book/01-introduction/sections/installing.asc

@@ -72,7 +72,7 @@ Il est très difficile de faire réaliser au système des actions qui ne soient
 Par contre, comme dans la plupart des systèmes de gestion de version, vous pouvez perdre ou corrompre des modifications qui n'ont pas encore été entrées en base ; mais dès que vous avez validé un instantané dans Git, il est très difficile de le perdre, spécialement si en plus vous synchronisez votre base de données locale avec un dépôt distant.
 
 Cela fait de l'usage de Git un vrai plaisir, car on peut expérimenter sans danger de casser définitivement son projet.
-Pour une information plus approfondie sur la manière dont Git stocke ses données et comment récupérer des données qui pourraient sembler perdues, référez-vous à <<ch02-git-basics#s_undoing>>.
+Pour une information plus approfondie sur la manière dont Git stocke ses données et comment récupérer des données qui pourraient sembler perdues, référez-vous à <<ch02-git-basics-chapter#s_undoing>>.
 
 ==== Les trois états
 
@@ -107,4 +107,4 @@ L'utilisation standard de Git se passe comme suit :
 Si une version particulière d'un fichier est dans le répertoire Git, il est considéré comme validé.
 S'il est modifié mais a été ajouté dans la zone d'index, il est indexé.
 S'il a été modifié depuis le dernier instantané mais n'a pas été indexé, il est modifié.
-Dans <<ch02-git-basics#ch02-git-basics>>, vous en apprendrez plus sur ces états et comment vous pouvez en tirer parti ou complètement occulter la phase d'indexation.
+Dans <<ch02-git-basics-chapter#ch02-git-basics-chapter>>, vous en apprendrez plus sur ces états et comment vous pouvez en tirer parti ou complètement occulter la phase d'indexation.

book/01-introduction/sections/what-is-git.asc

@@ -59,7 +59,7 @@ Si vous souhaitez obtenir une copie d'un dépôt Git existant — par exemple,
 Si vous êtes familier avec d'autres systèmes de gestion de version tels que Subversion, vous noterez que la commande est `clone` et non `checkout`.
 C'est une distinction importante — Git reçoit une copie de quasiment toutes les données dont le serveur dispose.
 Toutes les versions de tous les fichiers pour l'historique du projet sont téléchargées quand vous lancez `git clone`.
-En fait, si le disque du serveur se corrompt, vous pouvez utiliser n'importe quel clone pour remettre le serveur dans l'état où il était au moment du clonage (vous pourriez perdre quelques paramètres du serveur, mais toutes les données sous gestion de version seraient récupérées — cf. <<ch04-git-server#s_git_on_the_server>> pour de plus amples détails).
+En fait, si le disque du serveur se corrompt, vous pouvez utiliser n'importe quel clone pour remettre le serveur dans l'état où il était au moment du clonage (vous pourriez perdre quelques paramètres du serveur, mais toutes les données sous gestion de version seraient récupérées — cf. <<ch04-git-on-the-server#s_git_on_the_server>> pour de plus amples détails).
 
 Vous clonez un dépôt avec `git clone [url]`.(((commandes git, clone)))
 Par exemple, si vous voulez cloner la bibliothèque logicielle Git appelée libgit2, vous pouvez le faire de la manière suivante :
@@ -83,4 +83,4 @@ Cette commande réalise la même chose que la précédente, mais le répertoire
 
 Git dispose de différents protocoles de transfert que vous pouvez utiliser.
 L'exemple précédent utilise le protocole `https://`, mais vous pouvez aussi voir `git://` ou `utilisateur@serveur:/chemin.git`, qui utilise le protocole de transfert SSH.
-<<ch04-git-server#s_git_on_the_server>> introduit toutes les options disponibles pour mettre en place un serveur Git, ainsi que leurs avantages et inconvénients.
+<<ch04-git-on-the-server#s_git_on_the_server>> introduit toutes les options disponibles pour mettre en place un serveur Git, ainsi que leurs avantages et inconvénients.

book/02-git-basics/sections/getting-a-repository.asc

@@ -426,7 +426,7 @@ Cette action lance votre éditeur choisi.
 
 [NOTE]
 ====
- Ceci est paramétré par la variable d'environnement `EDITOR` de votre shell — habituellement vim ou Emacs, mais vous pouvez le paramétrer spécifiquement pour Git en utilisant la commande `git config --global core.editor` comme nous l'avons vu au <<ch01-introduction#ch01-introduction>>).(((éditeur, changer par défaut)))(((commandes git, config)))
+ Ceci est paramétré par la variable d'environnement `EDITOR` de votre shell — habituellement vim ou Emacs, mais vous pouvez le paramétrer spécifiquement pour Git en utilisant la commande `git config --global core.editor` comme nous l'avons vu au <<ch01-getting-started#ch01-getting-started>>).(((éditeur, changer par défaut)))(((commandes git, config)))
 ====
 
 L'éditeur affiche le texte suivant (par exemple, ici Vim) :

book/02-git-basics/sections/recording-changes.asc

@@ -67,7 +67,7 @@ origin    [email protected]:mojombo/grit.git (push)
 Cela signifie que vous pouvez facilement tirer les contributions de tous ces utilisateurs.
 Nous pouvons de plus avoir les permissions en poussée sur certain d'entre eux, bien qu'on ne puisse pas le dire ici.
 
-Notez que ces dépôts distants sont accessibles au moyen de différents protocoles ; nous traiterons des protocoles au chapitre <<ch04-git-server#s_git_on_the_server>>.
+Notez que ces dépôts distants sont accessibles au moyen de différents protocoles ; nous traiterons des protocoles au chapitre <<ch04-git-on-the-server#s_git_on_the_server>>.
 
 ==== Ajouter des dépôts distants
 

book/02-git-basics/sections/remotes.asc

@@ -158,7 +158,7 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number
 a11bef0 - Scott Chacon, 6 years ago : first commit
 ----
 
-<<ch02-git-basics#pretty_format>> liste les options de formatage les plus utiles.
+<<ch02-git-basics-chapter#pretty_format>> liste les options de formatage les plus utiles.
 
 [[pretty_format]]
 .Options utiles pour `git log --pretty=format`
@@ -208,7 +208,7 @@ $ git log --pretty=format:"%h %s" --graph
 Ces options deviendront plus intéressantes quand nous aborderons les branches et les fusions dans le prochain chapitre.
 
 Les options ci-dessus ne sont que des options simples de format de sortie de `git log` — il y en a de nombreuses autres.
-<<ch02-git-basics#s_log_options>> donne une liste des options que nous avons traitées ainsi que d'autres options communément utilisées accompagnées de la manière dont elles modifient le résultat de la commande `log`.
+<<ch02-git-basics-chapter#s_log_options>> donne une liste des options que nous avons traitées ainsi que d'autres options communément utilisées accompagnées de la manière dont elles modifient le résultat de la commande `log`.
 
 [[s_log_options]]
 .Options usuelles de `git log`

book/02-git-basics/sections/viewing-history.asc

@@ -3,13 +3,13 @@
 
 Pour réellement comprendre la manière dont Git gère les branches, nous devons revenir en arrière et examiner de plus près comment Git stocke ses données.
 
-Si vous vous souvenez bien du chapitre <<ch01-introduction#ch01-introduction>>, Git ne stocke pas ses données comme une série de modifications ou de différences successives mais plutôt comme une série d'instantanés (appelés _snapshots_).
+Si vous vous souvenez bien du chapitre <<ch01-getting-started#ch01-getting-started>>, Git ne stocke pas ses données comme une série de modifications ou de différences successives mais plutôt comme une série d'instantanés (appelés _snapshots_).
 
 Lorsque vous faites un commit, Git stocke un objet _commit_ qui contient un pointeur vers l'instantané (_snapshot_) du contenu que vous avez indexé.
 Cet objet contient également les noms et prénoms de l'auteur, le message que vous avez renseigné ainsi que des pointeurs vers le ou les _commits_ qui précèdent directement ce _commit_ : aucun parent pour le _commit_ initial, un parent pour un _commit_ normal et de multiples parents pour un _commit_ qui résulte de la fusion d'une ou plusieurs branches.
 
 Pour visualiser ce concept, supposons que vous avez un répertoire contenant trois fichiers que vous indexez puis validez.
-L'indexation des fichiers calcule une empreinte (_checksum_) pour chacun (via la fonction de hachage SHA-1 mentionnée au chapitre <<ch01-introduction#ch01-introduction>>), stocke cette version du fichier dans le dépôt Git (Git les nomme _blobs_) et ajoute cette empreinte à la zone d'index (_staging area_) :
+L'indexation des fichiers calcule une empreinte (_checksum_) pour chacun (via la fonction de hachage SHA-1 mentionnée au chapitre <<ch01-getting-started#ch01-getting-started>>), stocke cette version du fichier dans le dépôt Git (Git les nomme _blobs_) et ajoute cette empreinte à la zone d'index (_staging area_) :
 
 [source,console]
 ----