Fixing a lot basic.html, and little other files

git · humboldtux · Mar 20, 2014 · Dec 30, 2015 · Jan 8, 2016 · Jan 8, 2016
commit 822bcb3a49d915f8ee8496db9a7de2d2a3750cde
diff --git a/fr/basic/index.html b/fr/basic/index.html
diff --git a/fr/branching/index.html b/fr/branching/index.html
diff --git a/fr/creating/index.html b/fr/creating/index.html
@@ -3,7 +3,7 @@
 ---
 
 <div class="box">
-  <h2>Récupérer et Créer des Projets</h2>
+  <h2>Obtention et Création des Projets</h2>
   <div class="block">
     <p>
       Pour pouvoir faire quoi que ce soit avec Git, vous devez
@@ -14,7 +14,7 @@ <h2>Récupérer et Créer des Projets</h2>
     <p>
       Il y a deux moyens d'avoir un dépôt Git. Le premier est de simplement
       en initialiser un depuis un dossier existant, comme un nouveau projet
-      ou un projet débutant sa gestion de révisions. Le second est de cloner
+      ou un projet débutant sa gestion de versions. Le second est de cloner
       un dépôt public Git, comme vous le feriez si vous vouliez une copie
       ou si vous vouliez collaborer avec quelqu'un sur un projet. Nous allons
       aborder chacun de ces cas.
@@ -27,17 +27,17 @@ <h2>Récupérer et Créer des Projets</h2>
   <h2>
     <span class="docs">
       <a target="new" href="http://git-scm.com/docs/git-init">docs</a> &nbsp;
-      <a target="new" href="http://git-scm.com/book/fr/v2/Les-bases-de-Git-D%C3%A9marrer-un-d%C3%A9p%C3%B4t-Git#Initialisation-d’un-dépôt-Git-dans-un-répertoire-existant">book</a>
+      <a target="new" href="http://git-scm.com/book/fr/v2/Les-bases-de-Git-D%C3%A9marrer-un-d%C3%A9p%C3%B4t-Git#Initialisation-d’un-dépôt-Git-dans-un-répertoire-existant">livre</a>
     </span>
     <a name="init">git init</a>
-    <span class="desc">initialiser un répertoire comme dépôt Git</span>
+    <span class="desc">initialise un répertoire comme dépôt Git</span>
   </h2>
 
   <div class="block">
     <p>Pour créer un dépôt à partir d'un répertoire de fichiers existant,
       vous pouvez simplement faire <code>git init</code> dans ce répertoire.
       Par exemple, disons que nous avons un répertoire comprenant quelques fichiers,
-      ressemblant à:
+      ressemblant à :
     </p>
 
 <pre>
@@ -47,7 +47,7 @@ <h2>
 </pre>
 
     <p>C'est un projet dans lequel nous écrivons des exemples de programmes
-      "Hello World" dans chaque langage. Pour l'instant, nous avons simplement Ruby,
+      « Hello World » dans chaque langage. Pour l'instant, nous avons simplement Ruby,
       mais ce n'est qu'un début. Pour commencer à en gérer les versions avec Git,
       nous pouvons simplement lancer <code>git init</code>.
     </p>
@@ -83,10 +83,10 @@ <h2>
   <h2>
     <span class="docs">
       <a target="new" href="http://git-scm.com/docs/git-clone">docs</a> &nbsp;
-      <a target="new" href="http://git-scm.com/book/fr/v2/Les-bases-de-Git-D%C3%A9marrer-un-d%C3%A9p%C3%B4t-Git#Cloner-un-dépôt-existant">book</a>
+      <a target="new" href="http://git-scm.com/book/fr/v2/Les-bases-de-Git-D%C3%A9marrer-un-d%C3%A9p%C3%B4t-Git#Cloner-un-dépôt-existant">livre</a>
     </span>
     <a name="clone">git clone</a>
-    <span class="desc">copier un dépôt git pour pouvoir le modifier</span>
+    <span class="desc">copie un dépôt git pour pouvoir le modifier</span>
   </h2>
   <div class="block">
     <p>
@@ -129,7 +129,7 @@ <h2>
 
     <p>
       Par défaut, Git crée un dossier avec le même nom que le projet de l'URL
-      donnée - typiquement tout ce qui se trouve après le dernier slash de l'URL.
+      donnée—typiquement tout ce qui se trouve après le dernier slash de l'URL.
       Si vous voulez quelque chose de différent, vous pouvez l'indiquer à la fin
       de la commande, après l'URL.
     </p>
@@ -142,4 +142,4 @@ <h2>
   </div>
 </div>
 
-<p><a class="page-button next-page" href="/fr/basic">Aller à Bases des Instantanés &#187;</a></p>
+<p><a class="page-button next-page" href="/fr/basic">Aller à Capture d’Instantané Basique &#187;</a></p>
diff --git a/fr/index.html b/fr/index.html
@@ -30,19 +30,20 @@ <h2>Comment penser à la Git</h2>
   <div class="block">
     <p>
       La première chose à comprendre sur Git est qu'il
-      gère les révisions d'une manière totalement différente
+      gère les versions d'une manière totalement différente
       de Subversion ou Perforce ou tout autre gestionnaire de code source
       auquel vous pourriez être habitué. Il est souvent plus simple
       d'apprendre Git en essayant d'oublier toute assertion sur
-      le fonctionnement de la gestion de révisions et d'essayer d'y penser
+      le fonctionnement de la gestion de versions et d'essayer d'y penser
       à la Git.
     </p>
 
     <p>
       Partons de zéro. Imaginons que vous conceviez un nouveau système de gestion
-      de code source. Comment géreriez-vous simplement des révisions avant d'utiliser
-      un outil dédié? Il y a de fortes chances pour que vous ayez fait de simples
-      copies du répertoire de votre projet pour sauvegarder son état à ce moment-là.
+      de code source. Comment gériez-vous simplement différentes versions
+      avant d'utiliser un outil dédié à ça ? Il y a de fortes chances pour que vous ayez
+      fait de simples copies du répertoire de votre projet pour sauvegarder
+      son état à ce moment-là.
     </p>
 
     <pre> $ cp -R project project.bak </pre>
@@ -56,7 +57,7 @@ <h2>Comment penser à la Git</h2>
 
     <p>
       Si vous êtes réellement paranoïaque, vous le ferez peut-être souvent,
-      et vous inclurez la date dans le nom de la sauvegarde:
+      et vous inclurez la date dans le nom de la sauvegarde :
     </p>
 
     <pre> $ cp -R project project.2010-06-01.bak </pre>
@@ -90,7 +91,7 @@ <h2>Comment penser à la Git</h2>
     <p>
       Ceci fonctionne en fait plutôt bien, alors disons que nous désirons
       écrire un outil pour effectuer ce processus basique plus rapidement
-      et plus facilement. Au lieu d'écrire un outil qui crée des révisions
+      et plus facilement. Au lieu d'écrire un outil qui crée des versions
       de chaque fichier individuellement, comme Subversion, nous en écririons
       probablement un qui permettrait de manière plus simple de conserver
       des instantanés de notre projet sans avoir à copier la totalité du
@@ -100,8 +101,8 @@ <h2>Comment penser à la Git</h2>
     <p>
       C'est fondamentalement ce que fait Git. Vous dites à Git de sauvegarder
       un instantané de votre projet avec la commande <code>git commit</code>
-      et il va simplement enregistrer l'état de tous vos fichiers de votre projet
-      à ce moment. Ensuite la plupart des commandes travaille avec ces enregistrements
+      et il va simplement enregistrer l'état de tous les fichiers de votre projet
+      à ce moment. Ensuite la plupart des commandes travaillent avec ces enregistrements
       d'état pour voir comment ils différent ou y récupérer du contenu, etc.
     </p>
 
@@ -116,4 +117,4 @@ <h2>Comment penser à la Git</h2>
   </div>
 </div>
 
-<p><a class="page-button next-page" href="/fr/creating">Aller à Récupérer et Créer des Projets &#187;</a></p>
+<p><a class="page-button next-page" href="/fr/creating">Aller à Obtention et Création des Projets &#187;</a></p>
diff --git a/fr/inspect/index.html b/fr/inspect/index.html
@@ -13,16 +13,16 @@ <h2>
     <p>
       Vous avez désormais plusieurs branches dont vous vous servez pour des
       besoins éphémères, des fonctionnalités durables et autres. Comment
-      vous y retrouver parmi celles-ci? Git a différents outils pour vous
+      vous y retrouver parmi celles-ci ? Git a différents outils pour vous
       aider à savoir où un travail donné a eu lieu, quelles sont les différences
       entre deux branches et bien d'autres choses.
     </p>
 
     <p class="nutshell">
       <b>Pour résumer</b>, vous utilisez <code>git log</code> pour retrouver des
-      validations spécifiques dans l'historique de votre projet - par auteur, date,
+      validations spécifiques dans l'historique de votre projet—par auteur, date,
       contenu et historique. Vous pouvez utiliser <code>git diff</code> pour comparer
-      deux points différents dans votre historique - habituellement pour voir de quelle
+      deux points différents dans votre historique—habituellement pour voir de quelle
       manière deux branches diffèrent ou ce qui a changé entre une version de votre
       logiciel et une autre.
     </p>
@@ -36,13 +36,13 @@ <h2>
       <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Visualiser-l-historique-des-validations#Limiter-la-longueur-de-l'historique">livre</a>
     </span>
     <a name="log">git log</a>
-    <span class="desc">limiter la longueur de l'historique</span>
+    <span class="desc">limite la longueur de l'historique</span>
   </h2>
 
   <div class="block">
     <p>Nous avons déjà vu comment utiliser <code>git log</code> pour comparer
       des branches, en visualisant les validations d'une branche. (Si vous ne vous
-      en souvenez pas, cela ressemble à: <code>git log brancheA ^brancheB</code>).
+      en souvenez pas, cela ressemble à : <code>git log brancheA ^brancheB</code>).
       Cependant, vous pouvez utiliser <code>git log</code> pour rechercher une
       validation spécifique. Ici nous allons nous intéresser à certaines options
       communément utilisées par <code>git log</code>, mais il en existe de très
@@ -51,7 +51,7 @@ <h2>
 
     <h4 id="log-author">
       git log --author
-      <small>rechercher uniquement les validations d'un auteur en particulier</small>
+      <small>recherche uniquement les validations d'un auteur en particulier</small>
     </h4>
 
     <p>
@@ -76,7 +76,7 @@ <h4 id="log-author">
 
     <h4 id="log-date">
       git log --since --before
-      <small>filtrer les validations suivant la date de validation</small>
+      <small>filtre les validations suivant la date de validation</small>
     </h4>
 
     <p>
@@ -86,7 +86,7 @@ <h4 id="log-date">
       et <code>--after</code>. Par exemple, pour voir toutes les validations du projet
       Git d'il y a trois semaines mais après le 18 Avril, vous pourriez exécuter ceci
       (Nous allons aussi utiliser <code>--no-merges</code> pour ignorer les validations
-      de fusion):
+      de fusion) :
     </p>
 
 <pre>
@@ -104,14 +104,14 @@ <h4 id="log-date">
 
     <h4 id="log-grep">
       git log --grep
-      <small>filtrer les validations suivant les messages de validation</small>
+      <small>filtre les validations suivant les messages de validation</small>
     </h4>
 
     <p>
       Vous désireriez peut-être également rechercher les validations avec une certaine
       phrase dans le message de validation. Utilisez <code>--grep</code> pour cela.
       Disons qu'il y a une validation qui portait sur la variable d'environnement P4EDITOR
-      et que vous vouliez vous remémorer à quoi ressemblaient les modificiations - vous
+      et que vous vouliez vous remémorer à quoi ressemblaient les modificiations—vous
       pourriez retrouver cette validation avec <code>--grep</code>.
     </p>
 
@@ -140,8 +140,8 @@ <h4 id="log-grep">
       l'option <code>--format</code>, afin de voir qui est l'auteur de chaque validation.
     </p>
 
-    <p>Si nous recherchons les validations dont le message contient 'p4 depo',
-      nous obtenons ces trois validations:</p>
+    <p>Si nous recherchons les validations dont le message contient « p4 depo »,
+      nous obtenons ces trois validations :</p>
 
 <pre>
 <b>$ git log --grep="p4 depo" --format="%h %an %s"</b>
@@ -152,7 +152,7 @@ <h4 id="log-grep">
 
       <p>Si nous ajoutons l'argument <code>--author=Hausmann</code>,
         au lieu de filtrer les validations de Simon, il va plutôt nous montrer
-        toutes les validations par Simon ou dont le message contient "p4 depo".</p>
+        toutes les validations par Simon ou dont le message contient « p4 depo".</p>
 
 <pre>
 <b>$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"</b>
@@ -172,7 +172,7 @@ <h4 id="log-grep">
 </pre>
 
         <p>Néanmoins, ajouter <code>--all-match</code> va vous retourner les résultats
-          que vous attendez:</p>
+          que vous attendez :</p>
 
 <pre>
 <b>$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match</b>
@@ -181,18 +181,18 @@ <h4 id="log-grep">
 
           <h4 id="log-s">
             git log -S
-            <small>filtrer suivant les changements introduits</small>
+            <small>filtre suivant les changements introduits</small>
           </h4>
 
           <p>
-            Que faire si vos messages de validations sont vraiment mauvais? Ou si
+            Que faire si vos messages de validations sont vraiment mauvais ? Ou si
             vous recherchez quand une fonction a été rajoutée, ou quand des
-            variables ont commencé à être utilisées? Vous pouvez aussi dire à Git
+            variables ont commencé à être utilisées ? Vous pouvez aussi dire à Git
             de rechercher parmi les modifications de chaque validation pour une certaine
             chaîne de caractères. Par exemple, si nous voulions trouver quelles
             validations ont modifié tout ce qui ressemble au nom de function
-            'userformat_find_requirements', nous exécuterions ceci (notez qu'il
-            n'y a pas de '=' entre le '-S' et ce que vous recherchez):
+            « userformat_find_requirements', nous exécuterions ceci (notez qu'il
+            n'y a pas de « = » entre le « -S » et ce que vous recherchez) :
           </p>
 
 <pre>
@@ -217,7 +217,7 @@ <h4 id="log-s">
 
           <h4 id="log-patch">
             git log -p
-            <small>afficher le correctif introduit par chaque validation</small>
+            <small>affiche le correctif introduit par chaque validation</small>
           </h4>
 
           <p>
@@ -278,7 +278,7 @@ <h4 id="log-patch">
 
           <h4 id="log-stat">
             git log --stat
-            <small>afficher un résumé des modifications introduites par chaque validation</small>
+            <small>affiche un résumé des modifications introduites par chaque validation</small>
           </h4>
 
           <p>Si vous trouvez l'option <code>-p</code> trop verbeuse, vous pouvez résumer
@@ -306,7 +306,7 @@ <h4 id="log-stat">
  1 files changed, 1 insertions(+), 1 deletions(-)
 </pre>
 
-            <p>Basiquement les mêmes informations, mais plus succintement - vous pouvez
+            <p>Basiquement les mêmes informations, mais plus succintement—vous pouvez
               toujours les diférences et quelles fichiers ont été modifiés.</p>
 
           </div>
@@ -326,7 +326,7 @@ <h2>
 
             <p>Enfin, pour voir les changements absolus entre deux instantanés de validations,
               vous pouvez utiliser la commande <code>git diff</code>. Ceci est très utilisé
-              principalement dans deux cas - voir en quoi deux branches diffèrent
+              principalement dans deux cas—voir en quoi deux branches diffèrent
               l'une de l'autre et voir ce qui a changé depuis la publication d'une version
               ou tout autre ancien moment donné passé dans l'historique.
               Voyons chacune de ces situations.</p>
@@ -378,16 +378,16 @@ <h2>
 
               <p>Pour comparer deux branches divergentes, néanmoins, vous pouvez exécucter
                 quelque chose de similaire à <code>git diff branchA branchB</code> mais
-                le problème est que cela va faire exactement ce que vous lui demandez
-                - cela va concrétement vous fournir le correctif qui transformerai l'instantané
+                le problème est que cela va faire exactement ce que vous lui
+                demandez—cela va concrètement vous fournir le correctif qui transformerai l'instantané
                 à l'extrémité de la branche brancheA en l'instantané de l'extrémité de la
-                branche brancheB. Cela signifie que si deux branches ont divergé - elles
-                ont pris des directions différentes - cela va occulter toutes les modifications
+                branche brancheB. Cela signifie que si deux branches ont divergé—elles
+                ont pris des directions différentes—cela va occulter toutes les modifications
                 introduites dans brancheA puis ajouter tout ce qui a été introduit dans brancheB.
-                Ce n'est probablement pas ce que vous voulez - vous voulez les changements ajoutés
+                Ce n'est probablement pas ce que vous voulez—vous voulez les changements ajoutés
                 à brancheB qui ne sont pas dans brancheA, vous voulez donc vraiment les différences
                 entre là où les deux branches ont divergé et l'extrémité de brancheB. Donc,
-                si notre historique ressemble à ça:</p>
+                si notre historique ressemble à ça :</p>
 
 <pre>
 <b>$ git log --graph --oneline --decorate --all</b>
@@ -399,8 +399,8 @@ <h2>
 ...
 </pre>
 
-                <p>Et si nous voulions voir ce qui se trouve sur la branche "erlang" 
-                  par rapport à la branche "master", exécuter <code>git diff master erlang</code>
+                <p>Et si nous voulions voir ce qui se trouve sur la branche « erlang »
+                  par rapport à la branche « master », exécuter <code>git diff master erlang</code>
                   ne nous afficherait pas la bonne chose.</p>
 
 <pre>
@@ -415,9 +415,9 @@ <h2>
                     que nous avons fait dans cette branche, mais la sortie revient aussi sur les
                     changements du fichier ruby que nous avons effetués dans la branche master.
                     Ce que nous voulons vraiment voir sont juste les changements qui ont été faits
-                    dans la branche "erlang" (l'ajout des deux fichiers). Nous pouvons obtenir le
+                    dans la branche « erlang » (l'ajout des deux fichiers). Nous pouvons obtenir le
                     résultat attendu en faisant la différence entre la validation commune de laquelle
-                    elles ont divergé:</p>
+                    elles ont divergé :</p>
 
 <pre>
 <b>$ git diff --stat 8d585ea erlang</b>
@@ -431,7 +431,7 @@ <h2>
                       Heureusement, Git a un raccourci pour ça. Si vous exécutez
                       <code>git diff master...erlang</code> (avec trois points entre les noms de
                       branches), Git va automatiquement savoir quelle est la validation commune
-                      (aussi connue sous le nom de "base de fusion") entre les deux validations et
+                      (aussi connue sous le nom de « base de fusion") entre les deux validations et
                       afficher les modifications en se basant sur celle-ci.</p>
 
 <pre>
@@ -453,15 +453,15 @@ <h2>
 
                       <p>En guise de bonus, vous pouvez aussi faire calculer manuellement par Git quelle
                         serait la base de fusion (la première validation ancêtre commune) entre deux validations
-                        avec la commande <code>git merge-base</code>:</p>
+                        avec la commande <code>git merge-base</code> :</p>
 
 <pre>
 <b>$ git merge-base master erlang</b>
 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
 </pre>
 
                         <p>Vous pouvez faire l'équivalent de <code>git diff master...erlang</code>
-                          en exécutant:</p>
+                          en exécutant :</p>
 
 <pre>
 <b>$ git diff --stat $(git merge-base master erlang) erlang</b>
@@ -484,5 +484,5 @@ <h2>
                         </div>
                       </div>
 
-                      <p>Et c'est la fin! Pour plus d'informations, essayez de lire le
+                      <p>Et c'est la fin ! Pour plus d'informations, essayez de lire le
                         <a href="http://git-scm.com/book/fr/">Livre Pro Git</a>.</p>