Merge pull request #155 from hjonin/fix/typos

Corrrectifs mineurs (formatage et nommage)

Author: jnavila

book/02-git-basics/sections/recording-changes.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-getting-started#ch01-getting-started>>).(((é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/03-git-branching/sections/basic-branching-and-merging.asc

@@ -76,15 +76,15 @@ C'est un point important à garder en mémoire : quand vous changez de branche,
 Il ajoute, retire et modifie automatiquement les fichiers de manière à s'assurer que votre copie de travail soit identique à ce qu'elle était lors de votre dernier _commit_ sur cette branche.
 
 Vous avez ensuite un correctif à faire.
-Pour ce faire, créons une branche `correctif` sur laquelle travailler jusqu'à résolution du problème :
+Pour ce faire, créons une branche `hotfix` sur laquelle travailler jusqu'à résolution du problème :
 
 [source,console]
 ----
-$ git checkout -b correctif
-Switched to a new branch 'correctif'
+$ git checkout -b hotfix
+Switched to a new branch 'hotfix'
 $ vim index.html
 $ git commit -a -m "correction de l'adresse email incorrecte"
-[correctif 1fb7853] "correction de l'adresse email incorrecte"
+[hotfix 1fb7853] "correction de l'adresse email incorrecte"
  1 file changed, 2 insertions(+)
 ----
 
@@ -97,7 +97,7 @@ Vous réalisez ceci au moyen de la commande `git merge` :
 [source,console]
 ----
 $ git checkout master
-$ git merge correctif
+$ git merge hotfix
 Updating f42c576..3a0874c
 Fast-forward
  index.html | 2 ++
@@ -110,17 +110,17 @@ Autrement dit, lorsque l'on cherche à fusionner un _commit_ qui peut être atte
 
 Votre modification est maintenant dans l'instantané (_snapshot_) du _commit_ pointé par la branche `master` et vous pouvez déployer votre correctif.
 
-.Avancement du pointeur de `master` sur `correctif`
-image::images/basic-branching-5.png[Avancement du pointeur de `master` sur `correctif`]
+.Avancement du pointeur de `master` sur `hotfix`
+image::images/basic-branching-5.png[Avancement du pointeur de `master` sur `hotfix`]
 
 Après le déploiement de votre correctif super-important, vous voilà prêt à retourner travailler sur le sujet qui vous occupait avant l'interruption.
-Cependant, vous allez avant cela effacer la branche `correctif` dont vous n'avez plus besoin puisque la branche `master` pointe au même endroit.
+Cependant, vous allez avant cela effacer la branche `hotfix` dont vous n'avez plus besoin puisque la branche `master` pointe au même endroit.
 Vous pouvez l'effacer avec l'option `-d` de la commande `git branch` :
 
 [source,console]
 ----
-$ git branch -d correctif
-Deleted branch correctif (3a0874c).
+$ git branch -d hotfix
+Deleted branch hotfix (3a0874c).
 ----
 
 Maintenant, vous pouvez retourner travailler sur la branche qui contient vos travaux en cours pour le problème #53 :
@@ -139,15 +139,15 @@ $ git commit -a -m 'Nouveau pied de page terminé [issue 53]'
 .Le travail continue sur `iss53`
 image::images/basic-branching-6.png[Le travail continue sur `iss53`]
 
-Il est utile de noter que le travail réalisé dans la branche `correctif` n'est pas contenu dans les fichiers de la branche `iss53`.
+Il est utile de noter que le travail réalisé dans la branche `hotfix` n'est pas contenu dans les fichiers de la branche `iss53`.
 Si vous avez besoin de les y rapatrier, vous pouvez fusionner la branche `master` dans la branche `iss53` en lançant la commande `git merge master`, ou vous pouvez retarder l'intégration de ces modifications jusqu'à ce que vous décidiez plus tard de rapatrier la branche `iss53` dans `master`.
 
 
 [[s_basic_merging]]
 ==== Fusions (_Merges_)
 
 Supposons que vous ayez décidé que le travail sur le problème #53 était terminé et prêt à être fusionné dans la branche `master`.
-Pour ce faire, vous allez fusionner votre branche `iss53` de la même manière que vous l'avez fait plus tôt pour la branche `correctif`.
+Pour ce faire, vous allez fusionner votre branche `iss53` de la même manière que vous l'avez fait plus tôt pour la branche `hotfix`.
 Tout ce que vous avez à faire est d'extraire la branche dans laquelle vous souhaitez fusionner et lancer la commande `git merge`:
 
 [source,console]
@@ -160,7 +160,7 @@ README |    1 +
 1 file changed, 1 insertion(+)
 ----
 
-Le comportement semble légèrement différent de celui observé pour la fusion précédente de la branche `correctif`.
+Le comportement semble légèrement différent de celui observé pour la fusion précédente de la branche `hotfix`.
 Dans ce cas, à un certain moment, l'historique de développement a divergé.
 Comme le _commit_ sur la branche sur laquelle vous vous trouvez n'est plus un ancêtre direct de la branche que vous cherchez à fusionner, Git doit effectuer quelques actions.
 Dans ce cas, Git réalise une simple fusion à trois sources (_three-way merge_), en utilisant les deux instantanés pointés par les sommets des branches ainsi que leur plus proche ancêtre commun.
@@ -188,7 +188,7 @@ $ git branch -d iss53
 (((fusionner, conflits)))
 Quelques fois, le processus ci-dessus ne se déroule pas aussi bien.
 Si vous avez modifié différemment la même partie du même fichier dans les deux branches que vous souhaitez fusionner, Git ne sera pas capable de réaliser proprement la fusion.
-Si votre résolution du problème #53 a modifié la même section de fichier que le `correctif`, vous obtiendrez un conflit qui ressemblera à ceci :
+Si votre résolution du problème #53 a modifié la même section de fichier que le `hotfix`, vous obtiendrez un conflit qui ressemblera à ceci :
 
 
 [source,console]

book/03-git-branching/sections/branch-management.asc

@@ -12,7 +12,7 @@ Si vous la lancez sans argument, vous obtenez la liste des branches courantes :
 $ git branch
   iss53
 * master
-  test
+  testing
 ----
 
 Notez le caractère `*` qui préfixe la branche `master` : il indique la branche courante (c'est-à-dire la branche sur laquelle le pointeur `HEAD` se situe).
@@ -24,7 +24,7 @@ Pour visualiser la liste des derniers _commits_ sur chaque branche, vous pouvez
 $ git branch -v
   iss53   93b412c fix javascript issue
 * master  7a98805 Merge branch 'iss53'
-  test 782fd34 add scott to the author list in the readmes
+  testing 782fd34 add scott to the author list in the readmes
 ----
 
 `--merged` et `--no-merged` sont des options très utiles qui permettent de filtrer les branches de cette liste selon que vous les avez ou ne les avez pas encore fusionnées avec la branche courante.
@@ -45,17 +45,17 @@ Pour visualiser les branches qui contiennent des travaux qui n'ont pas encore é
 [source,console]
 ----
 $ git branch --no-merged
-  test
+  testing
 ----
 
 Ceci affiche votre autre branche.
 Comme elle contient des modifications qui n'ont pas encore été intégrées, essayer de les supprimer par la commande `git branch -d` se solde par un échec :
 
 [source,console]
 ----
-$ git branch -d test
-error: The branch 'test' is not fully merged.
-If you are sure you want to delete it, run 'git branch -D test'.
+$ git branch -d testing
+error: The branch 'testing' is not fully merged.
+If you are sure you want to delete it, run 'git branch -D testing'.
 ----
 
 Si vous souhaitez réellement supprimer cette branche et perdre ainsi le travail réalisé, vous pouvez tout de même forcer la suppression avec l'option `-D`, comme l'indique le message.

book/03-git-branching/sections/nutshell.asc

@@ -117,7 +117,7 @@ $ git commit -a -m 'made a change'
 .La branche HEAD avance à chaque _commit_
 image::images/advance-testing.png[La branche HEAD avance à chaque _commit_]
 
-C'est intéressant parce qu'à présent, votre branche `test` a avancé tandis que la branche `master` pointe toujours sur le _commit_ sur lequel vous étiez lorsque vous avez lancé la commande `git checkout` pour changer de branche.
+C'est intéressant parce qu'à présent, votre branche `testing` a avancé tandis que la branche `master` pointe toujours sur le _commit_ sur lequel vous étiez lorsque vous avez lancé la commande `git checkout` pour changer de branche.
 Retournons sur la branche `master` :
 
 [source,console]
@@ -143,7 +143,7 @@ image::images/checkout-master.png[HEAD est déplacé lors d'un _checkout_]
 Cette commande a réalisé deux actions.
 Elle a remis le pointeur `HEAD` sur la branche `master` et elle a replacé les fichiers de votre répertoire de travail dans l'état du _snapshot_ pointé par `master`.
 Cela signifie aussi que les modifications que vous réalisez à partir de ce point divergeront de l'ancienne version du projet.
-Cette commande annule les modifications réalisées dans la branche `test` pour vous permettre de repartir dans une autre direction.
+Cette commande annule les modifications réalisées dans la branche `testing` pour vous permettre de repartir dans une autre direction.
 
 [NOTE]
 .Changer de branche modifie les fichiers dans votre répertoire de travail

book/03-git-branching/sections/rebasing.asc

@@ -26,7 +26,7 @@ Dans cet exemple, vous lanceriez les commandes suivantes :
 
 [source,console]
 ----
-$ git checkout experience
+$ git checkout experiment
 $ git rebase master
 First, rewinding head to replay your work on top of it...
 Applying: added staged command
@@ -63,9 +63,9 @@ Rebaser rejoue les modifications d'une ligne de _commits_ sur une autre dans l'o
 
 Vous pouvez aussi faire rejouer votre rebasage sur autre chose qu'une branche.
 Prenez un historique tel que <<ch03-git-branching#rbdiag_e>> par exemple.
-Vous avez créé une branche thématique (`serveur`) pour ajouter des fonctionnalités côté serveur à votre projet et avez réalisé un _commit_.
+Vous avez créé une branche thématique (`server`) pour ajouter des fonctionnalités côté serveur à votre projet et avez réalisé un _commit_.
 Ensuite, vous avez créé une branche pour ajouter des modifications côté client (`client`) et avez validé plusieurs fois.
-Finalement, vous avez rebasculé sur la branche `serveur` et avez réalisé quelques _commits_ supplémentaires.
+Finalement, vous avez rebasculé sur la branche `server` et avez réalisé quelques _commits_ supplémentaires.
 
 
 [[rbdiag_e]]
@@ -77,10 +77,10 @@ Vous pouvez récupérer les modifications du côté client qui ne sont pas sur l
 
 [source,console]
 ----
-$ git rebase --onto master serveur client
+$ git rebase --onto master server client
 ----
 
-Cela signifie en substance "Extraire la branche client, déterminer les patchs depuis l'ancêtre commun des branches `client` et `serveur` puis les rejouer sur `master` ".
+Cela signifie en substance "Extraire la branche client, déterminer les patchs depuis l'ancêtre commun des branches `client` et `server` puis les rejouer sur `master` ".
 C'est assez complexe, mais le résultat est assez impressionnant.
 
 .Rebaser deux branches thématiques l'une sur l'autre
@@ -98,34 +98,34 @@ $ git merge client
 .Avance rapide sur votre branche `master` pour inclure les modifications de la branche client
 image::images/interesting-rebase-3.png[Avance rapide sur votre branche `master` pour inclure les modifications de la branche client]
 
-Supposons que vous décidiez de tirer (_pull_) votre branche `serveur` aussi.
-Vous pouvez rebaser la branche `serveur` sur la branche `master` sans avoir à l'extraire avant en utilisant `git rebase [branchedebase] [branchethematique]` — qui extrait la branche thématique (dans notre cas, `serveur`) pour vous et la rejoue sur la branche de base (`master`) :
+Supposons que vous décidiez de tirer (_pull_) votre branche `server` aussi.
+Vous pouvez rebaser la branche `server` sur la branche `master` sans avoir à l'extraire avant en utilisant `git rebase [branchedebase] [branchethematique]` — qui extrait la branche thématique (dans notre cas, `server`) pour vous et la rejoue sur la branche de base (`master`) :
 
 [source,console]
 ----
-$ git rebase master serveur
+$ git rebase master server
 ----
 
-Cette commande rejoue les modifications de `serveur` sur le sommet de la branche `master`, comme indiqué dans <<ch03-git-branching#rbdiag_h>>.
+Cette commande rejoue les modifications de `server` sur le sommet de la branche `master`, comme indiqué dans <<ch03-git-branching#rbdiag_h>>.
 
 [[rbdiag_h]]
-.Rebasage de la branche serveur sur le sommet de la branche `master`
-image::images/interesting-rebase-4.png[Rebasage de la branche serveur sur le sommet de la branche `master`]
+.Rebasage de la branche server sur le sommet de la branche `master`
+image::images/interesting-rebase-4.png[Rebasage de la branche server sur le sommet de la branche `master`]
 
 Vous pouvez ensuite faire une avance rapide sur la branche de base (`master`) :
 
 [source,console]
 ----
 $ git checkout master
-$ git merge serveur
+$ git merge server
 ----
 
-Vous pouvez effacer les branches `client` et `serveur` une fois que tout le travail est intégré et que vous n'en avez plus besoin, éliminant tout l'historique de ce processus, comme visible sur <<ch03-git-branching#rbdiag_i>> :
+Vous pouvez effacer les branches `client` et `server` une fois que tout le travail est intégré et que vous n'en avez plus besoin, éliminant tout l'historique de ce processus, comme visible sur <<ch03-git-branching#rbdiag_i>> :
 
 [source,console]
 ----
 $ git branch -d client
-$ git branch -d serveur
+$ git branch -d server
 ----
 
 [[rbdiag_i]]
@@ -190,12 +190,12 @@ Ceci est appelé un "identifiant de patch" (_patch-id_).
 
 Si vous tirez des travaux qui ont été réécrits et les rebasez au-dessus des nouveaux _commits_ de votre collègue, Git peut souvent déterminer ceux qui sont uniquement les vôtres et les réappliquer au sommet de votre nouvelle branche.
 
-Par exemple, dans le scénario précédent, si au lieu de fusionner quand nous étions à l'étape <<ch03-git-branching#s_pre_merge_rebase_work>> nous exécutons la commande  `git rebase equipe1/master`, Git va :
+Par exemple, dans le scénario précédent, si au lieu de fusionner quand nous étions à l'étape <<ch03-git-branching#s_pre_merge_rebase_work>> nous exécutons la commande  `git rebase teamone/master`, Git va :
 
 * Déterminer quels travaux sont uniques à notre branche (C2, C3, C4, C6, C7)
 * Déterminer ceux qui ne sont pas des _commits_ de fusion (C2, C3, C4)
 * Déterminer ceux qui n'ont pas été réécrits dans la branche de destination (uniquement C2 et C3 puisque C4 est le même _patch_ que C4')
-* Appliquer ces _commits_ au sommet de `equipe1/master`
+* Appliquer ces _commits_ au sommet de `teamone/master`
 
 Ainsi, au lieu du résultat que nous avons observé au chapitre <<ch03-git-branching#s_merge_rebase_work>>, nous aurions pu finir avec quelque chose qui ressemblerait davantage à <<ch03-git-branching#s_rebase_rebase_work>>.