Skip to content
This repository
Browse code

[fr] Windows quotes.

Add a warning on the caveats of using the Windows system console.
  • Loading branch information...
commit 93c71bff2bc4e491f29df7eb92078004c71a83a1 1 parent bc3f922
Philippe Lhoste authored December 10, 2012
15  fr/01-introduction/01-chapter1.markdown
Source Rendered
@@ -218,11 +218,11 @@ Par exemple, si vous avez un système d'exploitation qui utilise yum (tel que Fe
218 218
 
219 219
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
220 220
 	  libz-dev libssl-dev
221  
-	
  221
+
222 222
 Quand vous avez toutes les dépendances nécessaires, vous pouvez poursuivre et télécharger la dernière version de Git depuis le site :
223 223
 
224 224
 	http://git-scm.com/download
225  
-	
  225
+
226 226
 Puis, compiler et installer :
227 227
 
228 228
 	$ tar -zxf git-1.7.2.2.tar.gz
@@ -233,7 +233,7 @@ Puis, compiler et installer :
233 233
 Après ceci, vous pouvez obtenir Git par Git lui-même pour les mises à jour :
234 234
 
235 235
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
236  
-	
  236
+
237 237
 ### Installation sur Linux ###
238 238
 
239 239
 Si vous souhaitez installer Git sur Linux via un installateur d'application, vous pouvez généralement le faire via le système de gestion de paquet de base fourni avec votre distribution.
@@ -272,6 +272,11 @@ Téléchargez simplement le fichier exe d'installateur depuis la page Google Cod
272 272
 
273 273
 Après son installation, vous avez à la fois la version en ligne de commande (avec un client SSH utile pour la suite) ou l'interface graphique standard.
274 274
 
  275
+Note sur l'usage sous Windows :
  276
+vous devriez utiliser Git avec la ligne de command fournie par msysGit (style Unix), car elle permet d'utiliser les lignes de commandes complexes données dans ce livre.
  277
+Si vous devez, pour une raison quelconque, utiliser la ligne de commande native de Windows (console système), vous devez utiliser des guillemets au lieu des apostrophes pour délimiter les paramètres avec des espaces.
  278
+Et vous devez délimiter avec ces guillemets les paramètres finissant avec l'accent circonflexe (^) s'ils sont en fin de ligne, car c'est un symbole de continuation de Windows.
  279
+
275 280
 ## Paramétrage à la première utilisation de Git ##
276 281
 
277 282
 Maintenant que vous avez installé Git sur votre système, vous voudrez personnaliser votre environnement Git.
@@ -310,7 +315,7 @@ Par défaut, Git utilise l'éditeur configuré au niveau système, qui est gén
310 315
 Si vous souhaitez utiliser un éditeur de texte différent, comme Emacs, vous pouvez entrer ce qui suit :
311 316
 
312 317
 	$ git config --global core.editor emacs
313  
-	
  318
+
314 319
 ### Votre outil de différences ###
315 320
 
316 321
 Une autre option utile est le paramétrage de l'outil de différences à utiliser pour la résolution des conflits de fusion.
@@ -350,7 +355,7 @@ Si vous avez besoin d'aide pour utiliser Git, il y a trois moyens d'obtenir les
350 355
 	$ git help <verbe>
351 356
 	$ git <verbe> --help
352 357
 	$ man git-<verbe>
353  
-	
  358
+
354 359
 Par exemple, vous pouvez obtenir la page de manuel pour la commande config en lançant :
355 360
 
356 361
 	$ git help config
131  fr/02-git-basics/01-chapter2.markdown
Source Rendered
@@ -50,9 +50,9 @@ Ceci crée un répertoire nommé `grit`, initialise un répertoire `.git` à l'i
50 50
 Si vous examinez le nouveau répertoire `grit`, vous y verrez les fichiers du projet, prêt à être modifiés ou utilisés.
51 51
 Si vous souhaitez cloner le dépôt dans un répertoire nommé différemment, vous pouvez spécifier le nom dans une option supplémentaire de la ligne de commande :
52 52
 
53  
-	$ git clone git://github.com/schacon/grit.git mygrit
  53
+	$ git clone git://github.com/schacon/grit.git mongrit
54 54
 
55  
-Cette commande réalise la même chose que la précédente, mais le répertoire cible s'appelle `mygrit`.
  55
+Cette commande réalise la même chose que la précédente, mais le répertoire cible s'appelle `mongrit`.
56 56
 
57 57
 Git dispose de différents protocoles de transfert que vous pouvez utiliser.
58 58
 L'exemple précédent utilise le protocole `git://`, mais vous pouvez aussi voir `http(s)://` ou `utilisateur@serveur:/chemin.git`, qui utilise le protocole de transfert SSH.
@@ -102,8 +102,8 @@ Si ce fichier n'existait pas auparavant, et que vous lancez la commande `git sta
102 102
 	#	LISEZMOI
103 103
 	nothing added to commit but untracked files present (use "git add" to track)
104 104
 
105  
-Vous pouvez constater que votre nouveau fichier `LISEZMOI` n'est pas en suivi de version, car il apparaît dans la section "Untracked files" de l'état de la copie de travail.
106  
-"Untracked" signifie simplement que Git détecte un fichier qui n'était pas présent dans le dernier instantané ; Git ne le placera sous suivi de version que quand vous lui indiquerez de le faire.
  105
+Vous pouvez constater que votre nouveau fichier `LISEZMOI` n'est pas en suivi de version, car il apparaît dans la section « Untracked files » de l'état de la copie de travail.
  106
+« Untracked » signifie simplement que Git détecte un fichier qui n'était pas présent dans le dernier instantané ; Git ne le placera sous suivi de version que quand vous lui indiquerez de le faire.
107 107
 Ce comportement permet de ne pas placer accidentellement sous suivi de version des fichiers binaires générés ou d'autres fichiers que vous ne voulez pas inclure.
108 108
 Mais vous voulez inclure le fichier `LISEZMOI` dans l'instantané, alors commençons à suivre ce fichier.
109 109
 
@@ -114,7 +114,7 @@ Pour commencer à suivre le fichier `LISEZMOI`, vous pouvez entrer ceci :
114 114
 
115 115
 	$ git add LISEZMOI
116 116
 
117  
-Si vous lancez à nouveau le commande status, vous pouvez constater que votre fichier `LISEZMOI` est maintenant suivi et indexé :
  117
+Si vous lancez à nouveau la commande `status`, vous pouvez constater que votre fichier `LISEZMOI` est maintenant suivi et indexé :
118 118
 
119 119
 	$ git status
120 120
 	# On branch master
@@ -124,10 +124,10 @@ Si vous lancez à nouveau le commande status, vous pouvez constater que votre fi
124 124
 	#	new file:   LISEZMOI
125 125
 	#
126 126
 
127  
-Vous pouvez affirmer qu'il est indexé car il apparaît dans la section "Changes to be committed" (Modifications à valider).
  127
+Vous pouvez affirmer qu'il est indexé car il apparaît dans la section « Changes to be committed » (Modifications à valider).
128 128
 Si vous enregistrez à ce moment, la version du fichier à l'instant où vous lancez `git add` est celle qui appartiendra à l'instantané.
129  
-Vous pouvez vous souvenir que lorsque vous avez précédemment lancé `git init`, vous avez ensuite lancé `git add (fichiers)` — c'était bien sur pour commencer à placer sous suivi de version les fichiers de votre répertoire de travail.
130  
-La commande git add accepte en paramètre un chemin qui correspond à un fichier ou un répertoire ; dans le cas d'un répertoire, la commande ajoute récursivement tous les fichiers de ce répertoire.
  129
+Vous pouvez vous souvenir que lorsque vous avez précédemment lancé `git init`, vous avez ensuite lancé `git add (fichiers)` — c'était bien sûr pour commencer à placer sous suivi de version les fichiers de votre répertoire de travail.
  130
+La commande `git add` accepte en paramètre un chemin qui correspond à un fichier ou un répertoire ; dans le cas d'un répertoire, la commande ajoute récursivement tous les fichiers de ce répertoire.
131 131
 
132 132
 ### Indexer des fichiers modifiés ###
133 133
 
@@ -147,7 +147,7 @@ Si vous modifiez le fichier sous suivi de version appelé `benchmarks.rb` et que
147 147
 	#	modified:   benchmarks.rb
148 148
 	#
149 149
 
150  
-Le fichier `benchmarks.rb` apparaît sous la section nommée « Changed but not updated » ce qui signifie que le fichier sous suivi de version a été modifié dans la copie de travail mais n'est pas encore indexé.
  150
+Le fichier `benchmarks.rb` apparaît sous la section nommée « Changed but not updated » ce qui signifie que le fichier sous suivi de version a été modifié dans la copie de travail mais n'est pas encore indexé.
151 151
 Pour l'indexer, il faut lancer la commande `git add` (qui est une commande multi-usage — elle peut être utilisée pour placer un fichier sous suivi de version, pour indexer un fichier ou pour d'autres actions telles que marquer comme résolu des conflits de fusion de fichiers).
152 152
 Lançons maintenant `git add` pour indexer le fichier `benchmarks.rb`, et relançons la commande `git status` :
153 153
 
@@ -161,7 +161,7 @@ Lançons maintenant `git add` pour indexer le fichier `benchmarks.rb`, et relan
161 161
 	#	modified:   benchmarks.rb
162 162
 	#
163 163
 
164  
-A présent, les deux fichiers sont indexés et feront partie de la prochaine validation.
  164
+À présent, les deux fichiers sont indexés et feront partie de la prochaine validation.
165 165
 Mais supposons que vous souhaitiez apporter encore une petite modification au fichier `benchmarks.rb` avant de réellement valider la nouvelle version.
166 166
 Vous l'ouvrez à nouveau, réalisez la petite modification et vous voilà prêt à valider.
167 167
 Néanmoins, vous lancez `git status` une dernière fois :
@@ -198,7 +198,7 @@ Si le fichier est modifié après un `git add`, il faut relancer `git add` pour
198 198
 
199 199
 ### Ignorer des fichiers ###
200 200
 
201  
-Il apparaît souvent qu'un type de fichiers présent dans la copie de travail ne doit pas être ajouté automatiquement ou même apparaître comme fichier potentiel pour le suivi de version.
  201
+Il apparaît souvent qu'un type de fichiers présent dans la copie de travail ne doit pas être ajouté automatiquement ou même ne doit pas apparaître comme fichier potentiel pour le suivi de version.
202 202
 Ce sont par exemple des fichiers générés automatiquement tels que les fichiers de journaux ou de sauvegardes produits par l'outil que vous utilisez.
203 203
 Dans un tel cas, on peut énumérer les patrons de noms de fichiers à ignorer dans un fichier `.gitignore`.
204 204
 Voici ci-dessous un exemple de fichier `.gitignore` :
@@ -216,8 +216,8 @@ Les règles de construction des patrons à placer dans le fichier `.gitignore` s
216 216
 
217 217
 * Les lignes vides ou commençant par `#` sont ignorées
218 218
 * Les patrons standards de fichiers sont utilisables
219  
-* Si le patron se termine par un slash (`/`), le patron indique un répertoire
220  
-* Un patron commençant par un point d'exclamation (`!`) indique des fichiers à inclure malgré tout.
  219
+* Si le patron se termine par une barre oblique (`/`), il indique un répertoire
  220
+* Un patron commençant par un point d'exclamation (`!`) indique des fichiers à inclure malgré les autres règles.
221 221
 
222 222
 Les patrons standards de fichiers sont des expressions régulières simplifiées utilisées par les shells.
223 223
 Un astérisque (`*`) correspond à un ou plusieurs caractères ; `[abc]` correspond à un des trois caractères listés dans les crochets, donc a ou b ou c ; un point d'interrogation (`?`) correspond à un unique caractère ; des crochets entourant des caractères séparés par un signe moins (`[0-9]`) correspond à un caractère dans l'intervalle des deux caractères indiqués, donc ici de 0 à 9.
@@ -309,7 +309,7 @@ Par exemple, si vous indexez le fichier `benchmarks.rb` et l'éditez ensuite, vo
309 309
 	#	modified:   benchmarks.rb
310 310
 	#
311 311
 
312  
-A présent, vous pouvez utiliser `git diff` pour visualiser les modifications non indexées :
  312
+À présent, vous pouvez utiliser `git diff` pour visualiser les modifications non indexées :
313 313
 
314 314
 	$ git diff
315 315
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -343,8 +343,8 @@ et `git diff --cached` pour visualiser ce qui a été indexé jusqu'à maintenan
343 343
 
344 344
 ### Valider vos modifications ###
345 345
 
346  
-Votre zone d'index est dans l'état désiré, vous pouvez valider vos modifications.
347  
-Souvenez-vous que tout ce qui encore non indexé — tous les fichiers qui ont été créés ou modifiés mais n'ont pas subi de `git add` depuis ne feront pas partie de la prochaine validation.
  346
+Maintenant que votre zone d'index est dans l'état désiré, vous pouvez valider vos modifications.
  347
+Souvenez-vous que tout ce qui est encore non indexé — tous les fichiers qui ont été créés ou modifiés mais n'ont pas subi de `git add` depuis que vous les avez modifiés — ne feront pas partie de la prochaine validation.
348 348
 Ils resteront en tant que fichiers modifiés sur votre disque.
349 349
 
350 350
 Dans notre cas, la dernière fois que vous avez lancé `git status`, vous avez vérifié que tout était indexé, et vous êtes donc prêt à valider vos modifications.
@@ -370,7 +370,7 @@ L'éditeur affiche le texte suivant :
370 370
 	".git/COMMIT_EDITMSG" 10L, 283C
371 371
 
372 372
 Vous constatez que le message de validation par défaut contient une ligne vide suivie en commentaire par le résultat de la commande `git status`.
373  
-Vous pouvez effacer ces lignes de commentaire et saisir votre propre message de validation, ou vous pouvez les laisser en place vous aider à vous rappeler de ce que vous êtes en train de valider (pour un rappel plus explicite de ce que vous avez modifié, vous pouvez aussi passer l'option `-v` à la commande `git commit`.
  373
+Vous pouvez effacer ces lignes de commentaire et saisir votre propre message de validation, ou vous pouvez les laisser en place pour vous aider à vous rappeler de ce que vous êtes en train de valider (pour un rappel plus explicite de ce que vous avez modifié, vous pouvez aussi passer l'option `-v` à la commande `git commit`.
374 374
 Cette option place le résultat du diff en commentaire dans l'éditeur pour vous permettre de visualiser exactement ce que vous avez modifié.
375 375
 Quand vous quittez l'éditeur (après avoir sauvegardé le message), Git crée votre *commit* avec ce message de validation (après avoir retiré les commentaires et le diff).
376 376
 
@@ -382,11 +382,11 @@ D'une autre manière, vous pouvez spécifier votre message de validation en lign
382 382
 	 2 files changed, 3 insertions(+), 0 deletions(-)
383 383
 	 create mode 100644 LISEZMOI
384 384
 
385  
-A présent, vous avez créé votre premier *commit* ! Vous pouvez constater que le *commit* vous fournit quelques informations sur lui-même : sur quelle branche vous avez validé (`master`), quelle est sa somme de contrôle SHA-1 (`463dc4f`), combien de fichiers ont été modifiés, et quelques statistiques sur les lignes ajoutées et effacées dans ce *commit*.
  385
+À présent, vous avez créé votre premier *commit* ! Vous pouvez constater que le *commit* vous fournit quelques informations sur lui-même : sur quelle branche vous avez validé (`master`), quelle est sa somme de contrôle SHA-1 (`463dc4f`), combien de fichiers ont été modifiés, et quelques statistiques sur les lignes ajoutées et effacées dans ce *commit*.
386 386
 
387 387
 Souvenez-vous que la validation enregistre l'instantané que vous avez préparé dans la zone d'index.
388 388
 Tout ce que vous n'avez pas indexé est toujours en état modifié ; vous pouvez réaliser une nouvelle validation pour l'ajouter à l'historique.
389  
-A chaque validation, vous enregistrez un instantané du projet en forme de jalon auquel vous pourrez revenir ou comparer votre travail ultérieur.
  389
+À chaque validation, vous enregistrez un instantané du projet en forme de jalon auquel vous pourrez revenir ou avec lequel comparer votre travail ultérieur.
390 390
 
391 391
 ### Éliminer la phase d'indexation ###
392 392
 
@@ -452,8 +452,8 @@ Cela signifie que vous pouvez lancer des commandes telles que
452 452
 
453 453
 	$ git rm log/\*.log
454 454
 
455  
-Notez bien l'antislash (`\`) devant `*`.
456  
-Il est nécessaire d'échapper le caractère `*` car Git utilise sa propre expansion de nom de fichier en addition de l'expansion du shell.
  455
+Notez bien la barre oblique inverse (`\`) devant `*`.
  456
+Il est nécessaire d'échapper le caractère `*` car Git utilise sa propre expansion de nom de fichier en addition de l'expansion du shell. Ce caractère d'échappement doit être omis sous Windows si vous utilisez le terminal système.
457 457
 Cette commande efface tous les fichiers avec l'extension `.log` présents dans le répertoire `log/`.
458 458
 Vous pouvez aussi lancer une commande telle que :
459 459
 
@@ -470,7 +470,6 @@ Néanmoins, Git est assez malin pour s'en apercevoir après coup — la détect
470 470
 De ce fait, que Git ait une commande `mv` peut paraître trompeur.
471 471
 Si vous souhaitez renommer un fichier dans Git, vous pouvez lancer quelque chose comme
472 472
 
473  
-
474 473
 	$ git mv nom_origine nom_cible
475 474
 
476 475
 et cela fonctionne.
@@ -500,7 +499,7 @@ Le point principal est que vous pouvez utiliser n'importe quel outil pour renomm
500 499
 ## Visualiser l'historique des validations ##
501 500
 
502 501
 Après avoir créé plusieurs *commits* ou si vous avez cloné un dépôt ayant un historique de *commits*, vous souhaitez probablement revoir le fil des évènements.
503  
-La commande `git log` est l'outil le plus basique et puissant pour cet objet.
  502
+Pour ce faire, la commande `git log` est l'outil le plus basique et le plus puissant.
504 503
 
505 504
 Les exemples qui suivent utilisent un projet très simple nommé `simplegit` utilisé pour les démonstrations.
506 505
 Pour récupérer le projet, lancez
@@ -533,12 +532,12 @@ Cela signifie que les *commits* les plus récents apparaissent en premier.
533 532
 Comme vous le remarquez, cette commande indique chaque *commit* avec sa somme de contrôle SHA-1, le nom et l'e-mail de l'auteur, la date et le message du *commit*.
534 533
 
535 534
 `git log` dispose d'un très grand nombre d'options permettant de paramétrer exactement ce que l'on cherche à voir.
536  
-Nous allons détailler quelques unes des plus utilisées.
  535
+Nous allons détailler quelques-unes des plus utilisées.
537 536
 
538 537
 Une des options les plus utiles est `-p`, qui montre les différences introduites entre chaque validation.
539 538
 Vous pouvez aussi utiliser `-2` qui limite la sortie de la commande aux deux entrées les plus récentes :
540 539
 
541  
-	$ git log p -2
  540
+	$ git log -p -2
542 541
 	commit ca82a6dff817ec66f44342007202690a93763949
543 542
 	Author: Scott Chacon <schacon@gee-mail.com>
544 543
 	Date:   Mon Mar 17 21:52:11 2008 -0700
@@ -628,10 +627,10 @@ De plus, les options `short` (court), `full` (complet) et `fuller` (plus complet
628 627
 L'option la plus intéressante est `format` qui permet de décrire précisément le format de sortie.
629 628
 C'est spécialement utile pour générer des sorties dans un format facile à analyser par une machine — lorsqu'on spécifie intégralement et explicitement le format, on s'assure qu'il ne changera pas au gré des mises à jour de Git :
630 629
 
631  
-	$ git log --pretty=format:"%h — %an, %ar : %s"
632  
-	ca82a6d — Scott Chacon, 11 months ago : changed the version number
633  
-	085bb3b — Scott Chacon, 11 months ago : removed unnecessary test code
634  
-	a11bef0 — Scott Chacon, 11 months ago : first commit
  630
+	$ git log --pretty=format:"%h - %an, %ar : %s"
  631
+	ca82a6d - Scott Chacon, 11 months ago : changed the version number
  632
+	085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
  633
+	a11bef0 - Scott Chacon, 11 months ago : first commit
635 634
 
636 635
 Le tableau 2-1 liste les options de formatage les plus utiles.
637 636
 
@@ -643,18 +642,18 @@ Le tableau 2-1 liste les options de formatage les plus utiles.
643 642
 	%P	Sommes de contrôle des parents
644 643
 	%p	Sommes de contrôle abrégées des parents
645 644
 	%an	Nom de l'auteur
646  
-	%ae	e-mail de l'auteur
  645
+	%ae	E-mail de l'auteur
647 646
 	%ad	Date de l'auteur (au format de l'option -date=)
648 647
 	%ar	Date relative de l'auteur
649 648
 	%cn	Nom du validateur
650  
-	%ce	e-mail du validateur
  649
+	%ce	E-mail du validateur
651 650
 	%cd	Date du validateur
652 651
 	%cr	Date relative du validateur
653 652
 	%s	Sujet
654 653
 
655 654
 Vous pourriez vous demander quelle est la différence entre _auteur_  et _validateur_.
656 655
 L'_auteur_ est la personne qui a réalisé initialement le travail, alors que le _validateur_ est la personne qui a effectivement validé ce travail en gestion de version.
657  
-Donc, si quelqu'un envoie patch à un projet et un des membres du projet l'applique, les deux personnes reçoivent le crédit — l'écrivain en tant qu'auteur, et le membre du projet en tant que validateur.
  656
+Donc, si quelqu'un envoie un patch à un projet et un des membres du projet l'applique, les deux personnes reçoivent le crédit — l'écrivain en tant qu'auteur, et le membre du projet en tant que validateur.
658 657
 Nous traiterons plus avant de cette distinction au chapitre 5.
659 658
 
660 659
 Les options `oneline` et `format` sont encore plus utiles avec une autre option `log` appelée `--graph`.
@@ -677,24 +676,24 @@ Le tableau 2-2 donne une liste des options que nous avons traitées ainsi que d'
677 676
 
678 677
 	Option	Description
679 678
 	-p	Affiche le patch appliqué par chaque *commit*
680  
-	--stat	Affiche les statistiques de chaque fichier pour chaque commit
  679
+	--stat	Affiche les statistiques de chaque fichier pour chaque *commit*
681 680
 	--shortstat	N'affiche que les ligne modifiées/insérées/effacées de l'option --stat
682  
-	--name-only	Affiche la liste des fichiers modifiés après les informations du commit
  681
+	--name-only	Affiche la liste des fichiers modifiés après les informations du *commit*
683 682
 	--name-status	Affiche la liste des fichiers affectés accompagnés des informations d'ajout/modification/suppression
684 683
 	--abbrev-commit	N'affiche que les premiers caractères de la somme de contrôle SHA-1
685 684
 	--relative-date	Affiche la date en format relatif (par exemple "2 weeks ago" : il y a deux semaines) au lieu du format de date complet
686  
-	--graph	Affiche en caractère ASCII le graphe de branches et fusions en vis-à-vis de l'historique
687  
-	--pretty=<format>	Affiche les *commits* dans un format alternatif. Les formats incluent oneline, short, full, fuller, et format (où on peut spécifier son propre format)
  685
+	--graph	Affiche en caractères ASCII le graphe de branches et fusions en vis-à-vis de l'historique
  686
+	--pretty=<format>	Affiche les *commits* dans un format alternatif. Les formats incluent `oneline`, `short`, `full`, `fuller`, et `format` (où on peut spécifier son propre format)
688 687
 
689 688
 ### Limiter la longueur de l'historique ###
690 689
 
691  
-En complément des options de formatage de sortie, git log est pourvu de certaines options de limitation utiles — des options qui permettent de restreindre la liste à un sous-ensemble de *commits*.
  690
+En complément des options de formatage de sortie, `git log` est pourvu de certaines options de limitation utiles — des options qui permettent de restreindre la liste à un sous-ensemble de *commits*.
692 691
 Vous avez déjà vu une de ces options — l'option `-2` qui ne montre que les deux derniers *commits*.
693  
-En fait, on peut utiliser `-<n>`, ou `n` correspond au nombre de *commits* que l'on cherche à visualiser en partant des plus récents.
  692
+En fait, on peut utiliser `-<n>`, où `n` correspond au nombre de *commits* que l'on cherche à visualiser en partant des plus récents.
694 693
 En vérité, il est peu probable que vous utilisiez cette option, parce que Git injecte par défaut sa sortie dans un outil de pagination qui permet de la visualiser page à page.
695 694
 
696 695
 Cependant, les options de limitation portant sur le temps, telles que `--since` (depuis) et `--until` (jusqu'à) sont très utiles.
697  
-Par exemple, le commande suivante affiche la liste des *commits* des deux dernières semaines :
  696
+Par exemple, la commande suivante affiche la liste des *commits* des deux dernières semaines :
698 697
 
699 698
 	$ git log --since=2.weeks
700 699
 
@@ -702,33 +701,33 @@ Cette commande fonctionne avec de nombreux formats — vous pouvez indiquer une
702 701
 
703 702
 Vous pouvez aussi restreindre la liste aux *commits* vérifiant certains critères de recherche.
704 703
 L'option `--author` permet de filtrer sur un auteur spécifique, et l'option `--grep` permet de chercher des mots clés dans les messages de validation.
705  
-Notez que si vous cherchez seulement des *commits* correspondant simultanément aux deux critères, vous devez ajouter l'option `--all-match`, car par défaut ces commandes retournent les *commits* vérifiant au moins un critère lors de recherche de chaînes de caractères.
  704
+Notez que si vous cherchez seulement des *commits* correspondant simultanément aux deux critères, vous devez ajouter l'option `--all-match`, car par défaut ces commandes retournent les *commits* vérifiant au moins un critère lors de recherche.
706 705
 
707 706
 La dernière option vraiment utile à `git log` est la spécification d'un chemin.
708 707
 Si un répertoire ou un nom de fichier est spécifié, le journal est limité aux *commits* qui ont introduit des modifications aux fichiers concernés.
709  
-C'est toujours la dernière option de la commande, souvent précédée de deux tirets (`--`) pour séparer le chemin des options précédentes.
  708
+C'est toujours la dernière option de la commande, souvent précédée de deux tirets (`--`) pour séparer les chemins des options précédentes.
710 709
 
711 710
 Le tableau 2-3 récapitule les options que nous venons de voir ainsi que quelques autres pour référence.
712 711
 
713 712
 	Option	Description
714  
-	-(n)	N'affiche que les n derniers commits
715  
-	--since, --after	Limite l'affichage aux commits réalisés après la date spécifiée
716  
-	--until, --before	Limite l'affichage aux commits réalisés avant la date spécifiée
717  
-	--author	Ne montre que les commits dont le champ auteur correspond à la chaîne passée en argument
718  
-	--committer	Ne montre que les commits dont le champ validateur correspond à la chaîne passée en argument
  713
+	-(n)	N'affiche que les n derniers *commits*
  714
+	--since, --after	Limite l'affichage aux *commits* réalisés après la date spécifiée
  715
+	--until, --before	Limite l'affichage aux *commits* réalisés avant la date spécifiée
  716
+	--author	Ne montre que les *commits* dont le champ auteur correspond à la chaîne passée en argument
  717
+	--committer	Ne montre que les *commits* dont le champ validateur correspond à la chaîne passée en argument
719 718
 
720 719
 Par exemple, si vous souhaitez visualiser quels *commits* modifiant les fichiers de test dans l'historique du source de Git ont été validés par Junio Hamano et n'étaient pas des fusions durant le mois d'octobre 2008, vous pouvez lancer ce qui suit :
721 720
 
722  
-	$ git log --pretty="%h  %s" --author=gitster --since="2008-10-01" \
  721
+	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
723 722
 	   --before="2008-11-01" --no-merges -- t/
724  
-	5610e3b — Fix testcase failure when extended attribute
725  
-	acd3b9e — Enhance hold_lock_file_for_{update,append}()
726  
-	f563754 — demonstrate breakage of detached checkout wi
727  
-	d1a43f2 — reset --hard/read-tree --reset -u: remove un
728  
-	51a94af — Fix "checkout --track -b newbranch" on detac
729  
-	b0ad11e — pull: allow "git pull origin $something:$cur
  723
+	5610e3b - Fix testcase failure when extended attribute
  724
+	acd3b9e - Enhance hold_lock_file_for_{update,append}()
  725
+	f563754 - demonstrate breakage of detached checkout wi
  726
+	d1a43f2 - reset --hard/read-tree --reset -u: remove un
  727
+	51a94af - Fix "checkout --track -b newbranch" on detac
  728
+	b0ad11e - pull: allow "git pull origin $something:$cur
730 729
 
731  
-A partir des 20 000 *commits* constituant l'historique des sources de Git, cette commande extrait les 6 qui correspondent aux critères.
  730
+À partir des 20 000 *commits* constituant l'historique des sources de Git, cette commande extrait les 6 qui correspondent aux critères.
732 731
 
733 732
 ### Utiliser une interface graphique pour visualiser l'historique ###
734 733
 
@@ -746,7 +745,7 @@ Le visualisateur de diff dans la partie inférieure de la fenêtre affiche les m
746 745
 
747 746
 À tout moment, vous pouvez désirer annuler une de vos dernières actions.
748 747
 Dans cette section, nous allons passer en revue quelques outils de base permettant d'annuler des modifications.
749  
-Il faut être très attentif car certaines de ces annulations sont définitives (elles ne peuvent pas être elle-même annulées).
  748
+Il faut être très attentif car certaines de ces annulations sont définitives (elles ne peuvent pas être elles-même annulées).
750 749
 C'est donc un des rares cas d'utilisation de Git où des erreurs de manipulation peuvent entraîner des pertes définitives de données.
751 750
 
752 751
 ### Modifier le dernier *commit* ###
@@ -775,7 +774,7 @@ Les trois dernières commandes donnent lieu à la création d'un unique *commit*
775 774
 Les deux sections suivantes démontrent comment bricoler les modifications dans votre zone d'index et votre zone de travail.
776 775
 Un point sympathique est que la commande permettant de connaître l'état de ces deux zones vous rappelle aussi comment annuler les modifications.
777 776
 Par exemple, supposons que vous avez modifié deux fichiers et voulez les valider comme deux modifications indépendantes, mais que vous avez tapé accidentellement `git add *` et donc indexé les deux.
778  
-Comment annuler l'indexation d'un des fichiers ? La commande `git status` vous rappelle :
  777
+Comment annuler l'indexation d'un des fichiers ? La commande `git status` vous le rappelle :
779 778
 
780 779
 	$ git add .
781 780
 	$ git status
@@ -787,7 +786,7 @@ Comment annuler l'indexation d'un des fichiers ? La commande `git status` vous
787 786
 	#       modified:   benchmarks.rb
788 787
 	#
789 788
 
790  
-Juste sous le texte "Changes to be committed", elle vous indique d'utiliser `git reset HEAD <fichier>...` pour désindexer un fichier.
  789
+Juste sous le texte « Changes to be committed », elle vous indique d'utiliser `git reset HEAD <fichier>...` pour désindexer un fichier.
791 790
 Utilisons donc ce conseil pour désindexer le fichier `benchmarks.rb` :
792 791
 
793 792
 
@@ -871,7 +870,7 @@ Si vous avez cloné un dépôt, vous devriez au moins voir l'origine `origin` 
871 870
 	$ git remote
872 871
 	origin
873 872
 
874  
-Vous pouvez aussi spécifier `-v`, qui vous montre l'URL que Git a stocké pour chaque nom court :
  873
+Vous pouvez aussi spécifier `-v`, qui vous montre l'URL que Git a stocké pour chaque nom court :
875 874
 
876 875
 	$ git remote -v
877 876
 	origin  git://github.com/schacon/ticgit.git (fetch)
@@ -928,7 +927,7 @@ Après cette action, vous possédez toutes les références à toutes les branch
928 927
 
929 928
 Si vous clonez un dépôt, le dépôt distant est automatiquement ajouté sous le nom `origin`.
930 929
 Donc, `git fetch origin` récupère tout ajout qui a été poussé vers ce dépôt depuis que vous l'avez cloné ou la dernière fois que vous avez récupéré les ajouts.
931  
-Il faut noter que la commande fetch tire les données dans votre dépôt local mais sous sa propre branche — elle ne les fusionne pas automatiquement avec aucun de vos travaux ni ne modifie votre copie de travail.
  930
+Il faut noter que la commande `fetch` tire les données dans votre dépôt local mais sous sa propre branche — elle ne les fusionne pas automatiquement avec aucun de vos travaux ni ne modifie votre copie de travail.
932 931
 Vous devez volontairement fusionner ses modifications distantes dans votre travail lorsque vous le souhaitez.
933 932
 
934 933
 Si vous avez créé une branche pour suivre l'évolution d'une branche distante (Cf.
@@ -1019,7 +1018,7 @@ Si vous souhaitez retirer une référence pour certaines raisons — vous avez
1019 1018
 
1020 1019
 À l'instar de la plupart des VCS, Git donne la possibilité d'étiqueter un certain état dans l'historique comme important.
1021 1020
 Généralement, les gens utilisent cette fonctionnalité pour marquer les états de publication (`v1.0` et ainsi de suite).
1022  
-Dans cette section, nous apprendrons comment lister les différentes étiquettes (*tag* en anglais), comment créer de nouvelles étiquettes et les différents types de étiquettes.
  1021
+Dans cette section, nous apprendrons comment lister les différentes étiquettes (*tag* en anglais), comment créer de nouvelles étiquettes et les différents types d'étiquettes.
1023 1022
 
1024 1023
 ### Lister vos étiquettes ###
1025 1024
 
@@ -1184,7 +1183,7 @@ Supposons que l'historique des *commits* ressemble à ceci :
1184 1183
 	964f16d36dfccde844893cac5b347e7b3d44abbc validation afaire
1185 1184
 	8a5cbc430f1a9c3d00faaeffd07798508422908a mise à jour lisezmoi
1186 1185
 
1187  
-Maintenant, supposons que vous avez oublié d'étiqueter le projet à la version `v1.2` qui correspondait au *commit* "mise à jour rakefile".
  1186
+Maintenant, supposons que vous avez oublié d'étiqueter le projet à la version `v1.2` qui correspondait au *commit* « mise à jour rakefile ».
1188 1187
 Vous pouvez toujours le faire après l'évènement.
1189 1188
 Pour étiqueter ce *commit*, vous spécifiez la somme de contrôle du *commit* (ou une partie) en fin de commande :
1190 1189
 
@@ -1217,7 +1216,7 @@ Le *commit* a été étiqueté :
1217 1216
 
1218 1217
 Par défaut, la commande `git push` ne transfère pas les étiquettes vers les serveurs distants.
1219 1218
 Il faut explicitement pousser les étiquettes après les avoir créées localement.
1220  
-Ce processus s'apparente à pousser des branches distantes  vous pouvez lancer `git push origin [nom-du-tag]`.
  1219
+Ce processus s'apparente à pousser des branches distantes  vous pouvez lancer `git push origin [nom-du-tag]`.
1221 1220
 
1222 1221
 	$ git push origin v1.5
1223 1222
 	Counting objects: 50, done.
@@ -1242,7 +1241,7 @@ Ceci transférera toutes les nouvelles étiquettes vers le serveur distant.
1242 1241
 	 * [new tag]         v1.4-lw -> v1.4-lw
1243 1242
 	 * [new tag]         v1.5 -> v1.5
1244 1243
 
1245  
-A présent, lorsqu'une autre personne clone ou tire depuis votre dépôt, elle obtient aussi les étiquettes.
  1244
+À présent, lorsqu'une autre personne clone ou tire depuis votre dépôt, elle obtient aussi les étiquettes.
1246 1245
 
1247 1246
 ## Trucs et astuces ##
1248 1247
 
@@ -1259,7 +1258,7 @@ Copiez ce fichier dans votre répertoire personnel et ajoutez cette ligne à vot
1259 1258
 
1260 1259
 	source ~/.git-completion.bash
1261 1260
 
1262  
-Si vous souhaitez paramétrer Bash pour activer la complétion automatique de Git pour tous les utilisateur, copiez le script dans le répertoire `/opt/local/etc/bash_completion.d` sur les systèmes Mac ou dans le répertoire `/etc/bash_completion.d` sur les systèmes Linux.
  1261
+Si vous souhaitez paramétrer Bash pour activer la complétion automatique de Git pour tous les utilisateurs, copiez le script dans le répertoire `/opt/local/etc/bash_completion.d` sur les systèmes Mac ou dans le répertoire `/etc/bash_completion.d` sur les systèmes Linux.
1263 1262
 C'est le répertoire dans lequel Bash lit pour fournir automatiquement la complétion en ligne de commande.
1264 1263
 
1265 1264
 Si vous utilisez Windows avec le Bash Git, qui est installé par défaut avec Git en msysGit, l'auto-complétion est pré-configurée.
@@ -1311,7 +1310,7 @@ Il est aussi commun d'ajouter un alias `last`, de la manière suivante :
1311 1310
 	$ git config --global alias.last 'log -1 HEAD'
1312 1311
 
1313 1312
 Ainsi, vous pouvez visualiser plus facilement le dernier *commit* :
1314  
-	
  1313
+
1315 1314
 	$ git last
1316 1315
 	commit 66938dae3329c7aebe598c2246a8e6af90d04646
1317 1316
 	Author: Josh Goebel <dreamer3@example.com>
@@ -1330,7 +1329,7 @@ On peut par exemple aliaser `git visual` pour lancer `gitk` :
1330 1329
 
1331 1330
 ## Résumé ##
1332 1331
 
1333  
-A présent, vous pouvez réaliser toutes les opérations locales de base de Git — créer et cloner un dépôt, faire des modifications, les indexer et les valider, visualiser l'historique de ces modifications.
  1332
+À présent, vous pouvez réaliser toutes les opérations locales de base de Git — créer et cloner un dépôt, faire des modifications, les indexer et les valider, visualiser l'historique de ces modifications.
1334 1333
 Au prochain chapitre, nous traiterons de la fonctionnalité unique de Git : son modèle de branches.
1335 1334
 
1336 1335
 <!--  LocalWords:  Junio
2  fr/04-git-server/01-chapter4.markdown
Source Rendered
@@ -86,7 +86,7 @@ Pour cloner une dépôt Git à travers SSH, spécifiez le préfixe `ssh://` dans
86 86
 	$ git clone ssh://utilisateur@serveur:projet.git
87 87
 
88 88
 ou ne spécifiez  pas de protocole du tout — Git choisit SSH par défaut si vous n'êtes pas explicite :
89  
-	
  89
+
90 90
 	$ git clone utilisateur@serveur:projet.git
91 91
 
92 92
 Vous pouvez aussi ne pas spécifier de nom d'utilisateur et Git utilisera par défaut le nom de login.
2  fr/05-distributed-git/01-chapter5.markdown
Source Rendered
@@ -687,7 +687,7 @@ Quand c'est fait, vous pouvez utiliser la commande `git send-email` pour placer
687 687
 	Emails will be sent from: Jessica Smith <jessica@example.com>
688 688
 	Who should the emails be sent to? jessica@example.com
689 689
 	Message-ID to be used as In-Reply-To for the first email? y
690  
-	
  690
+
691 691
 La première question demande l'adresse mail d'origine (avec par défaut celle saisie en config), tandis que la seconde demande les destinataires.
692 692
 Enfin la dernière question sert à indiquer que l'on souhaite poster la série de patchs comme une réponse au premier patch de la série, créant ainsi un fil de discussion unique pour cette série.
693 693
 Ensuite, Git crache un certain nombre d'informations qui ressemblent à ceci pour chaque patch à envoyer :
8  fr/07-customizing-git/01-chapter7.markdown
Source Rendered
@@ -225,7 +225,7 @@ ou vous pouvez éditer votre fichier `~/.gitconfig` pour y ajouter ces lignes :
225 225
 	  external = extDiff
226 226
 
227 227
 Après avoir réglé tout ceci, si vous lancez des commandes de diff telles que celle-ci :
228  
-	
  228
+
229 229
 	$ git diff 32d1776b1^ 32d1776b1
230 230
 
231 231
 Au lieu d'obtenir la sortie du diff dans le terminal, Git lance P4Merge, ce qui ressemble à la Figure 7-1.
@@ -239,7 +239,7 @@ Le point agréable avec cette méthode d'enveloppe est que vous pouvez changer f
239 239
 Par exemple, pour changer vos outils `extDiff` et `extMerge` pour une utilisation de l'outil KDiff3, il vous suffit d'éditer le fichier `extMerge` :
240 240
 
241 241
 	$ cat /usr/local/bin/extMerge
242  
-	#!/bin/sh	
  242
+	#!/bin/sh
243 243
 	/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
244 244
 
245 245
 À présent, Git va utiliser l'outil KDiff3 pour visualiser les différences et résoudre les conflits de fusion.
@@ -471,13 +471,13 @@ Créez un fichier `/usr/local/bin/odt-to-txt` (vous êtes libre de le placer dan
471 471
 	#! /usr/bin/env perl
472 472
 	# Convertisseur simpliste OpenDocument Text (.odt) vers texte
473 473
 	# Author: Philipp Kempgen
474  
-	
  474
+
475 475
 	if (! defined($ARGV[0])) {
476 476
 		print STDERR "Pas de fichier fourni!\n";
477 477
 		print STDERR "Usage: $0 [nom du fichier]\n";
478 478
 		exit 1;
479 479
 	}
480  
-	
  480
+
481 481
 	my $content = '';
482 482
 	open my $fh, '-|', 'unzip', '-qq', '-p', $ARGV[0], 'content.xml' or die $!;
483 483
 	{
12  fr/08-git-and-other-scms/01-chapter8.markdown
Source Rendered
@@ -346,9 +346,9 @@ Si vous êtes habitué à Subversion, vous pouvez lancer `git svn log` pour visu
346 346
 
347 347
 	------------------------------------------------------------------------
348 348
 	r85 | schacon | 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) | 2 lines
349  
-	
  349
+
350 350
 	updated the changelog
351  
-	
  351
+
352 352
 Deux choses importantes à connaître sur `git svn log` : premièrement, à la différence de la commande réelle `svn log` qui interroge le serveur, cette commande fonctionne hors connexion ; deuxièmement, elle ne montre que les *commits* qui ont été effectivement remontés sur le serveur Subversion.
353 353
 Les *commits* locaux qui n'ont pas encore été remontés via `dcommit` n'apparaissent pas, pas plus que ceux qui auraient été poussés sur le serveur par des tiers entre deux `git svn rebase`.
354 354
 Cela donne plutôt le dernier état connu des *commits* sur le serveur Subversion.
@@ -486,18 +486,18 @@ Premièrement, déplacez les étiquettes pour qu'elles soient de vraies étiquet
486 486
 
487 487
 Pour déplacer les étiquettes et en faire de vraies étiquettes Git, lancez
488 488
 
489  
-	$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do 
490  
-	git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; 
  489
+	$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do
  490
+	git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname";
491 491
 	done
492 492
 
493 493
 Cela récupère les références déclarées comme branches distantes commençant par `tags/` et les transforme en vraies étiquettes (légères).
494 494
 
495 495
 Ensuite, déplacez le reste des références sous `refs/remotes` en branches locales :
496 496
 
497  
-	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do 
  497
+	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do
498 498
 	git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname";
499 499
 	done
500  
- 
  500
+
501 501
 À présent, toutes les vieilles branches sont des vraies branches Git et toutes les vieilles étiquettes sont de vraies étiquettes Git.
502 502
 La dernière activité consiste à ajouter votre nouveau serveur Git comme serveur distant et à y pousser votre projet transformé.
503 503
 Pour pousser tout, y compris branches et étiquettes, lancez :

0 notes on commit 93c71bf

Please sign in to comment.
Something went wrong with that request. Please try again.