Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Reviewing fr/index.html
  • Loading branch information
humboldtux committed Feb 28, 2016
commit 3b788c87ecd9fa02e650ce2a2ccb4ce83fdd3b29
57 changes: 28 additions & 29 deletions fr/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -9,17 +9,17 @@ <h2>Introduction à Référence Git</h2>
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 tenté de faire, et vous présenteront les options et commandes
habituelles pour réaliser ces tâches usuelles.
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 suivre
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 code source
Nous commencerons par découvrir comment penser gestion de sources
à la manière de Git.
</p>
</div>
Expand All @@ -31,55 +31,54 @@ <h2>Comment penser à la Git</h2>
<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 code source
auquel vous pourriez être habitué. Il est souvent plus simple
d'apprendre Git en essayant d'oublier toute assertion sur
le fonctionnement de la gestion de versions et d'essayer d'y penser
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 code source. Comment gériez-vous simplement différentes versions
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 project project.bak </pre>
<pre> $ cp -R projet projet.bak </pre>

<p>
De cette manière, vous pouvez facilement rétablir des fichiers qui
deviendraient inutilisables plus tard, ou pour voir ce que vous avez changé en
comparant ce à quoi le projet ressemble maintenant avec ce à quoi il
ressemblait lorsque vous l'avez copié.
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 peut-être souvent,
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 project project.2010-06-01.bak </pre>
<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 compressez votre
projet à un certain état et le mettez sur votre site web, d'autres développeurs
peuvent le télécharger, le modifier et vous envoyer un correctif
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://example.com/project.2010-06-01.zip
$ unzip project.2010-06-01.zip
$ cp -R project.2010-06-01 project-my-copy
$ cd project-my-copy
$ (change something)
$ diff project-my-copy project.2010-06-01 > change.patch
$ (email change.patch)</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
Expand All @@ -89,7 +88,7 @@ <h2>Comment penser à la Git</h2>
</p>

<p>
Ceci fonctionne en fait plutôt bien, alors disons que nous désirons
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
Expand All @@ -103,15 +102,15 @@ <h2>Comment penser à la Git</h2>
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 voir comment ils différent ou y récupérer du contenu, etc.
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 et comparer et fusionner des instantanés
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érents choses correctement.
faire différentes choses correctement.
</p>

</div>
Expand Down