diff --git a/_layouts/fr_reference.html b/_layouts/fr_reference.html
new file mode 100755
index 0000000..f707f32
--- /dev/null
+++ b/_layouts/fr_reference.html
@@ -0,0 +1,107 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="content-type" content="text/html; charset=utf-8" />
+ <title>Référence Git</title>
+ <link rel="stylesheet" type="text/css" href="/css/reset.css" media="screen" />
+ <link rel="stylesheet" type="text/css" href="/css/text.css" media="screen" />
+ <link rel="stylesheet" type="text/css" href="/css/grid.css" media="screen" />
+ <link rel="stylesheet" type="text/css" href="/css/layout.css" media="screen" />
+ <link rel="stylesheet" type="text/css" href="/css/nav.css" media="screen" />
+ <!--[if IE 6]><link rel="stylesheet" type="text/css" href="/css/ie6.css" media="screen" /><![endif]-->
+ <!--[if IE 7]><link rel="stylesheet" type="text/css" href="/css/ie.css" media="screen" /><![endif]-->
+ <script type="text/javascript" src="/js/jquery-1.4.1.min.js"></script>
+ <script type="text/javascript" src="/js/jquery-ui.min.js"></script>
+ <script type="text/javascript" src="/js/action.js"></script>
+ </head>
+ <body>
+ <div class="container_12">
+
+ <div class="grid_12">
+ <span id="branding">Référence Git</span>
+ </div>
+
+ <div class="grid_12">
+ <ul id="menu">
+ <li><a id="menu_home" href="/fr/index.html">Référence</a></li>
+ <!-- <li><a id="menu_cookbook" href="/fr/cookbook.html">Cookbook</a></li> -->
+ <li><a id="menu_about" href="/fr/about.html">À Propos</a></li>
+ <li>§</li>
+ <li><a href="https://github.com/git/git-reference">Sources du Site</a></li>
+ </ul>
+ <br/>
+
+ </div>
+
+ <div class="grid_2" id="reflist">
+ <div class="block">
+ <h3><a href="/fr/creating">Obtention et Création des Projets</a></h3>
+ <ul>
+ <li><a href="/fr/creating/#init">init</a></li>
+ <li><a href="/fr/creating/#clone">clone</a></li>
+ </ul>
+ </div>
+
+ <div class="block">
+ <h3><a href="/fr/basic">Capture d’Instantané Basique</a></h3>
+ <ul>
+ <li><a href="/fr/basic/#add">add</a></li>
+ <li><a href="/fr/basic/#status">status</a></li>
+ <li><a href="/fr/basic/#diff">diff</a></li>
+ <li><a href="/fr/basic/#commit">commit</a></li>
+ <li><a href="/fr/basic/#reset">reset</a></li>
+ <li><a href="/fr/basic/#rm-mv">rm, mv</a></li>
+ <li><a href="/fr/basic/#stash">stash</a></li>
+ </ul>
+ </div>
+
+ <div class="block">
+ <h3><a href="/fr/branching">Création de Branches et Fusion</a></h3>
+ <ul>
+ <li><a href="/fr/branching/#branch">branch</a></li>
+ <li><a href="/fr/branching/#branch">checkout</a></li>
+ <li><a href="/fr/branching/#merge">merge</a></li>
+ <li><a href="/fr/branching/#log">log</a></li>
+ <li><a href="/fr/branching/#tag">tag</a></li>
+ </ul>
+ </div>
+
+ <div class="block">
+ <h3><a href="/fr/remotes">Partage et Mise à Jour de Projets</a></h3>
+ <ul>
+ <li><a href="/fr/remotes/#remote">remote</a></li>
+ <li><a href="/fr/remotes/#fetch">fetch, pull</a></li>
+ <li><a href="/fr/remotes/#push">push</a></li>
+ </ul>
+ </div>
+
+ <div class="block">
+ <h3><a href="/fr/inspect">Inspection et Comparaison</a></h3>
+ <ul>
+ <li><a href="/fr/inspect/#log">log</a></li>
+ <li><a href="/fr/inspect/#diff">diff</a></li>
+ </ul>
+ </div>
+
+ <!--
+ <div class="block">
+ <h3><a href="/fr/fixing">Dépannage et Modification de l'Historique</a></h3>
+ <ul>
+ <li><a href="/fr/fixing/rebase.html">rebase</a></li>
+ <li><a href="/fr/fixing/revert.html">revert</a></li>
+ <li><a href="/fr/fixing/checkout.html">checkout</a></li>
+ <li><a href="/fr/fixing/reset.html">reset</a></li>
+ <li><a href="/fr/fixing/cherry-pick.html">cherry-pick</a></li>
+ </ul>
+ </div>
+ -->
+ </div>
+
+ <div class="grid_10 home_box" id="content_box">
+ {{ content }}
+ </div>
+
+ <div class="clear"></div>
+ </div>
+ </body>
+</html>
diff --git a/fr/.gitignore b/fr/.gitignore
new file mode 100644
index 0000000..a16c005
--- /dev/null
+++ b/fr/.gitignore
@@ -0,0 +1,2 @@
+_site
+*~
diff --git a/fr/README.md b/fr/README.md
new file mode 100644
index 0000000..7ea0b58
--- /dev/null
+++ b/fr/README.md
@@ -0,0 +1,18 @@
+# Référence Git, Effort de traduction française #
+
+Ce dépot concerne l'effort de traduction en français du site en ligne
+Référence Git.
+
+## Contribuer
+
+Si vous désirez contribuer, faites simplement un fork du dépôt,
+poussez vos modifications dans une branche et envoyez une requête de tirage.
+
+Corrections typographiques, améliorations grammaticales et de lisibilité, toute
+participation est la bienvenue.
+
+## Références pour la traduction
+
+Les traductions choisies pour les termes spécifiques à Git se basent sur
+[les références](https://github.com/progit/progit2-fr#références-pour-la-traduction)
+de l'effort de traduction en français de la deuxième édition du livre Pro Git.
diff --git a/fr/about.html b/fr/about.html
new file mode 100644
index 0000000..a294fcd
--- /dev/null
+++ b/fr/about.html
@@ -0,0 +1,8 @@
+---
+layout: fr_reference
+---
+<div class="box">
+ <h2>Qui est à l'origine de ce site ?</h2>
+ <br/>
+ <p>Le site Référence Git a été réalisé par l'équipe GitHub.</p>
+</div>
diff --git a/fr/basic/index.html b/fr/basic/index.html
new file mode 100644
index 0000000..1c1497d
--- /dev/null
+++ b/fr/basic/index.html
@@ -0,0 +1,1009 @@
+---
+layout: fr_reference
+---
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t">livre</a>
+ </span>
+ Capture d’Instantané Basique
+ </h2>
+ <div class="block">
+ <p>
+ L'essentiel de Git tient à créer et sauvegarder des instantanés de votre projet
+ pour ensuite utiliser et comparer ces instantanés. Cette section va
+ présenter les commandes nécessaires pour créer et sauvegarder des instantanés
+ de votre projet.
+ </p>
+
+ <p>
+ Un concept important ici est que Git dispose d'un « index », qui se comporte
+ comme une sorte de zone d'attente pour votre instantané. Cela vous permet
+ d'accumuler des séries bien ordonnées d'instantanés à partir de fichiers modifiés
+ de votre dossier de travail, plutôt que de valider toutes les modifications de
+ fichiers d'un coup.
+ </p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>, vous utiliserez <code>git add</code> pour
+ commencer à suivre de nouveaux fichiers et aussi pour préparer la capture
+ des modifications apportées à des fichiers déjà suivis, puis
+ <code>git status</code> et <code>git diff</code> pour voir ce qui a été
+ modifié et préparé pour la capture et finalement <code>git commit</code> pour
+ enregistrer un instantané dans votre historique. Ce sera le flux de travail
+ basique que vous utiliserez la plupart du temps.
+ </p>
+
+ </div>
+</div>
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-add">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t#Placer-de-nouveaux-fichiers-sous-suivi-de-version">livre</a>
+ </span>
+ <a name="add">git add</a>
+ <span class="desc">ajoute le contenu d'un fichier dans la zone d'attente</span>
+ </h2>
+
+ <div class="block">
+ <p>
+ Dans Git, vous devez ajouter le contenu d'un fichier dans la zone d'attente
+ avant de pouvoir le valider. Si c'est un nouveau fichier, vous pouvez
+ exécuter <code>git add</code> pour l'ajouter au préalable à la zone d'attente,
+ mais même si le fichier est déjà « suivi »—en d'autres termes, il fait partie
+ de votre dernière validation—vous devez toujours lancer <code>git add</code>
+ pour ajouter de nouvelles modifications à votre zone d'attente.
+ Voyons quelques exemples.
+ </p>
+
+ <p>Revenons à notre exemple Hello World, une fois initialisé notre projet,
+ nous commencerions alors à y ajouter des fichiers et le ferions avec
+ <code>git add</code>. Nous pouvons utiliser <code>git status</code> pour
+ afficher l'état de notre projet.
+ </p>
+
+<pre>
+<b>$ git status -s</b>
+<span class="red">??</span> README
+<span class="red">??</span> hello.rb
+</pre>
+
+ Nous avons désormais deux fichiers non suivis. Nous pouvons maintenant les ajouter.
+
+<pre>
+<b>$ git add README hello.rb</b>
+</pre>
+
+ Maintenant si nous exécutons <code>git status</code> à nouveau, nous verrions
+ qu'ils ont été ajoutés.
+
+<pre>
+<b>$ git status -s</b>
+<span class="green">A</span> README
+<span class="green">A</span> hello.rb
+</pre>
+
+ <p class="aside">
+ Il est aussi courant d'ajouter récursivement tous les fichiers d'un nouveau projet
+ en indiquant le dossier de travail courant comme suit : <code>git add .</code>.
+ Sachant que Git va ajouter récursivement tous les fichiers dans un dossier que
+ vous lui donnez, si vous lui donnez le répertoire de travail courant, il va
+ simplement faire le suivi de chaque fichier qui s'y trouve. Dans ce cas,
+ la commande <code>git add .</code> aurait donné la même chose que
+ <code>git add README hello.rb</code>.
+ </p>
+
+ <p>OK, à présent si nous éditons un de ces fichiers et exécutons
+ <code>git status</code> à nouveau, nous allons observer
+ un comportement étrange.</p>
+<pre>
+<b>$ vim README</b>
+<b>$ git status -s</b>
+<span class="green">A</span><span class="red">M</span> README
+<span class="green">A</span> hello.rb
+</pre>
+
+ <p>Le statut « AM » signifie que le fichier a été modifié depuis la dernière
+ fois qu'il a été ajouté. Cela signifie que si nous validons notre instantané
+ tout de suite, nous enregistrerions la version du fichier lors de l'exécution
+ précédente de <code>git add</code>, pas la version actuelle. Git ne suppose
+ pas que le fichier dans sa version actuelle est nécessairement celui que vous
+ voulez prendre en instantané—vous devez le préciser à Git avec la commande
+ <code>git add</code>.
+ </p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>,
+ vous exécutez <code>git add</code> sur un fichier lorsque vous voulez inclure
+ toute modification apportée au fichier dans le prochain instantané.
+ Toute modification qui ne sera pas ajoutée ne sera pas incluse dans
+ l'instantané—cela signifie que vous pouvez créer vos instantanés
+ de manière plus fine que dans la plupart des systèmes de gestion
+ de versions.</p>
+
+ <p>Pour voir cette flexibilité de capture en action dans un exemple
+ particulièrement intéressant qui ne capture que certaines des
+ modifications apportées à un même fichier, voyez l’option
+ « -p » de <code>git add</code> du livre Pro Git.</p>
+
+
+ </div>
+
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-status">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t#Vérifier-l%27état-des-fichiers">livre</a>
+ </span>
+ <a name="status">git status</a>
+ <span class="desc">affiche le statut de vos fichiers dans le dossier de travail et dans la zone d'attente</span>
+ </h2>
+
+ <div class="block">
+ <p>Comme vous l'avez vu dans la section <code>git add</code>, pour voir
+ le statut de votre zone d'attente comparé au code de votre dossier de travail,
+ vous pouvez exécuter la commande <code>git status</code>. En utilisant
+ l'option <code>-s</code> l'affichage de la sortie sera réduit. Sans cette option
+ la commande <code>git status</code> vous donnera plus de contexte et d'indications.
+ Voici le même affichage de la sortie du statut avec et sans le <code>-s</code>.
+ La sortie courte ressemble à ça :
+ </p>
+
+<pre>
+<b>$ git status -s</b>
+<span class="green">A</span><span class="red">M</span> README
+<span class="green">A</span> hello.rb
+</pre>
+
+ Alors que le même statut avec la sortie longue ressemble à ça :
+
+<pre>
+<b>$ git status</b>
+# On branch master
+#
+# Initial commit
+#
+# Changes to be committed:
+# (use "git rm --staged <file>..." to unstage)
+#
+# <span class="green">new file: README</span>
+# <span class="green">new file: hello.rb</span>
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+# (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# <span class="red">modified: README</span>
+#
+</pre>
+
+ <p>Vous pouvez facilement constater que l'affichage court de la sortie
+ est beaucoup plus compact, mais la sortie longue a des informations et
+ indications utiles dont vous pourriez avoir besoin par la suite.
+ </p>
+
+ <p>Git vous dira également quels fichiers ont été effacés
+ ou les fichiers modifiés ou mis en attente depuis votre dernière validation</p>
+<pre>
+<b>$ git status -s</b>
+<span class="green">M</span> README
+ <span class="red">D</span> hello.rb
+</pre>
+
+ Remarquez qu'il y a deux colonnes dans la sortie courte du statut.
+ La première colonne est pour la zone d'attente, la seconde est pour le
+ dossier de travail. Par exemple, si vous avez le fichier README en zone
+ d'attente et qu'ensuite vous le modifiez sans exécuter <code>git add</code>
+ une seconde fois, vous verrez ceci :
+
+<pre>
+<b>$ git status -s</b>
+<span class="green">M</span><span class="red">M</span> README
+ <span class="red">D</span> hello.rb
+</pre>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>,
+ vous exécutez <code>git status</code> pour voir si quoi que ce soit a été
+ modifié ou mis en attente depuis votre dernier instantané pour que vous
+ puissiez décider si vous voulez valider un nouvel instantané et avec quel
+ contenu.
+ </p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-diff">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t#Inspecter-les-modifications-indexées-et-non-indexées">livre</a>
+ </span>
+ <a name="diff">git diff</a>
+ <span class="desc">affiche les modifications indexées et non indexées</span>
+ </h2>
+
+ <div class="block">
+ <p class="nutshell">
+ Git utilise le terme « indexé » pour indiquer l'action qui consiste
+ à mettre une modification en zone d'attente, en vue de son inclusion
+ dans le prochain instantané. En fait, dans la littérature Git, les termes
+ stage (zone d'attente) et index sont interchangeables.
+ On trouve d'ailleurs très souvent le terme index dans les manuels officiels de Git.
+ Nous utiliserons donc le terme « indexer » et
+ l’adjectif « indexé » dans la suite de ce document.
+ </p>
+
+ <p>Il y a deux utilisations principales de la commande <code>git diff</code>.
+ Nous allons décrire la première ici, l'autre sera décrite plus loin
+ dans la section <a href="/fr/inspect">"Inspection et Comparaison"</a>.
+ Pour le moment, nous allons l’utiliser pour visualiser les modifications
+ déjà indexées pour le prochain instantané, et celles qui ne sont encore
+ présentes que dans notre dossier de travail.</p>
+
+ <h4>
+ git diff
+ <small>affiche les modifications non indexées</small>
+ </h4>
+
+ <p>Sans aucun argument, un simple <code>git diff</code> vous affichera au
+ format diff unifié (un correctif) ce que vous avez changé comme code ou
+ contenu de votre projet depuis la dernière indexation ou,
+ à défaut, le dernier instantané.
+ </p>
+
+<pre>
+<b>$ vim hello.rb</b>
+<b>$ git status -s</b>
+ <span class="red">M</span> hello.rb
+<b>$ git diff</b>
+<span class="umber">diff --git a/hello.rb b/hello.rb
+index d62ac43..8d15d50 100644
+--- a/hello.rb
++++ b/hello.rb</span>
+<span class="lblue">@@ -1,7 +1,7 @@</span>
+ class HelloWorld
+
+ def self.hello
+<span class="red">- puts "hello world"</span>
+<span class="green">+ puts "bonjour monde"</span>
+ end
+
+ end
+</pre>
+
+ <p>Là où <code>git status</code> vous affichera quels fichiers ont changé
+ et/ou ont été indexés depuis votre dernière validation, <code>git diff</code>
+ va vous montrer quels sont concrètement ces changements, ligne par ligne.
+ C'est généralement une commande utile à la suite d'un <code>git status</code>.
+ </p>
+
+ <h4 id="diff-staged">
+ git diff --staged
+ <small>affiche les modifications indexées</small>
+ </h4>
+
+ <p>La commande <code>git diff --staged</code> montrera le contenu indexé.
+ C'est-à-dire, elle vous affichera les changements qui seront inclus
+ dans le prochain instantané validé. Ainsi, si vous deviez indexer
+ les modifications de <code>hello.rb</code> de l'exemple précédent,
+ <code>git diff</code> tel quel ne vous affichera rien car il
+ vous afficherait que ce qui n'a <i>pas encore</i> été indexé.
+ </p>
+
+<pre>
+<b>$ git status -s</b>
+ <span class="red">M</span> hello.rb
+<b>$ git add hello.rb </b>
+<b>$ git status -s</b>
+<span class="green">M</span> hello.rb
+<b>$ git diff</b>
+<b>$ </b>
+</pre>
+
+ <p>Si vous voulez voir les changements indexés, vous pouvez exécuter
+ <code>git diff --staged</code> à la place.</p>
+
+<pre>
+<b>$ git status -s</b>
+<span class="green">M</span> hello.rb
+<b>$ git diff</b>
+<b>$ </b>
+<b>$ git diff --staged</b>
+<span class="umber">diff --git a/hello.rb b/hello.rb
+index d62ac43..8d15d50 100644
+--- a/hello.rb
++++ b/hello.rb</span>
+<span class="lblue">@@ -1,7 +1,7 @@</span>
+ class HelloWorld
+
+ def self.hello
+<span class="red">- puts "hello world"</span>
+<span class="green">+ puts "bonjour monde"</span>
+ end
+
+ end
+</pre>
+
+ <h4 id="diff-head">
+ git diff HEAD
+ <small>affiche toutes les modifications, indexées ou non</small>
+ </h4>
+
+ <p>Si vous voulez voir aussi bien les modifications indexées que non indexées ensemble,
+ vous pouvez exécuter <code>git diff HEAD</code>—cela veut simplement
+ dire que vous voulez voir les différences entre votre répertoire de travail et le
+ dernier instantané, ignorant la zone d'index. Si nous apportons une autre modification
+ au fichier <code>hello.rb</code>, alors nous aurons des modifications indexées et
+ d'autres modifications non indexées. Voici ce que chacune des trois commandes
+ <code>diff</code> vous affichera :</p>
+<pre>
+<b>$ vim hello.rb </b>
+<b>$ git diff</b>
+<span class="umber">diff --git a/hello.rb b/hello.rb
+index 4f40006..2ae9ba4 100644
+--- a/hello.rb
++++ b/hello.rb</span>
+<span class="lblue">@@ -1,7 +1,7 @@</span>
+ class HelloWorld
+
+<span class="green">+ # says hello</span>
+ def self.hello
+ puts "bonjour monde"
+ end
+
+ end
+<b>$ git diff --staged</b>
+<span class="umber">diff --git a/hello.rb b/hello.rb
+index 2aabb6e..4f40006 100644
+--- a/hello.rb
++++ b/hello.rb</span>
+<span class="lblue">@@ -1,7 +1,7 @@</span>
+ class HelloWorld
+
+ def self.hello
+<span class="red">- puts "hello world"</span>
+<span class="green">+ puts "bonjour monde"</span>
+ end
+
+ end
+<b>$ git diff HEAD</b>
+<span class="umber">diff --git a/hello.rb b/hello.rb
+index 2aabb6e..2ae9ba4 100644
+--- a/hello.rb
++++ b/hello.rb</span>
+<span class="lblue">@@ -1,7 +1,8 @@</span>
+ class HelloWorld
+
+<span class="green">+ # says hello</span>
+ def self.hello
+<span class="red">- puts "hello world"</span>
+<span class="green">+ puts "bonjour monde"</span>
+ end
+
+ end
+</pre>
+
+ <h4 id="diff-stat">
+ git diff --stat
+ <small>affiche un résumé des modifications au lieu de leur détail</small>
+ </h4>
+
+ <p>Si nous ne voulons pas de l'affichage complet des modifications,
+ mais souhaitons davantage que la sortie de <code>git status</code>,
+ on peut utiliser l'option <code>--stat</code>, qui nous donnera
+ à la place un résumé. Voici le même exemple que
+ précédemment, mais en utilisant l'option <code>--stat</code>.
+ </p>
+
+<pre>
+<b>$ git status -s</b>
+<span class="green">M</span><span class="red">M</span> hello.rb
+<b>$ git diff --stat</b>
+ hello.rb | 1 <span class="green">+</span>
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+<b>$ git diff --staged --stat</b>
+ hello.rb | 2 <span class="green">+</span><span class="red">-</span>
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+<b>$ git diff HEAD --stat</b>
+ hello.rb | 3 <span class="green">++</span><span class="red">-</span>
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+</pre>
+
+ <p>
+ Vous pouvez aussi ajouter des chemins à la fin de n’importe laquelle
+ de ces variantes pour réduire la sortie de <code>diff</code>
+ à des fichiers ou dossiers spécifiques.
+ </p>
+
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>,
+ vous exécutez <code>git diff</code> pour voir les détails de la commande
+ <code>git status</code> : <i>dans quelle mesure</i> les fichiers ont été
+ modifiés ou indexés, ligne par ligne.
+ </p>
+
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-commit">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t#Valider-vos-modifications">livre</a>
+ </span>
+ <a name="commit">git commit</a>
+ <span class="desc">valide un instantané à partir de la zone d'index</span>
+ </h2>
+
+ <div class="block">
+
+ <p>Maintenant que vous avez indexé le contenu dont vous voulez faire un instantané
+ avec la commande <code>git add</code>, vous exécutez <code>git commit</code>
+ pour enregistrer l'instantané.
+ Git enregistre vos nom et adresse email, il faut donc commencer par indiquer
+ leurs valeurs à Git.
+ </p>
+
+<pre>
+<b>$ git config --global user.name 'Votre Nom'</b>
+<b>$ git config --global user.email vous@domaine.fr</b>
+</pre>
+
+ <p>Indexons et validons tous les changements de notre fichier
+ <code>hello.rb</code>. Dans ce premier exemple, nous allons utiliser
+ l'option <code>-m</code> pour fournir un message de commit sur la ligne
+ de commande.
+ </p>
+
+<pre>
+<b>$ git add hello.rb </b>
+<b>$ git status -s</b>
+<span class="green">M</span> hello.rb
+<b>$ git commit -m 'mes modifications bonjour monde'</b>
+[master 68aa034] mes modifications bonjour monde
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+</pre>
+
+ <p>Nous avons désormais enregistré un instantané. Si nous exécutons
+ <code>git status</code> à nouveau, nous allons voir que « la copie
+ de travail est propre », ce qui signifie que nous n'avons fait aucune
+ modification depuis notre dernier commit—il n'y a aucun
+ travail en attente.</p>
+
+<pre>
+<b>$ git status</b>
+# On branch master
+nothing to commit (working directory clean)
+</pre>
+
+ <p>Si vous n'utilisez pas l'option <code>-m</code> option, Git va essayer
+ d'ouvrir un éditeur de texte pour écrire votre message de commit.
+ Dans <code>vim</code>, qui est utilisé par défaut à moins que vous
+ n'ayez configuré une alternative à utiliser, votre écran ressemblera
+ vraisemblablement à cela :
+ </p>
+
+<pre>
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# modified: hello.rb
+#
+~
+~
+".git/COMMIT_EDITMSG" 9L, 257C
+</pre>
+
+ <p>À ce stade vous ajoutez votre message de commit final au tout
+ début du document. Toute ligne qui commence par « # » sera ignorée—Git
+ va vous y ajouter la sortie de la commande <code>git status</code>
+ pour vous rappeler ce que vous avez modifié et indexé.</p>
+
+ <p>En règle générale, il est très important d'écrire de bons messages de commit.
+ Pour des projets libres, par convention vous écrirez votre message
+ plus ou moins dans ce format :</p>
+
+<pre>
+Un court (50 caractères ou moins) résumé des modifications
+
+Un texte explicatif plus détaillé, si nécessaire. Faites le tenir
+sur environ 72 caractères. Dans certains cas, la première ligne est
+traitée comme le sujet d'un email et le reste du texte comme le corps.
+Le saut de ligne entre le résumé et le corps est très important
+(à moins que vous omettiez complètement le corps) ; certains outils git
+peuvent mal fonctionner si vous les mettez l'un après l'autre.
+
+Les paragraphes supplémentaires viennent après d'autres sauts de ligne.
+
+ - Les listes à puces sont possibles, aussi
+
+ - Typiquement, un tiret ou une astérisque est utilisée comme puce,
+ précédée d'une seule espace, séparées par des sauts de ligne, mais
+ différentes conventions existent
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# modified: hello.rb
+#
+~
+~
+~
+".git/COMMIT_EDITMSG" 25L, 884C written
+</pre>
+
+ <p class="aside">
+ Le message de commit est très important. Étant donné qu'une grande
+ part de la puissance de Git est cette souplesse dans la création attentionnée
+ des commits en local pour les partager ensuite, c'est très utile de
+ pouvoir écrire trois ou quatre validations sur des modifications indépendantes
+ afin que votre travail puisse être examiné plus facilement par vos pairs.
+ Étant donné qu'il y a une différence entre créer un commit et pousser ses modifications,
+ prenez bien le temps de faciliter aux personnes avec lesquelles vous travaillez
+ la lecture de ce que vous avez fait en plaçant chaque modification indépendante
+ dans un commit propre avec un joli message pour que ce soit
+ simple pour eux de voir ce que vous faites et pourquoi.</p>
+
+ <h4 id="commit-a">
+ git commit -a
+ <small>indexe automatiquement, avant un commit, toutes les modifications aux fichiers suivis</small>
+ </h4>
+
+ <p>Si l'étape <code>git add</code> du flux de travail vous paraît lourde,
+ Git vous permet de sauter celle-ci avec l'option <code>-a</code>.
+ Cela va simplement dire à Git d'exécuter <code>git add</code> sur
+ chaque fichier qui est « suivi »—c'est-à-dire, chaque fichier qui fait
+ partie de votre dernier commit et qui a été modifié. Cela vous permet
+ d'avoir un flux de travail plus proche de celui de Subversion si vous le voulez,
+ en éditant simplement vos fichiers puis en exécutant <code>git commit -a</code>
+ pour réaliser un instantané de tout ce qui a changé. Vous aurez toujours à
+ exécuter <code>git add</code> pour commencer à suivre de nouveaux fichiers,
+ néanmoins, tout comme avec Subversion.
+ </p>
+
+<pre>
+<b>$ vim hello.rb</b>
+<b>$ git status -s</b>
+ <span class="red">M</span> hello.rb
+<b>$ git commit -m 'changes to hello file'</b>
+# On branch master
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+# (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified: hello.rb
+#
+<span class="hl">no changes added to commit (use "git add" and/or "git commit -a")</span>
+<b>$ git commit -am 'changes to hello file'</b>
+[master 78b2670] changes to hello file
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+</pre>
+
+ <p>Notez que si vous n'indexez aucune modification et que vous exécutez
+ <code>git commit</code>, Git va simplement vous retourner la sortie de la
+ commande <code>git status</code>, pour vous rappeler que rien n'a été indexé.
+ La partie importante de ce message a été mise en exergue, et signifie que
+ rien n'a été ajouté pour commit. Si vous utilisez <code>-a</code>,
+ cela va tout ajouter et créer un commit en même temps.
+ </p>
+
+ <p>Cela va vous permettre de finaliser le flux de travail complet des
+ instantanés—vous faites des modifications à vos fichiers, vous utilisez
+ ensuite <code>git add</code> pour indexer les fichiers que vous avez
+ modifiés, <code>git status</code> et <code>git diff</code> pour voir
+ ce que vous avez modifié, et finalement <code>git commit</code>
+ pour enregistrer définitivement votre instantané.</p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>,
+ vous exécutez <code>git commit</code> pour enregistrer l'instantané
+ de votre contenu indexé. Cet instantané peut ensuite être comparé,
+ partagé et rembobiné au besoin.
+ </p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-reset">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Annuler-des-actions#Désindexer-un-fichier-déjà-indexé">livre</a>
+ </span>
+ <a name="reset">git reset</a>
+ <span class="desc">annule des changements et instantanés</span>
+ </h2>
+
+ <div class="block">
+ <p><code>git reset</code> est probablement la commande source de la plus
+ grande confusion jamais écrite, mais elle peut être extrêmement utile
+ une fois qu'on en a saisi le principe. Il y a trois invocations spécifiques
+ de cette commande qui sont communément utilisées.
+ </p>
+
+ <h4 id="reset-head">
+ git reset HEAD
+ <small>retire des fichiers de l'index et ré-initialise le pointeur vers HEAD</small>
+ </h4>
+
+ <p>Pour commencer, vous pouvez l'utiliser pour enlever quelque chose de placé
+ accidentellement dans l'index. Imaginons que vous avez modifié
+ deux fichiers et que vous vouliez les enregistrer dans deux commits différents.
+ Vous devriez indexer et faire un commit pour un fichier, puis indexer et faire un commit
+ pour l'autre. Si vous avez accidentellement indexé les deux, comment
+ en <i>dés</i>indexer un ? Vous le faites avec
+ <code>git reset HEAD -- fichier</code>. Techniquement vous n'avez pas à ajouter
+ le <code>--</code>—il est utilisé pour dire à Git où se termine la liste des options
+ et où commence la liste des chemins, mais c'est probablement une bonne idée
+ de prendre l'habitude de l'utiliser pour séparer les options des chemins
+ même si vous n'en avez pas besoin.
+ </p>
+
+ <p>Voyons à quoi cela ressemble de désindexer quelque chose.
+ Ici nous avons deux fichiers qui ont été modifiés depuis notre dernier commit.
+ Nous allons les indexer tous les deux, puis en désindexer un des deux.</p>
+
+<pre>
+<b>$ git status -s</b>
+ <span class="red">M</span> README
+ <span class="red">M</span> hello.rb
+<b>$ git add .</b>
+<b>$ git status -s</b>
+<span class="green">M</span> README
+<span class="green">M</span> hello.rb
+<b>$ git reset HEAD -- hello.rb </b>
+Unstaged changes after reset:
+M hello.rb
+<b>$ git status -s</b>
+<span class="green">M</span> README
+ <span class="red">M</span> hello.rb
+</pre>
+
+ <p>Vous pouvez alors exécuter <code>git commit</code> qui va juste
+ enregistrer les modifications du fichier <code>README</code>, pas celles
+ du fichier <code>hello.rb</code>.
+ </p>
+
+ <p class="aside">
+ Si vous êtes curieux, ce que Git fait concrètement ici est de recaler
+ la somme de contrôle de l'entrée de ce fichier dans l'index à ce qu'elle
+ était dans la dernière validation. Vu que <code>git add</code> crée une somme
+ de contrôle d'un fichier et l'ajoute à l'index, <code>git reset HEAD</code>
+ écrase cela avec sa valeur précédente, pour ainsi effectivement le sortir
+ de l'index.
+ </p>
+
+ <p class="tip">
+ Si vous voulez être capable de simplement exécuter <code>git unstage</code>,
+ vous pouvez facilement définir un alias dans Git. Exécutez simplement
+ <code>git config --global alias.unstage "reset HEAD"</code>.
+ Une fois exécuté, vous pouvez ensuite exécuter
+ <code>git unstage [fichier]</code> à la place.
+ </p>
+
+ <p>Si vous oubliez quelle est la commande pour désindexer
+ quelque chose, Git vient à votre aide en vous le rappelant
+ dans la sortie de la commande normale <code>git status</code>.
+ Par exemple, si vous exécutez <code>git status</code> sans le
+ <code>-s</code> quand vous avez des fichiers indexés, il vous
+ dira comment les sortir de l'index :</p>
+
+<pre>
+<b>$ git status</b>
+# On branch master
+# Changes to be committed:
+# <span class="hl">(use "git reset HEAD <file>..." to unstage)</span>
+#
+# <span class="green">modified: README</span>
+# <span class="green">modified: hello.rb</span>
+#
+</pre>
+
+ <p>Quand vous exécutez <code>git reset</code> sans spécifier un drapeau
+ il utilise par défaut <code>--mixed</code>. Les autres options sont
+ <code>--soft</code> et <code>--hard</code>.</p>
+
+ <h4 id="reset-soft">
+ git reset --soft
+ <small>déplace HEAD vers une référence spécifique de commit, la zone d'attente restant inchangée</small>
+ </h4>
+
+ <p>La première chose que fait <code>git reset</code> est d'annuler
+ le dernier commit et remettre les fichiers dans l'index.
+ Si vous incluez le drapeau <code>--soft</code> il s'arrête là.
+ Par exemple, si vous exécutez <code>git reset --soft HEAD~</code>
+ (le parent de HEAD) le dernier commit sera annulé et les fichiers
+ modifiés seront mis à nouveau dans l'index.</p>
+
+<pre>
+<b>$ git status -s</b>
+<span class="green">M</span> hello.rb
+<b>$ git commit -am 'hello with a flower'</b>
+[master 5857ac1] hello with a flower
+ 1 files changed, 3 insertions(+), 1 deletions(-)
+<b>$ git status</b>
+# On branch master
+nothing to commit (working directory clean)
+<b>$ git reset --soft HEAD~</b>
+<b>$ git status -s</b>
+<span class="green">M</span> hello.rb
+</pre>
+
+ <p>Ça fait en gros la même chose que
+ <code>git commit --amend</code>, vous permettant de continuer
+ à travailler avant que vous n'ajoutiez les modifications de fichiers
+ dans le même commit.</p>
+
+ <h4 id="reset-hard">
+ git reset --hard
+ <small>annule toute modification, indexée ou encore dans la copie de travail, survenue depuis le dernier commit</small>
+ </h4>
+
+ <p>La troisième option est <code>--hard</code>. Cette variante annule toute
+ modification indexée ou présente dans la copie de travail. En d'autres
+ termes, elle ramène les deux à leur état du dernier commit en date.
+ C'est la variante la plus dangereuse, car elle peut passer à la trappe
+ des modifications de votre copie de travail. Toute modification
+ non validée au préalable sera perdue.</p>
+
+<pre>
+<b>$ git status</b>
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# <span class="green">modified: README</span>
+#
+# Changes not staged for commit:
+# (use "git add <file>..." to update what will be committed)
+# (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# <span class="red">modified: README</span>
+#
+<b>$ git reset --hard HEAD</b>
+HEAD is now at 5857ac1 hello with a flower
+<b>$ git status</b>
+# On branch master
+nothing to commit (working directory clean)
+</pre>
+
+ <p>Dans l'exemple ci-dessus, alors que nous avions toutes les modifications
+ prêtes à être validées et ajoutées, un <code>git reset --hard</code>
+ les a complètement supprimées. Le dossier de travail et l'index
+ sont ré-initialisés à la pointe de la branche courante ou HEAD.</p>
+
+ <p>Vous pouvez remplacer <code>HEAD</code> avec le SHA-1 d'un commit
+ ou une autre référence vers un parent pour ré-initialiser en un point
+ spécifique.</p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>,
+ vous exécutez <code>git reset HEAD</code> pour annuler le dernier commit,
+ sortir de l'index des fichiers sur lesquels vous aviez exécuté
+ <code>git add</code> et que vous ne désirez pas inclure dans le prochain
+ commit.</p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a href="http://git-scm.com/docs/git-rm">docs</a>
+ <a href="http://git-scm.com/book/fr/Les-bases-de-Git-Enregistrer-des-modifications-dans-le-d%C3%A9p%C3%B4t#Effacer-des-fichiers">livre</a>
+ </span>
+ <a name="rm-mv">git rm</a>
+ <span class="desc">supprime des fichiers de l'index</span>
+ </h2>
+
+ <div class="block">
+
+ <p><code>git rm</code> va supprimer des entrées de l'index.
+ C'est un peu différent de <code>git reset HEAD</code> qui désindexe des
+ fichiers. Désindexer signifie recaler l'index à l'état dans lequel
+ il était avant que nous fassions des modifications. <code>git rm</code> d'un
+ autre côté sort complétement le fichier de l'index, de sorte
+ qu'il ne sera pas inclus dans le prochain commit,
+ le supprimant ainsi carrément.</p>
+
+ <p>Par défaut, un <code>git rm file</code> va supprimer complètement
+ le fichier de l'index et aussi de votre disque (le dossier
+ de travail). Pour laisser le fichier dans le dossier de travail,
+ vous pouvez utiliser <code>git rm --staged</code>.</p>
+
+ <h4>
+ git mv
+ <small>git rm --staged orig; mv original nouveau; git add nouveau</small>
+ </h4>
+
+ <p>
+ Contrairement à la plupart des systèmes de gestion de sources, Git ne
+ suit pas le renommage des fichiers. À la place, il suit juste les commits
+ et arrive par la suite à réaliser quels fichiers ont pu être renommés
+ en comparant les commits. Si un fichier a été supprimé d'un commit
+ et un autre fichier a été ajouté au suivant avec un contenu similaire,
+ Git supposera que c'est sûrement un renommage. Alors, bien que la commande
+ <code>git mv</code> existe, elle est superflue—tout ce qu'elle fait est un
+ <code>git rm --staged</code>, renomme le fichier sur le disque, puis exécute un
+ <code>git add</code> sur le nouveau fichier. Vous n'avez pas vraiment besoin
+ de l'utiliser, mais si cela vous semble plus simple, n'hésitez pas.
+ </p>
+
+ <p class="aside">
+ La commande est communément utilisée pour supprimer les fichiers.
+ Mais il est souvent plus simple de juste supprimer les fichiers du disque
+ puis exécuter <code>git commit -a</code>, ce qui va également automatiquement
+ les supprimer de l'index.</p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>,
+ vous exécutez <code>git rm</code> pour supprimer des fichiers du suivi de Git.
+ Cela va également les supprimer de votre dossier de travail.
+ </p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a href="http://git-scm.com/docs/git-stash">docs</a>
+ <a href="http://git-scm.com/book/fr/Utilitaires-Git-Le-remisage">livre</a>
+ </span>
+ <a name="stash">git stash</a>
+ <span class="desc">remise pour plus tard des modifications faites dans l'index et le dossier de travail</span>
+ </h2>
+
+ <div class="block">
+
+ <p>Vous êtes au beau milieu de modifications mais quelque chose se présente
+ qui nécessite que vous vous en occupiez, comme une très-très-urgente
+ correction de bug, mais ne souhaitez pas valider ou perdre vos modifications
+ en cours. <code>git stash</code> est là pour vous.
+ </p>
+
+ <h4>
+ git stash
+ <small>remise les modifications courantes sur la pile</small>
+ </h4>
+
+ <p>Un remisage prend l'état courant de votre dossier de travail et de l'index,
+ les place sur une pile pour plus tard, et vous offre en retour un dossier
+ de travail propre. Cela va vous ramener à l'état du dernier commit.
+ </p>
+
+ <p>Si vous avez des fichiers non suivis, <code>git stash</code> ne les inclura pas.
+ Vous pouvez soit les indexer avec <code>git add</code> (sans faire un commit)
+ avant de les remiser, ou, si vous avez une version récente de Git
+ (1.7.7 ou plus), vous pouvez utiliser <code>git stash -u</code> pour aussi
+ remiser des fichiers non versionnés.</p>
+
+<pre>
+<b>$ git status -s</b>
+<span class="red">M</span> hello.rb
+<b>$ git stash</b>
+Saved working directory and index state WIP on master: 5857ac1 hello with a flower
+HEAD is now at 5857ac1 hello with a flower
+<b>$ git status</b>
+# On branch master
+nothing to commit (working directory clean)
+</pre>
+
+ <h4 id="stash-list">
+ git stash list
+ <small>affiche les remisages présents sur la pile</small>
+ </h4>
+
+ <p>C'est utile de savoir ce que vous avez stocké sur la pile et c'est la où
+ <code>git stash list</code> entre en jeu. Exécuter cette commande
+ va vous afficher la liste courante des éléments remisés.
+ </p>
+
+<pre>
+<b>$ git stash list</b>
+stash@{0}: WIP on master: 5857ac1 hello with a flower
+</pre>
+
+ <p>Le dernier élément ajouté sur la pile sera référencé par
+ <code>stash@{0}</code> et incrémentera d'une unité la référence
+ vers les éléments déjà présents.
+ </p>
+
+<pre>
+<b>$ vim hello.rb</b>
+<b>$ git commit -am 'it stops raining'</b>
+[master ee2d2c6] it stops raining
+1 files changed, 1 insertions(+), 1 deletions(-)
+<b>$ vim hello.rb</b>
+<b>$ git stash</b>
+Saved working directory and index state WIP on master: ee2d2c6 it stops raining
+HEAD is now at ee2d2c6 it stops raining
+<b>$ git stash list</b>
+stash@{0}: WIP on master: ee2d2c6 it stops raining
+stash@{1}: WIP on master: 5857ac1 hello with a flower
+</pre>
+
+ <h4 id="stash-apply">
+ git stash apply
+ <small>récupère l'élément depuis la pile et l'applique au dossier de travail</small>
+ </h4>
+
+ <p>Quand vous êtes prêt à reprendre là où vous en êtiez, exécutez la
+ commande <code>git stash apply</code> pour appliquer dans le dossier
+ de travail des modifications remisées.
+ </p>
+
+<pre>
+<b>$ git stash apply</b>
+# On branch master
+# Changes not staged for commit:
+# (use "git add <file>..." to update what will be committed)
+# (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# <span class="red">modified: hello.rb</span>
+#
+no changes added to commit (use "git add" and/or "git commit -a")
+</pre>
+
+ <p>Par défaut cela va appliquer le dernier élément remisé au dossier
+ de travail. Ce sera l'élément référencé par <code>stash@{0}</code>.
+ Vous pouvez récupérer à la place un autre élément remisé si vous le référencez
+ dans la liste des arguments. Par exemple, <code>git stash apply stash@{1}</code>
+ va appliquer l'élément référencé par <code>stash@{1}</code>.
+ </p>
+
+ <p>Si vous voulez également supprimer l'élément de la pile en même temps,
+ utilisez <code>git stash pop</code> à la place.
+ </p>
+
+ <h4 id="stash-drop">
+ git stash drop
+ <small>supprime un élément de la pile</small>
+ </h4>
+
+ <p>Quand vous en avez fini avec un élément remisé et/ou vous voulez le
+ supprimer de la liste, exécutez la commande <code>git stash drop</code>.
+ Par défaut cela va supprimer le dernier élément remisé ajouté. Vous pouvez
+ aussi supprimer un élément en particulier si vous l'indiquez en tant qu'argument.
+ </p>
+
+ <p>Dans cet exemple, notre pile a au moins deux éléments, mais nous
+ voulons nous débarasser de l'élément ajouté avant le dernier, qui
+ est référencé par <code>stash@{1}</code>.
+ </p>
+
+<pre>
+<b>$ git stash drop stash@{1}</b>
+Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)
+</pre>
+
+ <p>Si vous voulez supprimer tous les éléments remisés, exécutez juste
+ la commande <code>git stash clear</code>. Mais faites cela seulement
+ si vous êtes sûr d'en avoir fini avec la pile.
+ </p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>, exécutez <code>git stash</code> pour rapidement
+ remiser des modifications que vous n'êtes pas prêt à valider ou sauver, mais
+ auxquelles vous voulez revenir après avoir travaillé sur autre chose.
+ </p>
+
+ </div>
+ </div>
+
+ <p><a class="page-button next-page" href="/fr/branching">Aller à Création de Branches et Fusion »</a></p>
diff --git a/fr/branching/index.html b/fr/branching/index.html
new file mode 100644
index 0000000..c148544
--- /dev/null
+++ b/fr/branching/index.html
@@ -0,0 +1,897 @@
+---
+layout: fr_reference
+---
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/book/fr/Les-branches-avec-Git">livre</a>
+ </span>
+ Création de Branches et Fusion
+ </h2>
+ <div class="block">
+ <p>Les branches sont une des nombreuses fonctionnalités intéressantes de Git.
+ Si vous avez utilisé d'autres systèmes de gestion de versions, il sera
+ probablement utile d'oublier tout ce que vous savez sur les branches—En fait,
+ il sera encore plus utile de les voir quasiment comme des
+ <i>contextes</i> car c'est la façon la plus courante dont vous allez
+ vous en servir. Quand vous basculez dans une branche, vous changez de
+ contexte de travail, et vous pouvez rapidement basculer de l'une à l'autre.
+ </p>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous pouvez créer une branche avec
+ <code>git branch (nombranche)</code>, basculer dans ce contexte avec
+ <code>git checkout (nombranche)</code>, enregistrer un commit
+ depuis ce contexte, puis basculer d'une branche à l'autre facilement.
+ Quand vous changez de branche, Git remplace votre dossier de travail
+ avec l'instantané du dernier commit de cette branche afin que vous
+ n'ayez pas de multiples dossiers pour de multiples branches. Vous fusionnez
+ des branches ensemble avec <code>git merge</code>. Vous pouvez facilement
+ faire plusieurs fusions étalées dans le temps depuis la même branche,
+ ou alternativement vous pouvez choisir de supprimer une branche dès
+ que vous l'avez fusionnée.
+ </p>
+
+ </div>
+</div>
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-branch">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-branches-avec-Git-Ce-qu-est-une-branche">livre</a>
+ </span>
+ <a name="branch">git branch</a>
+ <span class="desc">liste, crée et gére les contextes de travail</span>
+ </h2>
+
+ <br/>
+
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-checkout">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-branches-avec-Git-Brancher-et-fusionner%C2%A0%3A-les-bases">livre</a>
+ </span>
+ <a name="checkout">git checkout</a>
+ <span class="desc">bascule vers un nouveau contexte de branche</span>
+ </h2>
+
+ <div class="block">
+ <p>La commande <code>git branch</code> est un outil de gestion général des branches
+ de Git et peut faire de nombreuses choses différentes. Nous allons aborder
+ celles de base que vous utiliserez le plus souvent—lister les branches, créer
+ des branches et supprimer des branches. Nous allons aussi aborder
+ <code>git checkout</code> ici qui vous permet de basculer entre branches.
+ </p>
+
+ <h4 id="branch-list">
+ git branch
+ <small>liste vos branches disponibles</small>
+ </h4>
+
+ <p>Sans argument, <code>git branch</code> va lister vos branches locales.
+ La branche courante sur laquelle vous êtes sera précédée d'un astérisque
+ et si vous avez
+ <a href="http://git-scm.com/book/fr/Personnalisation-de-Git-Configuration-de-Git#Couleurs-dans-Git">la colorisation activée</a>,
+ la branche courante sera affichée en vert.
+ </p>
+
+<pre>
+$ git branch
+* <span class="green">master</span>
+</pre>
+
+ <p>Cela signifie que nous avons une branche « master » et que nous sommes sur
+ celle-ci. Quand vous exécutez <code>git init</code> cela va automatiquement
+ créer une branche « master » pour vous par défaut, néanmoins il n'y a rien
+ de particulier dans ce nom—vous n'avez pas en fait à avoir de branche « master »
+ mais étant donné qu'elle est créée par défaut, la plupart des projets en ont une.
+ </p>
+
+ <h4 id="branch-create">
+ git branch (nombranche)
+ <small>crée une nouvelle branche</small>
+ </h4>
+
+ <p>Commençons par créer une nouvelle branche puis basculons vers celle-ci.
+ Vous pouvez le faire en exécutant <code>git branch (nombranche)</code>.
+ </p>
+
+<pre>
+$ git branch testing
+$ git branch
+* <span class="green">master</span>
+ testing
+</pre>
+
+ <p>Vous pouvez voir que nous avons une nouvelle branche. Quand vous créez une
+ branche de cette manière cela crée la branche basée sur votre dernier commit
+ donc si à ce stade vous créez des commits puis basculez vers « testing »,
+ vous rétablirez le contexte de votre dossier de travail à celui où il était
+ lorsque la branche a été créée initialement—Vous pouvez penser à cela comme
+ un signet qui indique où vous en êtes. Voyons cela en action—nous utilisons
+ <code>git checkout (branche)</code> pour changer de branche courante.
+ </p>
+
+<pre>
+<b>$ ls</b>
+README hello.rb
+<b>$ echo 'test content' > test.txt</b>
+<b>$ echo 'more content' > more.txt</b>
+<b>$ git add *.txt</b>
+<b>$ git commit -m 'added two files'</b>
+[master 8bd6d8b] added two files
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 100644 more.txt
+ create mode 100644 test.txt
+<b>$ ls</b>
+README hello.rb more.txt test.txt
+<b>$ git checkout testing</b>
+Switched to branch 'testing'
+<b>$ ls</b>
+README hello.rb
+</pre>
+
+ <p>Nous voyons que lorsque nous basculons vers la branche « testing »,
+ nos nouveaux fichiers ont disparu. Nous pouvons retourner vers la
+ branche « master » et les voir ré-apparaître.</p>
+
+<pre>
+<b>$ ls</b>
+README hello.rb
+<b>$ git checkout master</b>
+Switched to branch 'master'
+<b>$ ls</b>
+README hello.rb more.txt test.txt
+</pre>
+
+ <h4 id="branch-last-commit">
+ git branch -v
+ <small>affiche le dernier commit de chaque branche</small>
+ </h4>
+
+ <p>Si nous voulons voir les derniers commits de chaque branche
+ nous pouvons exécuter <code>git branch -v</code> pour les voir.</p>
+
+<pre>
+<b>$ git branch -v</b>
+* <span class="green">master</span> 54b417d fix javascript issue
+ development 74c111d modify component.json file
+ testing 62a557a update test scripts
+</pre>
+
+ <h4 id="branch-create-switch">
+ git checkout -b (nombranche)
+ <small>crée puis bascule immédiatement vers une branche</small>
+ </h4>
+
+ <p>
+ Dans la plupart des cas vous voudrez basculer vers la branche immédiatement,
+ afin de pouvoir y travailler puis la fusionner plus tard dans une branche qui contient
+ seulement du travail stable (comme « master ») lorsque le travail
+ dans votre nouvelle branche sera stable. Vous pouvez faire cela
+ relativement facilement avec
+ <code>git branch nouvellebranche; git checkout nouvellebranche</code>,
+ mais Git a un raccourci pour cela : <code>git checkout -b nouvellebranche</code>.
+ </p>
+
+<pre>
+<b>$ git branch</b>
+* master
+<b>$ ls</b>
+README hello.rb more.txt test.txt
+<b>$ git checkout -b removals</b>
+Switched to a new branch 'removals'
+<b>$ git rm more.txt </b>
+rm 'more.txt'
+<b>$ git rm test.txt </b>
+rm 'test.txt'
+<b>$ ls</b>
+README hello.rb
+<b>$ git commit -am 'removed useless files'</b>
+[removals 8f7c949] removed useless files
+ 2 files changed, 0 insertions(+), 2 deletions(-)
+ delete mode 100644 more.txt
+ delete mode 100644 test.txt
+<b>$ git checkout master</b>
+Switched to branch 'master'
+<b>$ ls</b>
+README hello.rb more.txt test.txt
+</pre>
+
+ <p>Vous pouvez voir ici comment nous avons créé une branche, supprimé certains de nos
+ fichiers depuis le contexte de cette branche, puis nous sommes retournés dans
+ notre branche principale et nous voyons à nouveau nos fichiers. Les branches
+ isolent de manière sécurisée le travail que nous faisons dans des contextes
+ entre lesquels nous pouvons basculer.</p>
+
+ <p>
+ Si vous démarrez un travail il est très sutile de toujours le démarrer dans une
+ branche (parce-que cela est rapide et facile à faire) puis de le fusionner et
+ supprimer la branche quand vous en avez terminé. De cette manière si ce sur quoi
+ vous travaillez ne convient pas vous pouvez facilement vous en débarasser, et
+ si vous êtes forcé de basculer vers un contexte de travail plus stable, votre travail
+ en cours est facile à mettre de côté et à retrouver plus tard.</p>
+
+ <h4 id="branch-delete">
+ git branch -d (nombranche)
+ <small>supprime une branche</small>
+ </h4>
+
+ <p>Si nous voulons supprimer une branche (comme la branche « testing » de
+ l'exemple précédent vu qu'il n'y a aucun travail particulier sur celle-ci),
+ nous pouvons exécuter <code>git branch -d (branche)</code> pour la supprimer.</p>
+
+<pre>
+<b>$ git branch</b>
+* <span class="green">master</span>
+ testing
+<b>$ git branch -d testing</b>
+Deleted branch testing (was 78b2670).
+<b>$ git branch</b>
+* <span class="green">master</span>
+</pre>
+
+ <h4 id="branch-delete-remote">
+ git push (nom-distant) :(nombranche)
+ <small>supprime une branche distante</small>
+ </h4>
+
+ <p>Quand vous en avez fini avec une branche distante, qu'elle ait
+ été fusionnée dans le dépôt distant ou que vous vouliez l'abandonner
+ et la cacher des regards, vous exécuterez la commande <code>git push</code>
+ avec un symbôle deux-points savamment placé pour supprimer la branche :</p>
+
+<pre>
+<b>$ git push origin :tidy-cutlery</b>
+To git@github.com:octocat/Spoon-Knife.git
+ - [deleted] tidy-cutlery
+</pre>
+
+ <p>Dans l'exemple ci-dessus vous avez supprimé la branche « tidy-cutlery »
+ du dépôt distant « origin ». Un moyen de se souvenir de cette syntaxe est
+ de penser à celle de
+ <code>git push nom-distant branche-locale:branche-distante</code>.
+ Cela signifie que vous désirez pousser votre branche locale pour
+ qu'elle soit similaire sur le dépôt distant. Quand vous supprimez
+ la portion <code>branche-locale</code> vous ne faites alors plus rien
+ correspondre sur le dépôt distant, signifiant concrètement à la
+ branche distante d'être nulle.
+ </p>
+
+ <p>Alternativement, vous pouvez exécuter
+ <code>git push nom-distant --delete nombranche</code>
+ qui est un raccourci de la syntaxe deux-points (une paire
+ <code>source:destination</code>) de suppression d'une branche distante.
+ </p>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous utilisez <code>git branch</code> pour lister
+ vos branches, créer de nouvelles branches et supprimer des branches
+ inutiles ou qui ont été fusionnées.
+ </p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-merge">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-branches-avec-Git-Brancher-et-fusionner%C2%A0:-les-bases#Les-bases-de-la-fusion">livre</a>
+ </span>
+ <a name="merge">git merge</a>
+ <span class="desc">fusionne le contexte d'une branche dans votre contexte courant</span>
+ </h2>
+
+ <div class="block">
+ <p>Une fois isolé un travail dans une branche, vous allez peut-être
+ l'incorporer dans votre branche principale. Vous pouvez fusionner
+ toute branche dans votre branche courante avec la commande
+ <code>git merge</code>. Prenons comme exemple simple la branche
+ « removals » précédente. Si nous créons une branche et supprimons les fichiers
+ qui s'y trouvent puis que nous validons ces suppressions dans cette branche,
+ cela est isolé de notre branche principale (« master », dans notre cas). Pour
+ inclure ces suppressions dans notre branche « master », vous pouvez simplement
+ fusionner la branche « removals ».
+ </p>
+
+<pre>
+<b>$ git branch</b>
+* <span class="green">master</span>
+ removals
+<b>$ ls</b>
+README hello.rb more.txt test.txt
+<b>$ git merge removals</b>
+Updating 8bd6d8b..8f7c949
+Fast-forward
+ more.txt | 1 -
+ test.txt | 1 -
+ 2 files changed, 0 insertions(+), 2 deletions(-)
+ delete mode 100644 more.txt
+ delete mode 100644 test.txt
+<b>$ ls</b>
+<span class="hl">README hello.rb</span>
+</pre>
+
+ <h4 id="merge-complex">
+ fusions plus avancées
+ </h4>
+
+ <p>Bien sûr, cela ne marche pas juste pour de simples ajouts et suppressions
+ de fichiers. Git va tout autant fusionner les modifications de fichiers—En
+ fait, il est même très bon pour ça. Par exemple, voyons ce qu'il arrive
+ quand on édite un fichier dans une branche et nous le renommons et puis
+ l'éditons dans une autre branche et enfin nous fusionnons ensemble
+ ces branches. Chaos, vous avez dit ? Voyons cela.
+ </p>
+
+<pre>
+<b>$ git branch</b>
+* master
+<b>$ cat hello.rb </b>
+class HelloWorld
+ def self.hello
+ puts "Hello World"
+ end
+end
+
+HelloWorld.hello
+</pre>
+
+ <p>Nous allons donc commencer par créer une nouvelle branche nommée
+ « change_class », puis basculer vers celle-ci afin que les modifications
+ de renommage de classe soient isolées. Nous allons changer chaque
+ occurrence de « HelloWorld » en « HiWorld ».</p>
+
+<pre>
+<b>$ git checkout -b change_class</b>
+Switched to a new branch 'change_class'
+<b>$ vim hello.rb </b>
+<b>$ head -1 hello.rb </b>
+class HiWorld
+<b>$ git commit -am 'changed the class name'</b>
+[change_class 3467b0a] changed the class name
+ 1 files changed, 2 insertions(+), 4 deletions(-)
+</pre>
+
+ <p>Nous avons alors validé les changements de nom de la classe dans
+ une branche « change_class ». En retournant vers la branche « master »
+ le nom de la classe sera ré-initialisé à ce à quoi il était avant
+ que nous changions de branche. Ici nous pouvons modifier quelque chose
+ de différent (dans ce cas la sortie affichée) et en même temps
+ renommer le fichier <code>hello.rb</code> en <code>ruby.rb</code>.
+ </p>
+
+<pre>
+<b>$ git checkout master</b>
+Switched to branch 'master'
+<b>$ git mv hello.rb ruby.rb</b>
+<b>$ vim ruby.rb </b>
+<b>$ git diff</b>
+<span class="umber">diff --git a/ruby.rb b/ruby.rb
+index 2aabb6e..bf64b17 100644
+--- a/ruby.rb
++++ b/ruby.rb</span>
+<span class="lblue">@@ -1,7 +1,7 @@</span>
+ class HelloWorld
+
+ def self.hello
+<span class="red">- puts "Hello World"</span>
+<span class="green">+ puts "Hello World from Ruby"</span>
+ end
+
+ end
+<b>$ git commit -am 'added from ruby'</b>
+[master b7ae93b] added from ruby
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+ rename hello.rb => ruby.rb (65%)
+</pre>
+
+ <p>Désormais ces modifications sont sauvées dans la branche « master ». Notez
+ que le nom de la classe est de nouveau « HelloWorld », et non « HiWorld ».
+ Pou incorporer le changement « HiWorld » nous pouvons juste fusionner
+ la branche « change_class ». Néanmoins, le nom du fichier a changé depuis
+ que nous avons changé de branche, que va faire Git ?</p>
+
+<pre>
+<b>$ git branch</b>
+ change_class
+* master
+<b>$ git merge change_class</b>
+Renaming hello.rb => ruby.rb
+Auto-merging ruby.rb
+Merge made by recursive.
+ ruby.rb | 6 ++----
+ 1 files changed, 2 insertions(+), 4 deletions(-)
+<b>$ cat ruby.rb</b>
+class HiWorld
+ def self.hello
+ puts "Hello World from Ruby"
+ end
+end
+
+HiWorld.hello
+</pre>
+
+ <p>Et bien, il va simplement s'en rendre compte. Notez qu'il n'y a aucun conflit de
+ fusion et que le fichier qui a été renommé a désormais le changement de nom
+ de classe « HiWorld » qui a été fait dans l'autre branche. Plutôt cool.</p>
+
+ <h4 id="merge-conflicts">
+ conflits de fusion
+ </h4>
+
+ <p>Les fusions Git relèvent donc de la magie, nous n'avons jamais à traiter
+ des conflits de fusion ? Pas tout à fait. Dans des situations où
+ un même bloc de code est édité dans différentes branches il n'y a aucun moyen
+ pour un ordinateur de s'y retrouver, alors c'est à nous de nous débrouiller.
+ Voyons un autre exemple de changement d'une même ligne dans deux branches.
+ </p>
+
+<pre>
+<b>$ git branch</b>
+* master
+<b>$ git checkout -b fix_readme</b>
+Switched to a new branch 'fix_readme'
+<b>$ vim README </b>
+<b>$ git commit -am 'fixed readme title'</b>
+[fix_readme 3ac015d] fixed readme title
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+</pre>
+
+ <p>Nous avons alors créé un commit du changement d'une ligne dans notre
+ fichier README dans une branche. Maintenant changeons la même ligne
+ d'une manière différente depuis notre branche « master ».</p>
+
+<pre>
+<b>$ git checkout master</b>
+Switched to branch 'master'
+<b>$ vim README </b>
+<b>$ git commit -am 'fixed readme title differently'</b>
+[master 3cbb6aa] fixed readme title differently
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+</pre>
+
+ <p>Arrive le plus amusant—nous allons fusionner la première
+ branche dans notre branche « master », provoquant un conflit de fusion.</p>
+
+<pre>
+<b>$ git merge fix_readme</b>
+Auto-merging README
+CONFLICT (content): Merge conflict in README
+Automatic merge failed; fix conflicts and then commit the result.
+<b>$ cat README </b>
+<<<<<<< HEAD
+Many Hello World Examples
+=======
+Hello World Lang Examples
+>>>>>>> fix_readme
+
+This project has examples of hello world in
+nearly every programming language.
+</pre>
+
+ <p>Vous pouvez voir que Git insère des marqueurs standards de conflit de fusion,
+ très similaires à Subversion, dans les fichiers qui ont un conflit de fusion.
+ Maintenant c'est à vous de les résoudre. Nous allons le faire manuellement,
+ mais regardez
+ <a href="http://git-scm.com/docs/git-mergetool">git mergetool</a>
+ si vous voulez que Git lance un outil graphique de fusion
+ (comme kdiff3, emerge, p4merge, etc) à la place.
+ </p>
+
+<pre>
+<b>$ vim README </b> <span class="exp"># here I'm fixing the conflict</span>
+<b>$ git diff</b>
+<span class="umber">diff --cc README
+index 9103e27,69cad1a..0000000
+--- a/README
++++ b/README</span>
+<span class="lblue">@@@ -1,4 -1,4 +1,4 @@@</span>
+<span class="red">- Many Hello World Examples</span>
+ <span class="red">-Hello World Lang Examples</span>
+<span class="green">++Many Hello World Lang Examples</span>
+
+ This project has examples of hello world in
+</pre>
+
+ <p>Un bon conseil lors de la résolution de conflit de fusion est que si
+ vous exécutez <code>git diff</code>, cela va vous montrer chaque côté
+ du conflit et comment vous l'avez résolu comme affiché ici. Maintenant
+ il est l'heure de marquer notre fichier comme résolu. Avec Git on le fait
+ avec <code>git add</code>—pour dire à Git que le fichier a été résolu
+ vous devez l'indexer.</p>
+
+<pre>
+<b>$ git status -s</b>
+UU README
+<b>$ git add README </b>
+<b>$ git status -s</b>
+M README
+<b>$ git commit </b>
+[master 8d585ea] Merge branch 'fix_readme'
+</pre>
+
+ <p>Et nous avons alors résolu avec succès notre conflit de fusion et créé
+ un commit avec le résultat.</p>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous utilisez <code>git merge</code> pour combiner
+ un autre contexte de branche dans votre branche courante. Cela va
+ automatiquement décider comment combiner au mieux les différents instantanés
+ en un nouvel instantané avec le travail propre de chaque.
+ </p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-log">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Utilitaires-Git-S%C3%A9lection-des-versions#Plages-de-<em>commits</em>">livre</a>
+ </span>
+ <a name="log">git log</a>
+ <span class="desc">affiche l'historique des commits d'une branche</span>
+ </h2>
+
+ <div class="block">
+
+ <p>Jusqu'à présent nous créé des commits des instantanés de votre projet et basculé
+ entre différents contextes isolés, mais comment faire si nous avons oublié
+ comment nous en sommes arrivés à un certain point ? Ou si nous voulons
+ savoir à quel point une branche diffère d'une autre ? Git fournit un outil
+ qui affiche tous les messages de commits qui vous ont amené jusqu'à
+ votre commit courant, appelé <code>git log</code>.</p>
+
+ <p>Pour comprendre la commande d'historique, vous devez connaître quelles
+ informations sont stockées quand vous exécutez la commande
+ <code>git commit</code> pour enregistrer un instantané. En plus de la référence
+ des fichiers et du message de commit et des informations sur l'auteur
+ du commit, Git stocke également le commit sur laquelle vous avez
+ basé votre instantané. C'est-à-dire que, si vous clonez un projet, quel
+ est l'instantané que vous avez modifié pour obtenir l'instantané que vous
+ avez enregistré ? C'est utile pour savoir comment
+ le projet est arrivé à cet état et permet à Git de savoir qui a changé quoi.
+ Si Git a l'instantané que vous avez sauvegardé et celui sur lequel vous vous
+ êtes basé, alors il peut automatiquement savoir ce que vous avez changé.
+ Le commit sur lequel un autre commit est basé est appelé le
+ « parent ».
+ </p>
+
+ <p>Pour voir une liste chronologique des parents de n'importe quelle branche,
+ vous pouvez exécuter <code>git log</code> quand vous êtes dans cette branche.
+ Par exemple, si vous exécutez <code>git log</code> dans le projet Hello World
+ sur lequel nous avons travaillé dans cette section, nous allons voir tous les
+ messages des commits créés.
+ </p>
+
+<pre>
+<b>$ git log</b>
+<span class="yellow">commit 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d</span>
+Merge: 3cbb6aa 3ac015d
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 12:59:47 2010 +0200
+
+ Merge branch 'fix_readme'
+
+ Conflicts:
+ README
+
+<span class="yellow">commit 3cbb6aae5c0cbd711c098e113ae436801371c95e</span>
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 12:58:53 2010 +0200
+
+ fixed readme title differently
+
+<span class="yellow">commit 3ac015da8ade34d4c7ebeffa2053fcac33fb495b</span>
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 12:58:36 2010 +0200
+
+ fixed readme title
+
+<span class="yellow">commit 558151a95567ba4181bab5746bc8f34bd87143d6</span>
+Merge: b7ae93b 3467b0a
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 12:37:05 2010 +0200
+
+ Merge branch 'change_class'
+...
+</pre>
+
+ <p>Pour voir une version plus compacte de ce même historique, nous pouvons
+ utiliser l'option <code>--oneline</code>.</p>
+
+<pre>
+<b>$ git log --oneline</b>
+8d585ea Merge branch 'fix_readme'
+3cbb6aa fixed readme title differently
+3ac015d fixed readme title
+558151a Merge branch 'change_class'
+b7ae93b added from ruby
+3467b0a changed the class name
+17f4acf first commit
+</pre>
+
+ <p>Cela nous informe que c'est l'historique du développement de ce projet.
+ Si les messages de commit sont descriptifs, cela peut nous informer
+ sur les changements apportés ou qui ont influencé l'état de l'instantané
+ et donc ce qu'il contient.</p>
+
+ <p>Nous pouvons aussi l'utiliser pour voir quand l'historique a connu des
+ branches ou fusions avec l'option très utile <code>--graph</code>.
+ Voici la même commande mais avec le graphe de topologie activé :</p>
+
+<pre>
+<b>$ git log --oneline --graph</b>
+* 8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+* 558151a Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+</pre>
+
+ <p>Nous pouvons alors voir quand le travail a divergé et puis a
+ été fusionné. C'est très pratique pour voir ce qui s'est passé ou
+ quels changements ont été appliqués, mais c'est aussi extrêmement utile
+ pour gérer vos branches. Créons une nouvelle branche, effectuons
+ du travail dans celle-ci puis basculons et faisons du travail dans notre
+ branche master, puis voyons comment la commande <code>log</code> peut
+ nous aider à savoir ce qui se passe sur chacune d'elle.</p>
+
+ <p>D'abord nous allons créer une nouvelle branche pour ajouter le langage
+ Erlang comme exemple Hello World—nous désirons le faire dans une branche
+ afin de ne pas casser notre branche stable avec du code qui peut ne pas
+ fonctionner pendant un certain temps pour pouvoir basculer proprement
+ depuis ou vers cette branche.</p>
+
+<pre>
+<b>$ git checkout -b erlang</b>
+Switched to a new branch 'erlang'
+<b>$ vim erlang_hw.erl</b>
+<b>$ git add erlang_hw.erl </b>
+<b>$ git commit -m 'added erlang'</b>
+[erlang ab5ab4c] added erlang
+ 1 files changed, 5 insertions(+), 0 deletions(-)
+ create mode 100644 erlang_hw.erl
+</pre>
+
+ <p>Étant donné que nous nous amusons beaucoup avec les langages de
+ programmation fonctionnelle nous restons dans notre lancée et ajoutons
+ également un programme exemple Haskell alors que nous sommes toujours
+ dans la branche « erlang ».</p>
+
+<pre>
+<b>$ vim haskell.hs</b>
+<b>$ git add haskell.hs </b>
+<b>$ git commit -m 'added haskell'</b>
+[erlang 1834130] added haskell
+ 1 files changed, 4 insertions(+), 0 deletions(-)
+ create mode 100644 haskell.hs
+</pre>
+
+ <p>Enfin, nous décidons de remettre le nom de classe de notre programme Ruby
+ à ce qu'il était précédemment. Alors, nous pouvons retourner à la branche
+ master, le changer et décider de le valider directement dans la branche
+ master au lieu de créer une autre branche.</p>
+
+<pre>
+<b>$ git checkout master</b>
+Switched to branch 'master'
+<b>$ ls</b>
+README ruby.rb
+<b>$ vim ruby.rb </b>
+<b>$ git commit -am 'reverted to old class name'</b>
+[master 594f90b] reverted to old class name
+ 1 files changed, 2 insertions(+), 2 deletions(-)
+</pre>
+
+ <p>Imaginons alors que nous ne travaillons pas sur le projet
+ pendant quelques temps, ayant autre chose à faire. Quand nous
+ y revenons nous voulons en savoir plus sur la branche « erlang » et
+ où nous nous en sommes arrêtés sur la branche master. Juste en regardant
+ le nom de la branche, nous ne pouvons savoir que nous avons fait des modifications
+ en Haskell dans celle-ci, mais en utilisant <code>git log</code> nous pouvons
+ facilement le savoir. Si vous donnez à Git un nom de branche, cela va vous afficher
+ uniquement les commits qui sont « accessibles » dans l'historique de cette
+ branche, c'est-à-dire les commits qui ont influencé l'instantané
+ final.</p>
+
+<pre>
+<b>$ git log --oneline erlang</b>
+<span class="hl">1834130 added haskell</span>
+ab5ab4c added erlang
+8d585ea Merge branch 'fix_readme'
+3cbb6aa fixed readme title differently
+3ac015d fixed readme title
+558151a Merge branch 'change_class'
+b7ae93b added from ruby
+3467b0a changed the class name
+17f4acf first commit
+</pre>
+
+ <p>De cette manière, c'est très simple de voir que nous avons du code Haskell
+ inclus dans la branche (mis en surbrillance dans la sortie).
+ Ce qui est encore plus cool est que nous pouvons facilement dire à Git
+ que nous sommes seulement intéressés par les commits qui sont
+ accessibles dans une branche mais non accessibles dans une autre, en d'autres
+ termes quelles validations sont uniques à une branche par rapport à une autre.
+ </p>
+
+ <p>
+ Dans ce cas si nous sommes intéressés par la fusion de la branche « erlang »
+ nous voulons savoir quelles validations vont affecter notre instantané
+ quand nous allons fusionner. Pour dire à Git de le faire on utilise
+ un <code>^</code> devant la branche que nous ne voulons voir. Par exemple,
+ si nous voulons voir les validations qui sont dans la branche « erlang »
+ qui ne sont pas dans la branche « master », on peut exécuter
+ <code>erlang ^master</code>, et vice-versa. Notez que la ligne de
+ commande Windows traite <code>^</code> comme un caractère spécial,
+ dans ce cas vous devrez mettre <code>^master</code> entre guillemets.
+ </p>
+
+<pre>
+<b>$ git log --oneline erlang ^master</b>
+1834130 added haskell
+ab5ab4c added erlang
+<b>$ git log --oneline master ^erlang</b>
+594f90b reverted to old class name
+</pre>
+
+ <p>Cela nous donne un outil de gestion de branche simple et pratique.
+ Cela nous permet de facilement voir quels commits sont uniques
+ à quelles branches afin de savoir ce qu'il nous manque et ce que
+ nous fusionnerions en cas de fusion.
+ </p>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous pouvez utiliser <code>git log</code> pour lister
+ l'historique des commits ou lister les changements faits par d'autres
+ qui ont mené l'instantané jusqu'à la pointe de la branche. Cela vous permet
+ voir comment dans un contexte le projet est arrivé à l'état dans lequel il
+ est actuellement.
+ </p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-tag">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-%C3%89tiquetage">livre</a>
+ </span>
+ <a name="tag">git tag</a>
+ <span class="desc">étiquette un moment dans l'historique comme important</span>
+ </h2>
+
+ <div class="block">
+
+ <p>
+ Si vous arrivez à un moment qui est important et vous voulez définitivement
+ vous souvenir de ce commit spécifique, vous pouvez
+ l'étiqueter avec <code>git tag</code>. La commande <code>tag</code>
+ va simplement mettre un signet permanent sur un commit spécifique
+ afin de pouvoir l'utiliser pour le comparer à d'autres commits dans
+ le futur. C'est souvent utilisé lorsque vous publiez une version ou vous
+ déployez quelque chose.
+ </p>
+
+ <p>Disons que vous vouliez publier notre projet Hello World en tant
+ que version « 1.0 ». Nous pouvons étiqueter le dernier commit
+ (<code>HEAD</code>) comme « v1.0 » en exécutant <code>git tag -a v1.0</code>.
+ Le <code>-a</code> signifie « fait une étiquette annotée », qui permet
+ de lui ajouter un message d'étiquette, ce que vous voudrez quasiment
+ toujours faire. L'exécuter sans le <code>-a</code> fonctionne aussi,
+ mais cela n'enregistre pas la date, qui l'a étiqueté,
+ ou ne vous laisse pas ajouter un message d'étiquette. Il est recommandé
+ de toujours créer des étiquettes annotées.</p>
+
+<pre>
+<b>$ git tag -a v1.0 </b>
+</pre>
+
+ <p>Quand vous exécutez la commande <code>git tag -a</code>, Git
+ va ouvrir votre éditeur et vous laisser écrire un message d'étiquette,
+ tout comme vous écririez un message de validation.</p>
+
+ <p>Notez alors que quand vous exécutez <code>git log --decorate</code>,
+ nous pouvons voir nos étiquettes.</p>
+
+<pre>
+<b>$ git log --oneline --decorate --graph</b>
+* 594f90b (HEAD, <span class="hl">tag: v1.0</span>, master) reverted to old class name
+* 8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d (fix_readme) fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+* 558151a Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+</pre>
+
+ <p>Si nous faisons des commits supplémentaires, l'étiquette va rester
+ sur cet commit, nous avons alors cet instantané spécifique étiqueté
+ indéfiniment et nous pourrons toujours comparer de futurs instantanés
+ à celui-ci.</p>
+
+ <p>Nous ne sommes pas limités à étiqueter le commit sur lequel nous sommes,
+ néanmoins. Si nous avons oublié d'étiqueter un commit que nous avons
+ publiéxe, nous pouvons rétroactivement l'étiqueter en exécutant la même
+ commande, mais avec le SHA du commit à la fin. Par exemple, disons
+ que nous avons publié le commit <code>558151a</code> (de plusieurs
+ commits en arrière) mais avons oublié de l'étiqueter à ce moment-là.
+ Nous pouvons alors l'étiqueter :</p>
+
+<pre>
+<b>$ git tag -a v0.9 558151a</b>
+<b>$ git log --oneline --decorate --graph</b>
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+* 8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d (fix_readme) fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+* 558151a (<span class="hl">tag: v0.9</span>) Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+</pre>
+
+ <p>Les étiquettes pointant sur des objets suivis par les pointes
+ des branches seront automatiquement téléchargées quand vous utilisez
+ la commande <code>fetch</code> sur un dépôt distant. Néanmoins,
+ les étiquettes qui ne sont pas accessibles depuis les pointes
+ des branches seront ignorées. Si vous voulez être sûr que
+ <em>toutes</em> les étiquettes sont <em>toujours</em> incluses,
+ vous devez inclure l'option <code>--tags</code>.
+ </p>
+
+<pre>
+<b>$ git fetch origin --tags</b>
+remote: Counting objects: 1832, done.
+remote: Compressing objects: 100% (726/726), done.
+remote: Total 1519 (delta 1000), reused 1202 (delta 764)
+Receiving objects: 100% (1519/1519), 1.30 MiB | 1.21 MiB/s, done.
+Resolving deltas: 100% (1000/1000), completed with 182 local objects.
+From git://github.com:example-user/example-repo
+ * [new tag] v1.0 -> v1.0
+ * [new tag] v1.1 -> v1.1
+</pre>
+
+ <p>Si vous voulez juste une seule étiquette, utilisez
+ <code>git fetch <dépôt-distant> tag <nom-étiquette></code>.
+ </p>
+
+ <p>Par défaut, les étiquettes ne sont pas incluses quand
+ vous utilisez la commande <code>push</code> vers un dépôt distant.
+ Pour explicitement les actualiser vous devez inclure l'option
+ <code>--tags</code> quand vous utilisez <code>git push</code>.
+ </p>
+
+ <p class="nutshell">
+ <b>Pou résumer</b>, vous utilisez <code>git tag</code> pour marquer
+ un commit ou un point dans votre dépôt comme important.
+ Cela vous permet de faire référence à ce commit avec
+ quelque chose de plus mémorable qu'un SHA.
+ </p>
+
+ </div>
+ </div>
+
+ <p><a class="page-button next-page" href="/fr/remotes">Aller à Partage et Mise à Jour de Projets »</a></p>
+
diff --git a/fr/cookbook.html b/fr/cookbook.html
new file mode 100644
index 0000000..1e3c289
--- /dev/null
+++ b/fr/cookbook.html
@@ -0,0 +1,12 @@
+---
+layout: fr_reference
+---
+<div class="box">
+ <h2>Git Cookbook</h2>
+ <ul>
+ <li>Rétablir un fichier</li>
+ <li>Récupérer une branche perdue</li>
+ <li>Contribuer à un projet sur GitHub</li>
+ <li>Annuler une fusion</li>
+ </ul>
+</div>
diff --git a/fr/creating/index.html b/fr/creating/index.html
new file mode 100644
index 0000000..41ade81
--- /dev/null
+++ b/fr/creating/index.html
@@ -0,0 +1,145 @@
+---
+layout: fr_reference
+---
+
+<div class="box">
+ <h2>Obtention et Création des Projets</h2>
+ <div class="block">
+ <p>
+ Pour pouvoir faire quoi que ce soit avec Git, vous devez
+ avoir un dépôt Git. C'est là que Git stocke les données des
+ instantanés que vous créez.
+ </p>
+
+ <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 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.
+ </p>
+
+ </div>
+</div>
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-init">docs</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">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 à :
+ </p>
+
+<pre>
+<b>$ cd konnichiwa</b>
+<b>$ ls</b>
+README hello.rb
+</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,
+ 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>
+
+<pre>
+<b>$ git init</b>
+Dépôt Git vide initialisé dans /opt/konnichiwa/.git/
+</pre>
+
+ <p>Maintenant vous pouvez voir qu'il y a un sous-dossier <code>.git</code> dans
+ votre projet. Ceci est votre dossier Git dans lequel toutes les données des
+ instantanés de votre projet sont conservées.
+ </p>
+
+<pre>
+<b>$ ls -a</b>
+. .. .git README hello.rb
+</pre>
+
+ <p>Félicitations, vous avez maintenant une squelette de dépôt Git et vous pouvez
+ maintenant commencer à prendre des instantanés de votre projet.
+ </p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>, vous utilisez <code>git init</code> pour initialiser
+ le contenu d'un dossier existant en un nouveau dépôt Git. Vous pouvez le faire
+ dans n'importe quel dossier à tout moment, localement.</p>
+
+ </div>
+</div>
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-clone">docs</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">copie un dépôt git pour pouvoir le modifier</span>
+ </h2>
+ <div class="block">
+ <p>
+ Si vous avez besoin de collaborer avec quelqu'un sur un projet, ou si
+ vous voulez obtenir une copie d'un projet pour lire ou utiliser son code,
+ vous le clonerez. Vous lancez simplement la commande <code>git clone [url]</code>
+ avec l'URL du projet que vous voulez copier.
+ </p>
+
+<pre>
+<b>$ git clone git://github.com/schacon/simplegit.git</b>
+Clonage dans 'simplegit'...
+remote: Counting objects: 13, done.
+remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
+Réception d'objets: 100% (13/13), 1.63 KiB | 0 bytes/s, fait.
+Résolution des deltas: 100% (2/2), fait.
+Vérification de la connectivité... fait.
+<b>$ cd simplegit/</b>
+<b>$ ls</b>
+README Rakefile <span class="blue">lib</span>
+</pre>
+
+ <p>
+ Cela va copier l'historique complet de ce projet pour que vous l'ayez
+ à disposition localement et vous aurez un dossier de travail de la branche
+ principale de ce projet pour vous permettre de lire le code et commencer à
+ le modifier. Si vous rentrez dans ce nouveau dossier, vous pouvez voir
+ le sous-dossier <code>.git</code> où toutes les données du projet se trouvent.
+ </p>
+
+<pre>
+<b>$ ls -a</b>
+. .. <span class="blue">.git</span> README Rakefile <span class="blue">lib</span>
+<b>$ cd .git</b>
+<b>$ ls</b>
+HEAD description <span class="blue">info</span> packed-refs
+<span class="blue">branches hooks logs refs</span>
+config index <span class="blue">objects</span>
+</pre>
+
+ <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.
+ Si vous voulez quelque chose de différent, vous pouvez l'indiquer à la fin
+ de la commande, après l'URL.
+ </p>
+
+ <p class="nutshell">
+ <strong>Pour résumer</strong>, vous utilisez <code>git clone</code> pour
+ obtenir une copie locale d'un dépôt Git pour pouvoir l'étudier ou le modifier.
+ </p>
+
+ </div>
+</div>
+
+<p><a class="page-button next-page" href="/fr/basic">Aller à Capture d’Instantané Basique »</a></p>
diff --git a/fr/index.html b/fr/index.html
new file mode 100644
index 0000000..4d16e4c
--- /dev/null
+++ b/fr/index.html
@@ -0,0 +1,119 @@
+---
+layout: fr_reference
+---
+<div class="box">
+ <h2>Introduction à Référence Git</h2>
+ <div class="block">
+ <p>
+ Ceci est le site Référence Git. Il a pour but de servir
+ de référence rapide pour apprendre et retenir les commandes
+ les plus importantes et les plus utilisées de Git. Les commandes
+ sont organisées en sections selon le type d'opérations que vous
+ seriez amené à faire, et vous présenteront les options et commandes
+ courantes pour les réaliser.
+ </p>
+ <p>
+ Chaque section pointe vers la section suivante, vous pourrez les suivre
+ à la manière d'un tutoriel. Chaque page pointera également vers
+ une documentation Git plus approfondie comme les pages de manuel
+ officielles ou aux sections appropriées du
+ <a href="http://git-scm.com/book/fr/v2">Livre Pro Git</a>,
+ de cette manière vous pourrez en apprendre plus sur les commandes.
+ Nous commencerons par découvrir comment penser gestion de sources
+ à la manière de Git.
+ </p>
+ </div>
+</div>
+
+<div class="box">
+ <h2>Comment penser à la Git</h2>
+ <div class="block">
+ <p>
+ La première chose à comprendre sur Git est qu'il
+ gère les versions d'une manière totalement différente
+ de Subversion ou Perforce ou tout autre gestionnaire de sources
+ auquel vous seriez habitué. Il est souvent plus simple
+ d'apprendre Git en mettant de côté toute connaissance sur
+ le fonctionnement de la gestion de sources 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 sources. 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 projet projet.bak </pre>
+
+ <p>
+ De cette manière, vous pouvez facilement rétablir des fichiers qui
+ seraient devenus inutilisables plus tard, ou pour voir ce que vous avez changé en
+ comparant l'état du projet actuel avec celui de la copie de sauvegarde.
+ </p>
+
+ <p>
+ Si vous êtes réellement paranoïaque, vous le ferez sûrement souvent,
+ et vous inclurez la date dans le nom de la sauvegarde :
+ </p>
+
+ <pre> $ cp -R projet projet.2010-06-01.bak </pre>
+
+ <p>
+ Dans ce cas, vous aurez un tas d'instantanés de votre projet à
+ disposition comme source de comparaison et d'inspection. Vous pouvez
+ également utiliser cette méthode pour partager de manière plutôt
+ efficace des modifications avec un tiers. Si vous créez une archive compressée
+ de l'état actuel de votre projet et la partagez sur votre site web, d'autres développeurs
+ peuvent la télécharger, modifier votre projet et vous envoyer un correctif
+ assez facilement.
+ </p>
+
+ <pre>
+ $ wget http://exemple.com/projet.2010-06-01.zip
+ $ unzip projet.2010-06-01.zip
+ $ cp -R projet.2010-06-01 projet-ma-copie
+ $ cd projet-ma-copie
+ $ (vous faites des modifications)
+ $ diff projet-ma-copie projet.2010-06-01 > modif.patch
+ $ (email modif.patch)</pre>
+
+ <p>
+ Le développeur original peut alors appliquer le correctif à sa copie
+ du projet et avoir vos modifications. C'est de cette manière
+ que de nombreux projets libres ont collaboré pendant plusieurs
+ années.
+ </p>
+
+ <p>
+ Ceci fonctionne en fait plutôt bien, alors imaginons que nous désirions
+ écrire un outil pour effectuer ce processus basique plus rapidement
+ 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
+ dossier à chaque fois.
+ </p>
+
+ <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 les fichiers de votre projet
+ à ce moment. Ensuite la plupart des commandes travaillent avec ces enregistrements
+ d'état pour comparer leurs différences ou y récupérer du contenu, etc..
+ </p>
+
+ <center><img src="../images/snapshots.png"/></center>
+
+ <p>
+ Si vous pensez à Git comme un outil pour conserver, comparer et fusionner des instantanés
+ de votre projet, il sera plus facile de comprendre ce qui se passe et comment
+ faire différentes choses correctement.
+ </p>
+
+ </div>
+</div>
+
+<p><a class="page-button next-page" href="/fr/creating">Aller à Obtention et Création des Projets »</a></p>
diff --git a/fr/inspect/index.html b/fr/inspect/index.html
new file mode 100644
index 0000000..508c0ca
--- /dev/null
+++ b/fr/inspect/index.html
@@ -0,0 +1,488 @@
+---
+layout: fr_reference
+---
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Visualiser-l-historique-des-validations">livre</a>
+ </span>
+ Inspection et Comparaison
+ </h2>
+ <div class="block">
+ <p>
+ Vous avez désormais plusieurs branches dont vous vous servez pour des
+ besoins temporaires, des fonctionnalités durables et autres. Comment
+ 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
+ commits 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
+ manière deux branches diffèrent ou ce qui a changé entre une version de votre
+ logiciel et une autre.
+ </p>
+ </div>
+</div>
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-log">docs</a>
+ <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">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 commits d'une branche (si vous ne vous
+ en souvenez pas, cela ressemble à : <code>git log brancheA ^brancheB</code>).
+ Cependant, vous pouvez utiliser <code>git log</code> pour rechercher un
+ commit 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
+ nombreuses. Reportez-vous à la documentation officielle pour la liste complète.
+ </p>
+
+ <h4 id="log-author">
+ git log --author
+ <small>recherche uniquement les commits d'un auteur en particulier</small>
+ </h4>
+
+ <p>
+ Pour filtrer l'historique de vos commits suivant seulement ceux effectués
+ par un auteur en particulier, vous pouvez utiliser l'option <code>--author</code>.
+ Par exemple, disons que nous recherchons les commits du code source de Git
+ qui ont été effectués par Linus. Nous exécuterions quelque chose comme
+ <code>git log --author=Linus</code>. La recherche est sensible à la casse
+ et recherchera aussi l'adresse email. L'exemple suivant utilise l'option
+ <code>-[nombre]</code>, qui limite les résultats aux [nombre] derniers
+ commits.
+ </p>
+
+<pre>
+<b>$ git log --author=Linus --oneline -5</b>
+81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
+3bb7256 make "index-pack" a built-in
+377d027 make "git pack-redundant" a built-in
+b532581 make "git unpack-file" a built-in
+112dd51 make "mktag" a built-in
+</pre>
+
+ <h4 id="log-date">
+ git log --since --before
+ <small>filtre les commits suivant leur date</small>
+ </h4>
+
+ <p>
+ Si vous voulez spécifier un intervalle de temps pour filtrer vos commits,
+ vous pouvez utiliser plusieurs options comme <code>--since</code>
+ et <code>--before</code>, ou vous pouvez aussi utiliser <code>--until</code>
+ et <code>--after</code>. Par exemple, pour voir tous les commits 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 commits
+ de fusion) :
+ </p>
+
+<pre>
+<b>$ git log --oneline --before={3.weeks.ago} --after={2010-04-18} --no-merges</b>
+5469e2d Git 1.7.1-rc2
+d43427d Documentation/remote-helpers: Fix typos and improve language
+272a36b Fixup: Second argument may be any arbitrary string
+b6c8d2d Documentation/remote-helpers: Add invocation section
+5ce4f4e Documentation/urls: Rewrite to accomodate transport::address
+00b84e9 Documentation/remote-helpers: Rewrite description
+03aa87e Documentation: Describe other situations where -z affects git diff
+77bc694 rebase-interactive: silence warning when no commits rewritten
+636db2c t3301: add tests to use --format="%N"
+</pre>
+
+ <h4 id="log-grep">
+ git log --grep
+ <small>filtre les commits suivant leur message</small>
+ </h4>
+
+ <p>
+ Vous désireriez peut-être également rechercher les commits avec une certaine
+ phrase comme message de commit. Utilisez <code>--grep</code> pour cela.
+ Disons qu'il y ait un commit qui portait sur la variable d'environnement P4EDITOR
+ et que vous vouliez vous remémorer à quoi ressemblaient ses modificiations—vous
+ pourriez retrouver cet commit avec <code>--grep</code>.
+ </p>
+
+<pre>
+<b>$ git log --grep=P4EDITOR --no-merges</b>
+<span class="yellow">commit 82cea9ffb1c4677155e3e2996d76542502611370</span>
+Author: Shawn Bohrer
+Date: Wed Mar 12 19:03:24 2008 -0500
+
+ git-p4: Use P4EDITOR environment variable when set
+
+ Perforce allows you to set the P4EDITOR environment variable to your
+ preferred editor for use in perforce. Since we are displaying a
+ perforce changelog to the user we should use it when it is defined.
+
+ Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
+ Signed-off-by: Simon Hausmann <simon@lst.de>
+</pre>
+
+ <p>
+ Git va faire un OU logique de tous les arguments <code>--grep</code> et
+ <code>--author</code>. Si vous voulez utiliser <code>--grep</code> et
+ <code>--author</code> pour voir tous les commits qui ont été crééxes
+ par quelqu'un et ont un contenu de message spécifique, vous devez utiliser
+ l'option <code>--all-match</code>. Dans les exemples nous allons utiliser
+ l'option <code>--format</code>, afin de voir qui est l'auteur de chaque commit.
+ </p>
+
+ <p>Si nous recherchons les commits dont le message contient « p4 depo »,
+ nous obtenons ces trois commits :</p>
+
+<pre>
+<b>$ git log --grep="p4 depo" --format="%h %an %s"</b>
+ee4fd1a Junio C Hamano Merge branch 'master' of git://repo.or.cz/git/fastimport
+da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.
+1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
+</pre>
+
+ <p>Si nous ajoutons l'argument <code>--author=Hausmann</code>,
+ au lieu de filtrer les commits de Simon, il va plutôt nous montrer
+ toutes les commtis de Simon ou dont le message contient « p4 depo ».</p>
+
+<pre>
+<b>$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"</b>
+cdc7e38 Simon Hausmann Make it possible to abort the submission of a change to Pe
+f5f7e4a Simon Hausmann Clean up the git-p4 documentation
+30b5940 Simon Hausmann git-p4: Fix import of changesets with file deletions
+4c750c0 Simon Hausmann git-p4: git-p4 submit cleanups.
+0e36f2d Simon Hausmann git-p4: Removed git-p4 submit --direct.
+edae1e2 Simon Hausmann git-p4: Clean up git-p4 submit's log message handling.
+4b61b5c Simon Hausmann git-p4: Remove --log-substitutions feature.
+36ee4ee Simon Hausmann git-p4: Ensure the working directory and the index are cle
+e96e400 Simon Hausmann git-p4: Fix submit user-interface.
+38f9f5e Simon Hausmann git-p4: Fix direct import from perforce after fetching cha
+2094714 Simon Hausmann git-p4: When skipping a patch as part of "git-p4 submit" m
+1ca3d71 Simon Hausmann git-p4: Added support for automatically importing newly ap
+...
+</pre>
+
+ <p>Néanmoins, ajouter <code>--all-match</code> va vous retourner les résultats
+ que vous attendiez :</p>
+
+<pre>
+<b>$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match</b>
+1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
+</pre>
+
+ <h4 id="log-s">
+ git log -S
+ <small>filtre suivant les changements introduits</small>
+ </h4>
+
+ <p>
+ Que faire si vos messages de commits 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
+ de rechercher parmi les modifications de chaque commit pour une certaine
+ chaîne de caractères. Par exemple, si nous voulions trouver quelles
+ commits 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) :
+ </p>
+
+<pre>
+<b>$ git log -Suserformat_find_requirements</b>
+<span class="yellow">commit 5b16360330822527eac1fa84131d185ff784c9fb</span>
+Author: Johannes Gilger
+Date: Tue Apr 13 22:31:12 2010 +0200
+
+ pretty: Initialize notes if %N is used
+
+ When using git log --pretty='%N' without an explicit --show-notes, git
+ would segfault. This patches fixes this behaviour by loading the needed
+ notes datastructures if --pretty is used and the format contains %N.
+ When --pretty='%N' is used together with --no-notes, %N won't be
+ expanded.
+
+ This is an extension to a proposed patch by Jeff King.
+
+ Signed-off-by: Johannes Gilger
+ Signed-off-by: Junio C Hamano
+</pre>
+
+ <h4 id="log-patch">
+ git log -p
+ <small>affiche le correctif introduit par chaque commit</small>
+ </h4>
+
+ <p>
+ Chaque commit est un instantané de votre projet, mais étant donné que
+ chaque commit connaît l'instantané sur lequel il est basé, Git peut toujours
+ calculer la différence et vous l'afficher sous forme de correctif. Cela
+ signifie que pour chaque commit vous pouvez obtenir le correctif que
+ ce commit a introduit dans le projet. Vous pouvez le faire soit
+ en exécutant <code>git show [SHA]</code> avec un SHA spécifique de commit,
+ ou vous pouvez utiliser <code>git log -p</code>, qui dit à Git de mettre le
+ correctif après chaque commit. C'est un très bon moyen de résumer ce
+ qui est arrivé sur une branche ou entre des commits.
+ </p>
+
+<pre>
+<b>$ git log -p --no-merges -2</b>
+<span class="yellow">commit 594f90bdee4faf063ad07a4a6f503fdead3ef606</span>
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 15:46:55 2010 +0200
+
+ reverted to old class name
+
+<span class="umber">diff --git a/ruby.rb b/ruby.rb
+index bb86f00..192151c 100644
+--- a/ruby.rb
++++ b/ruby.rb</span>
+<span class="lblue">@@ -1,7 +1,7 @@</span>
+<span class="red">-class HiWorld</span>
+<span class="green">+class HelloWorld</span>
+ def self.hello
+ puts "Hello World from Ruby"
+ end
+ end
+
+<span class="red">-HiWorld.hello</span>
+<span class="green">+HelloWorld.hello</span>
+
+<span class="yellow">commit 3cbb6aae5c0cbd711c098e113ae436801371c95e</span>
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 12:58:53 2010 +0200
+
+ fixed readme title differently
+
+<span class="umber">diff --git a/README b/README
+index d053cc8..9103e27 100644
+--- a/README
++++ b/README</span>
+<span class="lblue">@@ -1,4 +1,4 @@</span>
+<span class="red">-Hello World Examples</span>
+<span class="green">+Many Hello World Examples</span>
+ ======================
+
+ This project has examples of hello world in
+</pre>
+
+ <p>C'est un très bon moyen de résumer les changements ou passer en revue
+ une série de commits avant de les fusionner ou de publier quoi que ce soit.</p>
+
+ <h4 id="log-stat">
+ git log --stat
+ <small>affiche un résumé des modifications introduites par chaque commit</small>
+ </h4>
+
+ <p>Si vous trouvez l'option <code>-p</code> trop verbeuse, vous pouvez résumer
+ les changements avec <code>--stat</code> à la place. Voici la même sortie du
+ journal avec <code>--stat</code> à la place de <code>-p</code>.</p>
+
+<pre>
+<b>$ git log --stat --no-merges -2</b>
+<span class="yellow">commit 594f90bdee4faf063ad07a4a6f503fdead3ef606</span>
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 15:46:55 2010 +0200
+
+ reverted to old class name
+
+ ruby.rb | 4 <span class="green">++</span><span class="red">--</span>
+ 1 files changed, 2 insertions(+), 2 deletions(-)
+
+<span class="yellow">commit 3cbb6aae5c0cbd711c098e113ae436801371c95e</span>
+Author: Scott Chacon <schacon@gmail.com>
+Date: Fri Jun 4 12:58:53 2010 +0200
+
+ fixed readme title differently
+
+ README | 2 <span class="green">+</span><span class="red">-</span>
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+</pre>
+
+ <p>Basiquement les mêmes informations, mais plus succintement—vous pouvez
+ toujours voir les différences et queles fichiers ont été modifiés.</p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-diff">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Git-distribu%C3%A9-Maintenance-d-un-projet#Déterminer-les-modifications-introduites">livre</a>
+ </span>
+ <a name="diff">git diff</a>
+ <span class="desc"></span>
+ </h2>
+
+ <div class="block">
+
+ <p>Enfin, pour voir les changements absolus entre deux instantanés,
+ vous pouvez utiliser la commande <code>git diff</code>. C'est utilisé
+ 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 moment donné passé dans l'historique.
+ Voyons chacune de ces situations.</p>
+
+ <p>Pour voir ce qui a changé depuis la dernière publication, vous pouvez
+ simplement exécuter <code>git diff [version]</code> (ou tout autre étiquette
+ attribuée à la publication). Par exemple, si vous voulez voir ce qui a changé
+ dans votre projet depuis la version v0.9, vous pouvez exécuter
+ <code>git diff v0.9</code>.
+ </p>
+
+<pre>
+<b>$ git diff v0.9</b>
+<span class="umber">diff --git a/README b/README
+index d053cc8..d4173d5 100644
+--- a/README
++++ b/README</span>
+<span class="lblue">@@ -1,4 +1,4 @@</span>
+<span class="red">-Hello World Examples</span>
+<span class="green">+Many Hello World Lang Examples</span>
+ ======================
+
+ This project has examples of hello world in
+<span class="umber">diff --git a/ruby.rb b/ruby.rb
+index bb86f00..192151c 100644
+--- a/ruby.rb
++++ b/ruby.rb</span>
+<span class="lblue">@@ -1,7 +1,7 @@</span>
+<span class="red">-class HiWorld</span>
+<span class="green">+class HelloWorld</span>
+ def self.hello
+ puts "Hello World from Ruby"
+ end
+ end
+
+<span class="red">-HiWorld.hello</span>
+<span class="green">+HelloWorld.hello</span>
+</pre>
+
+ <p>Tout comme <code>git log</code>, vous pouvez utiliser l'option
+ <code>--stat</code> avec.</p>
+
+<pre>
+<b>$ git diff v0.9 --stat</b>
+ README | 2 +-
+ ruby.rb | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+</pre>
+
+ <p>Pour comparer deux branches divergentes, néanmoins, vous pouvez exécuter
+ 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é
+ à la pointe de la branche brancheA en l'instantané de la pointe 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
+ 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
+ à brancheB qui ne sont pas dans brancheA, vous voulez donc vraiment les différences
+ là où les deux branches ont divergé et la pointe de brancheB. Donc,
+ si notre historique ressemble à ça :</p>
+
+<pre>
+<b>$ git log --graph --oneline --decorate --all</b>
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+| * 1834130 (erlang) added haskell
+| * ab5ab4c added erlang
+|/
+* 8d585ea Merge branch 'fix_readme'
+...
+</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>
+ ne nous afficherait pas la bonne chose.</p>
+
+<pre>
+<b>$ git diff --stat master erlang</b>
+ erlang_hw.erl | 5 +++++
+ haskell.hs | 4 ++++
+ ruby.rb | 4 ++--
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+</pre>
+
+ <p>Vous voyez que cela a ajouté les fichiers erlang et haskell, qui est ce
+ que nous avons fait dans cette branche, mais la sortie revient aussi sur les
+ changements du fichier ruby que nous avons effectué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
+ résultat attendu en faisant la différence entre le commit commun depuis lequel
+ elles ont divergé :</p>
+
+<pre>
+<b>$ git diff --stat 8d585ea erlang</b>
+ erlang_hw.erl | 5 +++++
+ haskell.hs | 4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+</pre>
+
+ <p>C'est ce que nous recherchons, mais nous ne désirons pas avoir à nous
+ souvenir à chaque fois depuis quel commit les deux branches ont divergé.
+ 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 quel est le commit commun
+ (aussi connu sous le nom de « base de fusion ») entre les deux commits et
+ afficher les modifications en se basant sur celui-ci.</p>
+
+<pre>
+<b>$ git diff --stat master erlang</b>
+ erlang_hw.erl | 5 +++++
+ haskell.hs | 4 ++++
+ ruby.rb | 4 ++--
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+<b>$ git diff --stat master...erlang</b>
+ erlang_hw.erl | 5 +++++
+ haskell.hs | 4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+</pre>
+
+ <p>Quasiment à chaque fois que vous voudrez comparer deux branches, vous voudrez
+ utiliser la syntaxe du triple-point, parce-qu'elle vous donnera sûrement toujours
+ ce que vous désirez.
+ </p>
+
+ <p>En guise de bonus, vous pouvez aussi faire calculer manuellement par Git quelle
+ serait la base de fusion (le premier commit parent commun) entre deux commits
+ 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>
+
+<pre>
+<b>$ git diff --stat $(git merge-base master erlang) erlang</b>
+ erlang_hw.erl | 5 +++++
+ haskell.hs | 4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+</pre>
+
+ <p>Vous préférerez peut-être utiliser la forme simple de la syntaxe néanmoins.</p>
+
+
+ <p class="nutshell">
+ <b>Pour résumer</b> vous pouvez utiliser <code>git diff</code> pour voir
+ comment un projet a changé depuis un moment donné ou pour voir quel travail
+ est contenu dans une branche depuis qu'elle a divergé d'une autre. Utilisez
+ toujours <code>git diff brancheA...brancheB</code> pour inspecter brancheB
+ par rapport à brancheA pour vous simplifier la vie.
+ </p>
+
+ </div>
+ </div>
+
+ <p>Et c'est la fin ! Pour plus d'informations, veuillez lire le
+ <a href="http://git-scm.com/book/fr/">Livre Pro Git</a>.</p>
diff --git a/fr/remotes/index.html b/fr/remotes/index.html
new file mode 100644
index 0000000..e52269e
--- /dev/null
+++ b/fr/remotes/index.html
@@ -0,0 +1,459 @@
+---
+layout: fr_reference
+---
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Travailler-avec-des-d%C3%A9p%C3%B4ts-distants">livre</a>
+ </span>
+ Partage et Mise à Jour de Projets
+ </h2>
+ <div class="block">
+ <p>
+ Git n'a pas de serveur central comme Subversion. Toutes les commandes
+ jusqu'à présent ont été exécutées localement, actualisant seulement la base
+ de données locale. Pour collaborer avec d'autres développeurs sous Git,
+ vous devez mettre toutes ces données sur un serveur auquel les autres
+ ont accès. Git rend cela possible en synchronisant vos données avec un
+ autre dépôt. Il n'y a pas de réelle différence entre un serveur et un
+ client—un dépôt Git est un dépôt Git et vous pouvez synchroniser
+ des dépôts indifféremment entre eux facilement.
+ </p>
+
+ <p>Dès que vous avez un dépôt Git, que ce soit un que vous hébergez sur votre
+ propre serveur, ou un dépôt hébergé chez un tiers comme GitHub, vous pouvez
+ dire à Git soit de pousser toutes données que vous avez qui ne sont pas
+ présentes sur le serveur distant, soit demander à Git de récupérer en local
+ les différences depuis l'autre dépôt.
+ </p>
+
+ <p>Vous pouvez le faire quand vous êtes en ligne, cela n'a pas à être fait
+ en même temps qu'un <code>commit</code> ou tout autre commande. Généralement
+ vous ferez un certains nombres de commits localement, puis vous récupérerez
+ les données depuis le dépôt partagé distant à partir duquel vous avez cloné
+ le projet pour être à jour, puis vous pousserez vos modifications en ligne.</p>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous pouvez actualiser votre projet avec <code>git fetch</code>
+ et partager vos modifications avec <code>git push</code>. Vous pouvez gérer vos
+ dépôts distants avec <code>git remote</code>.
+ </p>
+ </div>
+</div>
+
+<div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-remote">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Travailler-avec-des-d%C3%A9p%C3%B4ts-distants#Afficher-les-dépôts-distants">livre</a>
+ </span>
+ <a name="remote">git remote</a>
+ <span class="desc">liste, ajoute et supprime les alias de dépôts distants</span>
+ </h2>
+
+ <div class="block">
+
+ <p>Contrairement aux systèmes de gestion de versions centralisés qui ont un client
+ qui est très différent du serveur, les dépôts Git sont tout simplement équivalents
+ et vous les synchronisez simplement entre eux. Cela simplifie la possibilité
+ d'avoir plus d'un dépôt distant—vous pouvez en avoir certains en lecture seule
+ ainsi que d'autres accessibles en écriture.</p>
+
+ <p>Afin de ne pas avoir à donner l'URL complète d'un dépôt distant à chaque
+ fois que vous désirez vous synchroniser avec, Git stocke un alias ou diminutif
+ pour chaque URL de dépôt distant qui vous intéresse. Vous utilisez la commande
+ <code>git remote</code> pour gérer cette liste de dépôts distants qui vous
+ intéresse.</p>
+
+ <h4 id="remote-list">
+ git remote
+ <small>liste vos alias distants</small>
+ </h4>
+
+ <p>Sans argument, Git va simplement vous afficher les alias de dépôt distants
+ qu'ils stockent. Par défaut, si vous avez cloné le projet (par opposition
+ à en créer un nouveau localement), Git va automatiquement ajouter l'URL
+ de ce dépôt source que vous avez cloné sous le nom « origin ». SI vous exécutez
+ la commande avec l'option <code>-v</code>, vous pouvez voir
+ l'URL réelle de chaque alias.</p>
+
+<pre>
+<b>$ git remote</b>
+origin
+<b>$ git remote -v</b>
+origin git@github.com:github/git-reference.git (fetch)
+origin git@github.com:github/git-reference.git (push)
+</pre>
+
+ <p>Vous voyez l'URL ici en double car Git permet d'avoir des URLs
+ différentes pour pousser et récupérer pour chaque dépôt au cas où
+ vous vouliez utiliser des protocoles différents en lecture
+ et en écriture.</p>
+
+ <h4 id="remote-add">
+ git remote add
+ <small>ajoute un nouveau dépôt distant à votre projet</small>
+ </h4>
+
+ <p>Si vous voulez partager un dépôt créé localement, ou vous voulez
+ récupérer les contributions depuis le dépôt d'un tiers—si vous voulez
+ interagir de n'importe quelle manière avec un nouveau dépôt, le plus simple
+ est généralement de l'ajouter comme dépôt distant. Vous faites cela en
+ exécutant <code>git remote add [alias] [url]</code>. Cela ajoute
+ l'<code>[url]</code> en local en tant que dépôt distant sous le nom
+ <code>[alias]</code>.</p>
+
+ <p>Par exemple, si nous voulons partager notre programme Hello World avec
+ le reste du monde, nous pouvons créer un nouveau dépôt sur un serveur
+ (utilisons Github comme exemple), vous devriez obtenir une URL,
+ dans notre cas « git@github.com:schacon/hw.git ». Pour l'ajouter à notre
+ projet afin de pouvoir y pousser et récupérer des mises à jour depuis celui-ci
+ nous ferions :</p>
+
+<pre>
+<b>$ git remote</b>
+<b>$ git remote add github git@github.com:schacon/hw.git</b>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+</pre>
+
+ <p>Tout comme la dénomination des branches, le nommage des alias de dépôts
+ distants est arbitraire—tout comme « master » n'a aucune signification spéciale
+ mais est très largement utilisé car <code>git init</code> le configure par défaut,
+ « origin » est souvent utilisé comme nom de dépôt distant car
+ <code>git clone</code> le configure par défaut comme URL source du clonage. Dans
+ notre cas nous allons appeler ce dépôt distant « github », mais vous pourriez le
+ nommer comme bon vous semblerait.
+ </p>
+
+ <h4 id="remote-remove">
+ git remote rm
+ <small>enlève un alias existant de dépôt distant</small>
+ </h4>
+
+ <p>Si vous avez besoin d'enlever un dépôt distant—vous ne l'utilisez plus, le projet
+ n'existe plus, etc—vous pouvez l'enlever avec <code>git remote rm [alias]</code>.</p>
+
+<pre>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+<b>$ git remote add origin git://github.com/pjhyett/hw.git</b>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+origin git://github.com/pjhyett/hw.git (fetch)
+origin git://github.com/pjhyett/hw.git (push)
+<b>$ git remote rm origin</b>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+</pre>
+
+ <h4 id="remote-rename">
+ git remote rename [ancien-alias] [nouvel-alias]
+ <small>renomme des alias de dépôt distant</small>
+ </h4>
+
+ <p>Si vous voulez renommer des alias de dépôt distant sans avoir à les supprimer puis les
+ ajouter à nouveau vous pouvez le faire en exécutant
+ <code>git remote rename [ancien-alias] [nouvel-alias]</code>. Cela va vous permettre
+ de modifier le nom en cours d'utilisation du dépôt distant.</p>
+
+<pre>
+<b>$ git remote add github git@github.com:schacon/hw.git</b>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+<b>$ git remote rename github origin</b>
+<b>$ git remote -v</b>
+origin git@github.com:schacon/hw.git (fetch)
+origin git@github.com:schacon/hw.git (push)
+</pre>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, avec <code>git remote</code> vous pouvez lister vos dépôts
+ distants et toute URL que ce dépôt utilise. Vous pouvez utiliser
+ <code>git remote add</code> pour ajouter de nouveaux dépôts distants,
+ <code>git remote rm</code> pour en supprimer ou
+ <code>git remote rename [ancien-alias] [nouvel-alias]</code> pour les renommer.
+ </p>
+
+ <h4 id="remote-update">
+ git remote set-url
+ <small>actualise une URL distante existante</small>
+ </h4>
+
+ <p>Si vous aviez besoin d'actualiser l'URL d'un dépôt distant, vous
+ pouvez le faire avec la commande <code>git remote set-url</code>.
+ </p>
+
+<pre>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+origin git://github.com/pjhyett/hw.git (fetch)
+origin git://github.com/pjhyett/hw.git (push)
+<b>$ git remote set-url origin git://github.com/github/git-reference.git</b>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+origin git://github.com/github/git-reference.git (fetch)
+origin git://github.com/github/git-reference.git (push)
+</pre>
+
+ <p>De plus, vous pouvez définir une URL différente pour pousser quand
+ vous ajoutez le drapeau <code>--push</code>. Cela vous permet de récupérer
+ depuis un dépôt mais de pousser vers un autre tout en leur donnant le
+ même alias.
+ </p>
+
+<pre>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+origin git://github.com/github/git-reference.git (fetch)
+origin git://github.com/github/git-reference.git (push)
+<b>$ git remote set-url --push origin git://github.com/pjhyett/hw.git</b>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+origin git://github.com/github/git-reference.git (fetch)
+origin git://github.com/pjhyett/hw.git (push)
+</pre>
+
+ <p>En interne, la commande <code>git remote set-url</code> exécute
+ <code>git config remote</code>, mais avec l'avantage de vous signaler
+ en retour toute erreur. <code>git config remote</code> d'un autre côté,
+ va échouer en silence si vous avez mal tapé un argument ou une option
+ pour ne rien définir au final.
+ </p>
+
+ <p>Par exemple, nous allons mettre à jour le dépôt distant <code>github</code>
+ mais à la place y faire référence en tant que <code>guhflub</code> à chaque
+ invocation.
+ </p>
+
+<pre>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+origin git://github.com/github/git-reference.git (fetch)
+origin git://github.com/github/git-reference.git (push)
+<b>$ git config remote.guhflub git://github.com/mojombo/hw.git</b>
+<b>$ git remote -v</b>
+github git@github.com:schacon/hw.git (fetch)
+github git@github.com:schacon/hw.git (push)
+origin git://github.com/github/git-reference.git (fetch)
+origin git://github.com/github/git-reference.git (push)
+<b>$ git remote set-url guhflub git://github.com/mojombo/hw.git</b>
+fatal: No such remote 'guhflub'
+</pre>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous pouvez mettre à jour les emplacements de vos
+ dépôts distants avec <code>git remote set-url</code>. Vous pouvez aussi définir des URLs
+ différentes pour pousser et récupérer sous le même nom d'alias de dépôt distant.
+ </p>
+
+ </div>
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-fetch">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Travailler-avec-des-d%C3%A9p%C3%B4ts-distants#Récupérer-et-tirer-depuis-des-dépôts-distants">livre</a>
+ </span>
+ <a name="fetch">git fetch</a>
+ <span class="desc">récupère de nouvelles branches et données depuis un dépôt distant</span>
+ </h2>
+
+ <br/>
+
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-pull">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Travailler-avec-des-d%C3%A9p%C3%B4ts-distants#Récupérer-et-tirer-depuis-des-dépôts-distants">livre</a>
+ </span>
+ <a name="pull">git pull</a>
+ <span class="desc">récupère depuis un dépôt distant et essaye de fusionner dans la branche courante</span>
+ </h2>
+
+ <div class="block">
+
+ <p>Git a deux commandes pour se mettre à jour depuis un dépôt distant.
+ <code>git fetch</code> va vous synchroniser avec un autre dépôt, récupérant
+ en local tout donnée non présente en local et vous donnant des marqueurs sur où
+ chaque branche sur ce dépôt distant en était au momemt de la synchronisation.
+ Celles-ci sont appelées « branches distantes » et sont identiques aux branches locales
+ mis à part que Git ne vous autorisera pas d'y faire un checkout—par contre, vous pouvez
+ fusionner avec, les comparer à d'autres branches, exécuter des journaux d'historique
+ dessus, etc. Vous faites toutes ces opérations en local une fois votre synchronisation
+ faite.
+ </p>
+
+ <p>La seconde commande qui va récupérer en local des données est la commande
+ <code>git pull</code>. Cette commande va concrètement exécuter un <code>git fetch</code>
+ immédiatemment suivi d'un <code>git merge</code> de la branche de ce dépôt distant
+ qui est suivie par toute branche courante dans laquelle vous êtes. Exécuter les commandes
+ <code>fetch</code> et <code>merge</code> séparément est source de moins de magie et
+ de moins de problèmes, mais si vous aimez le principe de <code>pull</code>,
+ vous pouvez le retrouver de manière plus détaillée dans la
+ <a target="new" href="http://git-scm.com/docs/git-pull">documentation officielle</a>.
+ </p>
+
+ <p>Partant du principe que vous avez un dépôt distant fonctionnel et que vous voulez tirer
+ en local des mises à jour, vous exécuteriez en premier <code>git fetch [alias]</code>
+ pour dire à Git de récupérer en local toutes les données du dépôt que vous n'avez pas,
+ puis vous exécuteriez <code>git merge [alias]/[branche]</code> pour fusionner dans la
+ branche courante tout ce qu'il y de nouveau sur le serveur (par exemple si quelqu'un
+ a poussé entretemps). Au final, si vous travailliez sur un projet Hello World avec
+ plusieurs autres personnes et que vous vouliez récupérer toutes modifications qui
+ ont été poussées depuis votre dernière connexion, vous feriez quelque chose comme :</p>
+
+<pre>
+<b>$ git fetch github</b>
+remote: Counting objects: 4006, done.
+remote: Compressing objects: 100% (1322/1322), done.
+remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
+Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
+Resolving deltas: 100% (1526/1526), completed with 387 local objects.
+From github.com:schacon/hw
+ 8e29b09..c7c5a10 master -> github/master
+ 0709fdc..d4ccf73 c-langs -> github/c-langs
+ 6684f82..ae06d2b java -> github/java
+ * [new branch] ada -> github/ada
+ * [new branch] lisp -> github/lisp
+</pre>
+
+ <p>Dans cet exemple nous pouvons voir que depuis notre dernière synchronisation
+ avec le dépôt distant, cinq branches ont été créées ou mises à jour. Les
+ branches « ada » et « lisp » sont nouvelles, alors que les branches « master »,
+ « c-langs » et « java » ont été actualisées. Dans notre scénario exemple,
+ les autres développeurs poussent leurs modifications dans des branches distantes
+ pour revue avant d'être fusionnées dans « master ».
+ </p>
+
+ <p>Vous pouvez observer ce que Git met en place. La branche « master » sur le dépôt
+ distant devient une branche appelée « github/master » en local. De cette manière
+ vous pouvez fusionner la branche « master » de ce dépôt distant dans la branche locale
+ « master » en exécutant <code>git merge github/master</code>. Ou vous pouvez voir
+ quelles sont les nouveaux commits en exécutant <code>git log github/master ^master</code>.
+ Si votre dépôt distant est nommé « origin » il sera plutôt nommé <code>origin/master</code>.
+ Quasiment toute commande utilisable sur les branches locales est utilisable également
+ sur les branches distantes.
+ </p>
+
+ <p>Si vous avez plus d'un dépôt distant, vous pouvez plutôt récupérer depuis un dépôt
+ spécifique en exécutant <code>git fetch [alias]</code> ou vous pouvez dire à Git
+ de se synchroniser avec tous les dépôts distants en exécutant <code>git fetch --all</code>.
+ </p>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous exécutez <code>git fetch [alias]</code> pour synchroniser
+ votre dépôt avec un dépôt distant, en récupérant toutes les données du dépôt
+ distant qui ne sont pas référencées dans une branche locale pour les fusionner
+ ou autre.
+ </p>
+
+ </div>
+
+ </div>
+
+ <div class="box">
+ <h2>
+ <span class="docs">
+ <a target="new" href="http://git-scm.com/docs/git-push">docs</a>
+ <a target="new" href="http://git-scm.com/book/fr/Les-bases-de-Git-Travailler-avec-des-d%C3%A9p%C3%B4ts-distants#Pousser-son-travail-sur-un-dépôt-distant">livre</a>
+ </span>
+ <a name="push">git push</a>
+ <span class="desc">pousse vos nouvelles branches et données vers un dépôt distant</span>
+ </h2>
+
+ <div class="block">
+ <p>Pour partager vos sympathiques commits avec des tiers, vous avez besoin de pousser
+ vos modifications vers un dépôt distant. Pour cela, vous exécutez
+ <code>git push [alias] [branche]</code> qui va tenter de faire de votre [branche]
+ une nouvelle [branche] sur le dépôt distant [alias]. Essayons de le faire en commençant
+ par pousser notre branche « master » vers le dépôt distant « github » créé précédemment.</p>
+
+<pre>
+<b>$ git push github master</b>
+Counting objects: 25, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (25/25), done.
+Writing objects: 100% (25/25), 2.43 KiB, done.
+Total 25 (delta 4), reused 0 (delta 0)
+To git@github.com:schacon/hw.git
+ * [new branch] master -> master
+</pre>
+
+ <p>Plutôt simple. Désormais si quelqu'un clone ce dépôt il va obtenir exactement
+ tous ses commits et tout son historique.</p>
+
+ <p>Comment faire si vous avez une branche spécifique comme la branche « erlang »
+ créée précédemment et que vous vouliez just partager celle-ci ? Vous pouvez
+ uniquement pousser cette branche à la place.</p>
+
+<pre>
+<b>$ git push github erlang</b>
+Counting objects: 7, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (6/6), 652 bytes, done.
+Total 6 (delta 1), reused 0 (delta 0)
+To git@github.com:schacon/hw.git
+ * [new branch] erlang -> erlang
+</pre>
+
+ <p>Désormais quand quelqu'un clonera ou récupérera depuis ce dépôt, elle aura
+ une branche « erlang » qu'elle pourra étudier et fusionner. Vous pouvez pousser
+ toute branche de cette manière vers n'importe quel dépôt distant auquel
+ vous avez accès en écriture. Si votre branche est déjà sur le serveur,
+ Git tentera de la mettre à jour. Si elle n'est pas présente, Git l'ajoutera.</p>
+
+ <p>Le dernier problème courant que vous risquez de rencontrer en poussant vers
+ des branches distantes est dans le cas où quelqu'un pousse en même temps.
+ Si vous et une autre développeuse clone au même moment, vous créez chacun
+ vos validations, puis elle pousse et enfin vous essayez de pousser à votre tour,
+ Git va par défaut refuser que vous écrasiez ses modifications. Au lieu de ça,
+ Git va simplement exécuter un <code>git log</code> de la branche sur laquelle
+ vous essayez de pousser et s'assurer qu'il peut trouver l'extrémité courante
+ de la branche du serveur dans l'historique de ce que vous poussez. S'il ne
+ peut voir ce qu'il trouve sur le serveur dans votre historique, il en conclut
+ que vous n'êtes pas à jour et ne va pas accepter que vous poussiez. Pour bien
+ faire, vous devriez récupérer, fusionner puis pousser à nouveau—pour être sûr
+ de prendre ses modifications en compte.</p>
+
+ <p>Voici ce qui arrive lorsque vous essayez de pousser une branche vers une branche
+ distante qui a été mise à jour en même temps :</p>
+
+<pre>
+<b>$ git push github master</b>
+To git@github.com:schacon/hw.git
+ ! [rejected] master -> master (non-fast-forward)
+error: failed to push some refs to 'git@github.com:schacon/hw.git'
+To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes before pushing again. See the 'Note about
+fast-forwards' section of 'git push --help' for details.
+</pre>
+
+ <p>Vous pouvez corriger cela en exécutant <code>git fetch github; git merge github/master</code>
+ puis en poussant à nouveau.
+ </p>
+
+ <p class="nutshell">
+ <b>Pour résumer</b>, vous exécutez <code>git push [alias] [branche]</code> pour actualiser
+ une branche distante avec vos modifications locales. Cela va prendre le contenu de
+ votre [branche] et le pousser pour en faire la [branche] sur le dépôt distant, si possible.
+ Si quelqu'un a poussé depuis la dernière fois que vous avez récupéré et mis à jour,
+ le serveur Git va refuser que vous poussiez tant que vous n'êtes pas à jour.
+ </p>
+
+ </div>
+ </div>
+
+ <p><a class="page-button next-page" href="/fr/inspect">Aller à Inspection et Comparaison »</a></p>