Skip to content
This repository
Browse code

Merge remote branch 'jnavila/master'

Conflicts:
	fr/01-introduction/01-chapter1.markdown
  • Loading branch information...
commit 25c0e8837a9cf3be135dcd32600788a359437033 2 parents 459a07e + 9bc06ca
Scott Chacon authored December 02, 2009
1  .gitattributes
... ...
@@ -0,0 +1 @@
  1
+*.graffle binary
232  fr/01-introduction/01-chapter1.markdown
Source Rendered
... ...
@@ -1,225 +1,225 @@
1  
-# Pour commencer #
  1
+# Démarrage rapide #
2 2
 
3  
-Ce chapitre concernera la prise en main de Git. Nous commencerons par introduire les outils de suivi de version, puis continuerons avec l'installation de Git sur votre système pour terminer par sa configuration opérationnelle. A la fin de ce chapitre vous devriez comprendre pourquoi Git a été créé, pourquoi vous devrier l'utiliser et comment ce faire.
  3
+Ce chapitre traite du démarrage rapide avec Git. Nous commencerons par expliquer les bases des gestions de version, puis nous parlerons de l'installation de Git sur votre système et finalement comment le paramétrer pour commencer à l'utiliser. A la fin de ce chapitre vous devriez en savoir assez pour comprendre pourquoi on parle beaucoup de Git, pourquoi vous devriez l'utiliser et vous devriez en avoir une installation prête à l'emploi.
4 4
 
5  
-## A propos du suivi de version ##
  5
+## À propos de la gestion de version ##
6 6
 
7  
-Qu'est-ce que le suivi de version, et pourquoi devriez-vous vous en soucier ? Le suivi de version est un système qui enregistre les modifications apportées dans le temps à un fichier ou un lot de fichiers de manière à pouvoir en récupérer une copie spécifique ultérieurement. Dans le cadre des exemples fournis dans cet ouvrage, vous utiliserez du code source comme matière première à soumettre au suivi de version, mais en réalité vous pouvez le faire avec quasiment n'importe quel type de fichier présent sur votre ordinateur.
  7
+Qu'est-ce que la gestion de version et pourquoi devriez-vous vous en soucier ? La gestion de version est un système qui enregistre l'évolution d'un fichier ou d'un ensemble de fichiers au cours du temps de manière à ce qu'on puisse rappeler une version antérieure d'un fichier à tout moment. Pour les exemples de ce livre, nous utiliserons des fichiers sources de logiciel comme fichiers sous gestion de version, bien qu'en réalité on puisse l'utiliser avec pratiquement tous les types de fichiers d'un ordinateur.
8 8
 
9  
-Si vous êtes graphiste ou concepteur de sites Web et désirez conserver chacune des versions d'une image ou d'un gabarit (ce que vous voulez certainement), un système de suivi de version (SSV) offre une sage solution. Il permet de restaurer un fichier à sa version précédente, rétablir à une version antérieure l'ensemble d'un projet, comparer les modifications au fil du temps, repérer qui a effectué récemment un changement susceptible d'être à la source d'un problème, quand est apparue une problématique et qui l'a introduite, etc. Utiliser un SSV signifie également la possibilité de se remettre facilement d'une catastrophe ou d'une perte de fichier. Tout cela, presque sans effort supplémentaire.
  9
+Si vous êtes un dessinateur ou un designer web et voulez conserver toutes les versions d'une image ou d'une mise en page (ce que vous voudriez surement faire), un système de gestion de version (VCS en anglais pour Version Control System) est un outil qu'il est très sage d'utiliser. Il vous permet de ramener un fichier à un état précédent, ramener le projet complet à un état précédent, comparer les changements au cours du temps, voir qui a modifié quelque chose qui pourrait causer un problème, qui a introduit un problème et quand, et plus encore. Utiliser un VCS signifie aussi généralement que si vous vous trompez ou vous perdez des fichiers, vous pouvez facilement revenir à un état stable. De plus, vous obtenez tous ces avantages pour peu de surcharge de travail.
10 10
 
11  
-### Systèmes locaux de suivi de version ###
  11
+### Les systèmes de gestion de version locaux ###
12 12
 
13  
-Pour de nombreuses personnes, la méthode de choix pour la sauvegarde consiste à copier des fichiers dans un autre répertoire (peut-être nommé après la date courante, dans le meilleur des cas). Cette approche est très populaire du fait de sa simplicité, mais aussi incroyablement susceptible d'erreur. Il est tellement simple d'oublier le répertoire courant et modifier accidentellement le mauvais fichier ou en écraser un autre sans le vouloir.
  13
+La méthode commune pour la gestion de version est généralement de recopier les fichiers dans un autre répertoire (peut-être avec un nom incluant la date pour les plus malins). Cette méthode est la plus commune parce que c'est la plus simple, mais c'est aussi la plus grande source d'erreurs. Il est facile d'oublier le répertoire dans lequel vous êtes et d'écrire accidentellement dans le mauvais fichier ou d'écraser des fichiers que vous vouliez conserver.
14 14
 
15  
-Afin d'éviter cet écueil, les programmeurs ont depuis longtemps développé des SSV dotés d'une base de données simple conservant les modifications apportées aux fichiers suivis (voir la figure 1-1).
  15
+Pour traiter ce problème, les programmeurs ont développé il y a longtemps des VCSs locaux qui utilisaient une base de données simple pour conserver les modifications d'un fichier (Cf. figure 1-1).
16 16
 
17  
-Insert 18333fig0101.png
18  
-Figure 1-1. Diagramme du suivi local de version
  17
+Insert 18333fig0101.png 
  18
+Figure 1-1. Diagramme des systèmes de gestion de version locaux.
19 19
 
20  
-RCS, l'un des SSV les plus populaires, est encore fourni avec la plupart des ordinateurs. Même le célèbre Mac OS X inclue la commande rcs lorsque vous installez la suite de développement. Schématiquement, cet outil fonctionne en conservant  dans un format spécial sur le disque des lots de corrections (c'est-à-dire les différences entre les fichiers) d'une sauvegarde à l'autre; il peut restituer l'état d'un fichier à un instant quelconque en appliquant l'ensemble des corrections jusqu'à cet instant.
  20
+Un des systèmes les plus populaires était rcs, qui est encore distribué avec de nombreux systèmes d'exploitation aujourd'hui. Même le système d'exploitation populaire Mac OS X inclut le programme rcs lorsqu'on installe les outils de développement logiciel. Cet outil fonctionne en conservant les patch sets (c'est-à-dire la différence entre les fichiers) d'une version à l'autre dans un format spécial sur disque ; il peut alors recréer ce qu'était n'importe quel fichier à n'importe quel instant en ajoutant toutes les différences.
21 21
 
22  
-### Systèmes centralisés de suivi de version ###
  22
+### Les systèmes de gestion de version centralisés ###
23 23
 
24  
-La problématique majeure que rencontre ensuite la plupart des gens est la nécessité de collaborer avec des développeurs sur d'autres systèmes. Les systèmes centralisés de suivi de version (SCSV) ont été créé pour répondre à ce besoin. Ces systèmes, tels CVS, Subversion et Perforce, disposent d'un serveur unique maintenant l'ensemble des des versions des fichiers suivis, et des clients qui récupèrent leurs copies depuis ce serveur centrale. Depuis des années ce modèle s'établit comme le standard du suivi de versions (voir la figure 1-2).
  24
+Le problème majeur suivant que les gens rencontrent est qu'ils ont besoin de collaborer avec des développeurs sur d'autres ordinateurs. Pour traiter ce problème, les systèmes de gestion de version centralisés (CVCS en anglais pour Centralized Version Control Systems) furent développés. Ces systèmes tels que CVS, Subversion, et Perforce, mettent en place un serveur central qui contient tous les fichiers sous version, et des clients qui peuvent extraire les fichiers de ce dépot central. Pendant de nombreuses années, celà a été le standard pour la gestion de version (Cf. Figure 1-2).
25 25
 
26  
-Insert 18333fig0102.png
27  
-Figure 1-2. Diagramme des systèmes centralisés de suivi de version.
  26
+Insert 18333fig0102.png 
  27
+Figure 1-2. Diagramme de la gestion de version centralisée.
28 28
 
29  
-Ce modèle offre de nombreux avantages, surtout comparé aux SSV locaux. Par exemple, chacun sait jusqu'à un certain point, ce à quoi tout les autres sur le projet est occupé. Les administrateurs disposent d'une maîtrise fine des prérogatives de chacun; et il est bien plus facile de gérer un SCSV que d'avoir à maintenir des bases de données locales sur chaque machine cliente.
  29
+Ce schéma offre de nombreux avantages par rapport à la gestion de version locale. Par exemple, chacun sait jusqu'à un certain point ce que tout les autres sont en train de faire sur le projet. Les administrateurs ont un contrôle fin des permissions et il est beaucoup plus facile d'administrer un CVCS qu'il l'est de devoir gérer des bases de données locales.
30 30
 
31  
-Cependant, ce modèle souffre de sérieux écueils. Le plus évident concerne le point unique de panne que représente le serveur central. Si ce serveur devient indisponible pendant une heure, durant tout ce temps personne ne pourra collaborer ni sauvegarder les modifications de ses propres travaux en cours. Si le disque dur de la base de données centrale  est corrompu, et que des sauvegardes suffisantes n'ont pas été prévues, c'est l'ensemble du projet que vous pouvez perdre-incluant son historique, à l'exception de quelque copie intégrale dont pourraient disposer certaines personnes sur leurs propres machines. Les SSV locaux souffrent du même problème-dès que vous entreposez l'intégralité de l'historique d'un projet dans un endroit unique, vous risquez de tout perdre.
  31
+Cependant ce système a aussi de nombreux défauts. Le plus visible est le point unique de panne que le serveur centralisé représente. Si ce serveur est en panne pendant une heure, alors durant cette heure, aucun client ne peut collaborer ou enregistrer les modifications issues de son travail. Si le disque dur du serveur central se corrompt, et s'il n'y a pas eu de sauvegarde, vous perdez absolument tout de l'historique d'un projet en dehors des sauvegardes locales que les gens auraient pu réaliser sur leur machines locales. Les systèmes de gestion de version locaux souffrent du même problème - dès qu'on a tout l'historique d'un projet sauvegardé à un endroit unique, on prend le risque de tout perdre.
32 32
 
33  
-### Les systèmes distribués de suivi de version ###
  33
+### Les systèmes de gestion de version distribués ###
34 34
 
35  
-C'est là que les systèmes distribués de suivi de version apparaissent. Dans un SDSV (comme Git, Mercurial, Bazaar ou Darcs), les clients ne récupèrent pas seulement la dernière copie des fichiers : ils maintiennent localement un miroir fidèle du dépôt. Si l'un quelconque des serveurs disparait, et que ces systèmes collaboraient avec lui, chacun des clients saura fournir une copie identique à restaurer sur ce serveur. Chaque synchronisation génère en fait une sauvegarde complète de l'intégralité des données (voir la figure 1-3).
  35
+C'est à ce moment que les systèmes de gestion de version distribués entrent en jeu (DVCSs en anglais pour Distributed Version Control Systems). Dans un DVCS (tel que Git, Mercurial, Bazaar or Darcs), les clients n'extraient plus seulement la dernière version d'un fichier : il dupliquent complètement le dépot. Ainsi, si le serveur disparaît, et si les systèmes collaboraient via ce serveur, n'importe quel dépot d'un des clients peut être copié sur le serveur pour le restaurer. Chaque extraction devient une sauvegarde complète de toutes les données (Cf. Figure 1-3).
36 36
 
37  
-Insert 18333fig0103.png
38  
-Figure 1-3. Diagramme des systèmes distribués de suivi de version.
  37
+Insert 18333fig0103.png 
  38
+Figure 1-3. Diagramme de gestion de version de contrôle centralisée.
39 39
 
40  
-En outre, nombre de ces systèmes offre une bonne gestion de multiples dépôts distants avec lesquels travailler, de manière à collaborer avec différents groupes et procéder de différentes manières simultanément au sein d'un même projet. Cela permet la mise en oeuvre de plusieurs méthodes de travail impossible à mettre en place avec des systèmes centralisés, comme des modèles hiérarchiques.
  40
+De plus, un grand nombre de ces systèmes gère particulièrement bien le fait d'avoir plusieurs dépots avec lesquels travailler, vous permettant de collaborer avec différents groupes de personnes de manière différentes simultanément dans le même projet. Celà permet la mise en place de différentes chaînes de traitement qui ne sont pas réalisables avec les systèmes centralisés, tels que les modèles hierarchiques.
41 41
 
42  
-## Une brève histoire de Git ##
  42
+## Une rapide histoire de Git ##
43 43
 
44  
-Comme pour de nombreuses grandes choses de la vie, Git commença par un brin de destruction créatrice et une sauvage controverse. Le noyau Linux est un projet libre qu'on peut qualifier de grande envergure. Durant la majeure partie de la vie du maintien du noyau Linux (1991-2002), les modifications apportées au logiciel circulaient sous formes de corrections (_patches_) et d'archives de fichiers. En 2002, le projet du noyau Linux adopta un SDSV propriétaire nommé BitKeeper.
  44
+Comme de nombreuses choses extraordinaires de la vie, Git est né avec une dose de destruction créative et de controverse houleuse. Le kernel Linux est un projet libre de plutôt grande envergure. Pour la plus grande partie de sa vie (1991–2002), les modifications étaient transmises sous forme de patchs et d'archives de fichiers. En 2002, le projet du kernel Linux commença à utiliser un DVCS propriétaire appelé BitKeeper.
45 45
 
46  
-En 2005, les relations entre la communauté qui développait le noyau Linux et l'entreprise commerciale qui développait BitKeeper furent brisées et la charte d'utilisation gratuite révoquée. Cela força la communauté qui développe Linux (et en particulier son créateur, Linux Torvalds) à développer son propre outil issu des leçons-apprises en utilisant BitKeeper. Voici résumés quelques-uns des objectifs du nouveau système :
  46
+En 2005, les relations entre la communinauté développant le kernel linux et la société en charge du développement de BitKeeper furent rompues, et le statut de gratuité de l'outil fut révoqué. Celà poussa la communauté du développement de Linux (et plus particulièrement Linus Torvalds, le créateur de Linux) à developper leur propre outil en se basant sur les leçons apprises lors de l'utilisation de BitKeeper. Certains des objectifs du nouveau système étaient les suivants :
47 47
 
48  
-* rapidité
49  
-* architecture simple
50  
-* support natif du développement non-linéaire (des milliers de branches parallèles)
51  
-* entièrement distribué
52  
-* capacité de gérer de gros projets tels le noyau Linux efficacement (vitesse et taille des données)
  48
+* Vitesse
  49
+* Conception simple
  50
+* Support pour les développements non linéaires (milliers de branches parallèles)
  51
+* Complètement distribué
  52
+* Capacité à gérer efficacement des projets d'envergure tels que le kernel Linux (vitesse et compacité des données)
53 53
 
54  
-Depuis sa naissance en 2005, Git a évolué vers la mâturité en restant simple d'utilisation tout en conservant ces qualités initiales. Il est incroyablement rapide, très efficient avec les gros projets, et dispose d'un superbe système de gestion des branches pour le développement non-linéaire (voire chapitre 3).
  54
+Depuis sa naissance en 2005, Git a évolué et mûri vers une utilisation plus simple, tout en retenant ses qualités initiales. Il est incroyablement rapide, il est très efficace pour de grands projets, et il a un système incroyable de gestion de branches pour le développement non linéaire (Cf. Chapitre 3).
55 55
 
56  
-## Les fondements de Git ##
  56
+## Rudiments de Git ##
57 57
 
58  
-Alors, qu'est-ce que Git en deux mots ? C'est une section importante à absorber, parce que si vous comprenez ce qu'est Git et les fondements de son fonctionnement, alors utiliser Git efficacement viendra bien plus aisément pour vous. Durant l'apprentissage de Git, tâchez d'évacuer de votre esprit ce que vous avez appris d'autres SSV, tels Subversion ou Perforce; ce faisant, vous éviterez de subtiles confusion lorsque vous utiliserez l'outil. Git enregistre et approche les données très différemment des autres systèmes, malgré la similarité des interfaces pour l'utilisateur; comprendre ces différences vous permettra d'éviter la confusion lorsque vous l'utiliserez.
  58
+Donc, qu'est-ce que Git en quelques concepts ? Il est important de bien comprendre cette section , parce que si on comprend ce que Git est et les principes sur lesquels il repose, alors utiliser efficacement Git devient simple. Au cours de l'apprentissage de Git, essayer de libérer votre esprit de ce que vous pourriez connaître d'autres VCSs, tels que Subversion et Perforce ; ce faisant, vous vous éviterez de petites confusions à l'utilisation de cet outil. Git sauve et gère l'information très différemment des autres systèmes, même si l'interface utilisateur paraît similaire ; comprendre ses différences vous évitera des confusions à l'utilisation.
59 59
 
60  
-### Sauvegardes au lieu de différences ###
  60
+### Des instantanés, pas des différences ###
61 61
 
62  
-Comment Git "pense" ses données : la différence majeure entre Git et les autres SSV (y compris Subversion et compagnie). Conceptuellement, la plupart des systèmes alternatifs enregistre l'information comme une liste de modifications-par-fichier. Ces systèmes (CVS, Subversion, Perforce, Bazaar, etc.) "pensent" que l'information qu'ils maintiennent s'applique à des lots de fichiers et aux changements effectués dans le temps pour chaque fichier, tel qu'illustré à la figure 1-4.
  62
+La différence majeure entre Git et les autres VCSs (Subversion et autres) réside dans la manière dont Git considère les données. Au niveau conceptuel, la plupart des autres VCSs gèrent l'information comme une liste de modifications de fichiers. Ces systèmes (CVS, Subversion, Perforce, Bazaar, et autres) considèrent l'information qu'il gèrent comme une liste de fichiers et les modifications effectuées sur chaque fichier dans le temps, comme illustré en Figure 1-4.
63 63
 
64  
-Insert 18333fig0104.png
65  
-Figure 1-4. Les autres systèmes tendent à enregistrer les données comme modifications à une version étalon de chaque fichier.
  64
+Insert 18333fig0104.png 
  65
+Figure 1-4. Les autres système tendent à sauvegarder l'information comme des modifications sur des fichiers d'origine.
66 66
 
67  
-Git n'approche pas l'enregistrement des données ainsi. A la place, Git conçoit ses données plutôt comme des copies instantanées d'un mini-système-de-fichiers. Chaque fois que vous _committez_, que vous sauvegardez l'état de votre projet dans Git, il prend un instantané de l'état de vos fichiers à ce moment-là et enregistre la référence à cet instantané. Pour plus d'efficacité, si les fichiers n'ont pas changé, Git ne l'enregistre pas de nouveau mais conserve un lien vers la version identique qu'il a déjà enregistrée. La figure 1-5 ressemble à comment Git conçoit ses données.
  67
+Git ne gère pas et ne stocke pas les informations de cette manière. A la place, Git pense ses données plus comme un instantané d'un mini système de fichiers. A chaque fois que vous commitez ou sauvez l'état du projet dan Git, il prend effectivement un instantané du contenu de votre espace de travail à ce moment et sauve une référence à cet instantané. Pour être efficace, si les fichiers n'ont pas changé, Git ne stocke pas le fichier à nouveau, juste une référence vers le fichier original qui n'a pas été modifié. Git pense ses données plus à la manière de la figure 1-5. 
68 68
 
69  
-Insert 18333fig0105.png
70  
-Figure 1-5. Git enregistre les données comme instantanés d'un projet dans le temps.
  69
+Insert 18333fig0105.png 
  70
+Figure 1-5. Git stocke les données comme des instantanés du projet au cours du temps
71 71
 
72  
-Il s'agit là d'une distinction importante entre Git et les autres SSV. Dans Git, presque tout les aspects du suivi de version que les autres systèmes ont hérité des générations précédentes sont reconsidérés. Cela fait de Git plus un mini-système-de-fichiers sur lequel s'appuient quelques outils d'une puissance incroyable, qu'un simple SSV. Nous reviendrons aux bénéfices de concevoir les données ainsi lorsque nous nous intéresserons aux branches dans le chapitre 3.
  72
+C'est une distinction importante entre Git et quasiment tous les autres VCSs. Celà permet à Git de reconsidérer quasiment tous les aspects de la gestion de version que la plupart des autres système ont copié des générations précédentes. Celà fait quasiment de Git un mini système de fichiers avec des outils incroyablement puissants construit par dessus, plutôt qu'un simple VCS. Nous explorerons les bénéfices qu'il y a à penser les données de cette manière quand nous aborderons la gestion de branches au Chapitre 3.
73 73
 
74  
-### Quasiment toutes les opérations sont locales ###
  74
+### Presque toutes les opération sont locales ###
75 75
 
76  
-La plupart des opérations dans Git nécessite seulement des fichiers et ressources locales pour fonctionner--généralement, il n'y a besoin d'aucune information en provenance d'un autre ordinateur sur votre réseau. Si vous avez l'habitude d'un SCSV où la majorité des opérations souffrent de la latence du réseau, cet aspect de Git vous laissera penser que les dieux de la vitesse lui ont transmis ces pouvoirs. En raison de la présence de l'intégralité de l'historique du projet sur votre disque local, presque toutes les opérations semblent instantanées.
  76
+La plupart des opération sous Git ne nécessite que des fichiers et ressources locales - généralement aucune information venant d'un autre ordinateur du réseau n'est nécessaire. Si vous êtes habitué à un CVCS où toutes les opérations sont ralenties par la latence des échanges réseau, cet aspect de Git vous fera penser que les dieux de la vitesse ont octroyé à Git des pouvoirs divins de vitesse. Comme vous disposez de l'historique complet du projet localement sur votre disque dur, la plupart des opérations semblent instantanées.
77 77
 
78  
-Par exemple, pour accéder à l'historique du projet, Git n'a pas besoin d'interroger un serveur distant : il le lit directement depuis votre base de données locale. Cela signifie que vous visualisez l'historique du projet presque instantanément. Si vous voulez consulter les modifications introduites entre la version courante d'un fichier et sa création un mois auparavant, Git peut accéder à l'état du fichier le mois précédent et effectuer un calcul des différences localement, au lieu d'interroger un serveur distant ou récupérer une version précédente du fichier pour faire le calcul localement.
  78
+Par exemple, pour parcourir l'historique d'un projet, Git n'a pas besoin d'aller la chercher sur un serveur pour vous l'afficher - Il n'a qu'à simplement la lire directement dans votre base de donnée locale. Celà signifie que vous avez quasi-instantanément accès à l'historique du projet.Si vous souhaitez connaître les modifications introduites entre la version actuelle d'un fichier et son état un mois auparavant, Git peut rechercher l'état du fichier un mois auparavant et réaliser le calcul de différence, au lieu d'avoir à demander cette différence à un serveur ou à devoir récupérer l'ancienne version sur le serveur pour calculer la différence localement.
79 79
 
80  
-Cela signifie également qu'il y a très peu de choses que vous ne puissiez faire hors-connexion, ou déconnecté(e) du réseau privé virtuel. Si vous prenez l'avion ou le train et désirez profiter du trajet pour travailler un peu, vous pouvez soumettre vos modifications avec bonheur jusqu'à ce que vous puissiez vous connecter pour synchroniser vos données. Une fois à la maison, si vous ne parvenez pas à restaurer la connexion vers votre réseau privé virtuel, vous pouvez tout de même travailler. Avec d'autres systèmes, ces situations s'avèrent impossibles ou très difficiles à mettre en oeuvre. Dans Perforce, par exemple, vous ne pouvez pas faire grand chose sans une connexion au serveur ; et dans Subversion ou CVS, vous pouvez modifier des fichiers, mais vous ne pouvez soumettre aucune modification (parce que votre base de données est déconnectée). Cela peut sembler anodin, mais vous pourriez être surpris(e) de la grande différence que cela peut constituer.
  80
+Celà signifie aussi qu'il y a très peu de choses que vous ne puissiez réaliser si vous n'êtes pas connecté ou hors VPN. Si vous voyagez en train ou en avion et voulez avancer votre travail, vous pouvez continuer à gérer vos versions sans soucis en attendant de pouvoir de nouveau vous connecter pour partager votre travail. Si vous êtes chez vous et ne pouvez avoir une liaison VPN avec votre entreprise, vous pouvez tout de même travailler. Pour de nombreux autres systèmes, faire de même est au choix impossible ou vraiment très contraignant. Avec Perforce par éxemple, vous ne pouvez pas faire grand'chose tant que vous n'êtes pas connecté au serveur de version ; et avec Subversion ou CVS, vous pouvez éditer les fichiers, mais vous ne pourrez pas gérer de version dans votre base de données (car celle-ci est sur le serveur non accessible). Celà peut sembler peu important a priori, mais vous seriez étonné de découvrir quelle grande différence ça peut faire à l'usage. 
81 81
 
82  
-### Git possède l'intégrité ###
  82
+### Git gère l'intégrité ###
83 83
 
84  
-Tout dans Git est soumis à une somme de contrôle, qui deviendra la référence, avant d'être enregistré. Cela veut dire qu'il est impossible de modifier le contenu d'aucun fichier ou répertoire sans que Git ne le sache. Cette fonctionnalité est intégrée dans Git au plus bas niveau aussi bien que dans sa philosophie. Vous ne pouvez perdre de l'information pendant les transferts, ni obtenir un fichier corrompu sans que Git ne puisse le détecter.
  84
+Dans Git,tout est vérifié par somme de contrôle avant d'être stocké et par la suite la somme de contrôle, signature unique, sert de référence. Celà signifie qu'il est impossible de modifier le contenu d'un fichier ou d'un répertoire sans que Git ne s'en aperçoive. Cette fonctionnalité est ancrée dans les fondations de Git et fait partie intégrante de sa philosphie. Vous ne pouvez pas perdre des données en cours de transfert ou corrompre un fichier sans que Git ne le détecte immédiatement.
85 85
 
86  
-Git utilise une signature SHA-1 pour les sommes de contrôle. Il s'agit d'une chaîne de 40 caractères hexadécimaux (de 0 à 9 et de A à F), une empreinte unique issue du contenu du fichier ou de la structure des répertoires dans Git. Une empreinte SHA-1 ressemble à ceci :
  86
+Le mécanisme que Git utilise pour réaliser les sommes de contrôle est appelé SHA-1. C'est une chaîne de caractères composée de 40 caractères héxadécimaux (de '0' à '9' et de 'a' à 'f') calculée en fonction du contenu du fichier ou de la structure du répertoire considéré. Une signature SHA-1 ressembe à ceci :
87 87
 
88 88
 	24b9da6552252987aa493b52f8696cd6d3b00373
89 89
 
90  
-Vous verrez ce genre d'empreintes un peu partout dans Git car il les utilise partout. En fait, Git enregistre tout non par nom de fichier, mais dans une base de données addressable par la signature SHA-1 des contenus.
  90
+Vous trouverez ces valeurs à peu près partout dans Git car il les utilise pour tout. En fait, Git stocke tout non pas avec des noms de fichier, mais dans la base de données Git indéxée par ces valeurs.
91 91
 
92  
-### Git ne fait (presque) qu'ajouter des données ###
  92
+### Généralement, Git ne fait qu'ajouter des données ###
93 93
 
94  
-Lorsque vous effectuez des opérations dans Git, presque toutes ne font qu'ajouter des données dans la base de données de Git. Il est très difficile de forcer le système à faire quelque chose qu'on ne puisse défaire ou à effacer des données d'un quelconque manière. Comme dans tous les SSV, vous pouvez perdre ou casser des modifications que vous n'avez pas encore consignées ; mais une fois que vous avez consigné une image de vos changements dans Git, il devient très difficile de les perdre, d'autant plus si vous synchronisez régulièrement votre dépôt vers un autre dépôt.
  94
+Quand vous réalisez des actions dans Git, la quasi-totalité d'entre elles ne font qu'ajouter des données dans la base de données de Git. Il est très difficile de faire réaliser au système des actions qui ne soient pas réversibles ou de lui faire effacer des données d'une quelconque manière. Par contre, comme dans la plupart des systèmes de gestion de version, vous pouvez perdre ou corrompre des modifications qui n'ont pas encore été entrées en base ; mais dès que vous avez commité un instantané dans Git, il est très difficile de le perdre, spécialement si en plus vous synchronisez votre base de données locale avec un dépot distant.
95 95
 
96  
-Cela rend Git agréable à utiliser parce que nous savons que nous pouvons expérimenter sans danger de détruire le projet. Pour une vision plus approfondie de la manière dont Git enregistre ses données, et les moyens de récupérer des données qui semblent perdues, voir "Sous le couvercle" dans la chapitre 9.
  96
+Celà fait de l'usage de Git un vrai plaisir, car on peut expérimenter sans danger de casser définitivement notre projet. Pour une information plus approfondie de la manière dont Git stocke ses données et de comment récupérer des données qui pourraient sembler perdues, référez-vous au chapitre 9 "Sous le capot".
97 97
 
98 98
 ### Les trois états ###
99 99
 
100  
-A présent, prêtez attention. Il s'agit de la chose principale à retenir concernant Git si vous voulez que le reste de votre apprentissage se passe sans encombre. Git possède trois états principaux dans lesquels vos fichiers peuvent se trouver : consigné, modifié ou en attente. Consigné signifie que les données sont enregistrées, à l'abri, dans votre base de données locale. Modifié veut dire que des changements ont eu lieu, mais qu'ils ne sont pas encore consignés. En attente implique que vous avez marqué un fichier modifié dans sa version courante pour qu'il intègre la prochaine image consignée.
  100
+Ici, il faut être attentif. Il est primordial de se souvenir de ce qui suit si vous souhaitez que le reste de votre apprentissage s'effectue sans difficulté. Git gère trois états dans lequel les fichiers peuvent résider : commité, modifié et indexé. Commité signifie que les données sont stockées en sécurité dans votre base de données locale. Modifié signifie que vous avez modifié le fichier mais qu'il n'a pas encore été commité en base. Indéxé signifie que vous avez marqué un fichier modifié dans sa version actuelle pour qu'il fasse partie du prochain instantané du projet.
101 101
 
102  
-Cela nous amène aux trois principales sections d'un projet Git : le répertoire Git, le répertoire de travail et la zone d'attente.
  102
+Ceci nous mène aux trois sections principales d'un projet Git : le répertoire Git, le répertoire de travail et la zone d'index.
103 103
 
104  
-Insert 18333fig0106.png
105  
-Figure 1-6. Le répertoire de travail, zone d'attente et le répertoire Git.
  104
+Insert 18333fig0106.png 
  105
+Figure 1-6. Répertoire de travail, zone d'index et répertoire Git.
106 106
 
107  
-Le répertoire Git est l'endroit ou Git enregistre les méta-données et la base de données d'objets pour votre projet. C'est la partie la plus importante de Git, et c'est ce qui est copié lors d'une opération de clonage du dépôt depuis une autre machine.
  107
+Le répertoire Git est l'endroit où Git stocke les métadonnées et la base de données des objets de votre projet. C'est la partie la plus importante de Git, et c'est ce qui est copié lorsque vous clonez une dépot depuis un autre ordinateur.
108 108
 
109  
-Le répertoire de travail est un retrait unique d'une version du projet. Ces fichiers sont retirés de la base de données compressée dans le répertoire Git et placés sur le disque pour être utilisés ou modifiés.
  109
+Le répertoire de travail est une extraction unique d'un version du projet. Ces fichiers sont extraits depuis la base de données compressée dans le répertoire Git et placés sur le disque pour pouvoir être utilisés ou modifiés.
110 110
 
111  
-La zone d'attente est un simple fichier, généralement placé dans le répertoire Git, qui contient l'information relative aux modifications qui intègreront la prochaine consignation. On l'appelle parfois l'index, mais l'appellation courante, qui devient le standard, est la zone d'attente.
  111
+La zone d'index est un simple fichier, généralement situé sans le répertoire Git, qui stocke les informations concernant ce qui fera partie du prochain instantané. 
112 112
 
113  
-L'usage fondamental de Git peut se décrire ainsi :
  113
+L'utilisation standard de Git se passe comme suit :
114 114
 
115  
-1.  Vous modifiez des fichiers dans votre répertoire de travail.
116  
-2.  Vous mettez les fichiers en attente, en ajoutant leur image à la zone d'attente.
117  
-3.  Vous consignez les fichiers, ce qui prend un instantané des fichiers en attente et l'enregistre définitivement dans votre répertoire Git.
  115
+1.	Vous modifiez des fichiers dans votre répertoire de travail
  116
+2.	Vous indéxez les fichiers modifiés, ce qui ajoute des instantanés de ces fichiers dans la zone d'index
  117
+3.	Vous réalisez un commit, ce qui a pour effet de basculer les instantanés des fichiers de l'index dans la base de donnée du répertoire Git.
118 118
 
119  
-Si une version particulière d'un fichier est présente dans le répertoire Git, elle est considérée comme consignée. Si elle est modifiée mais présente dans la zone d'attente, elle est en attente. Et si elle a été modifiée depuis le dernier retrait, mais n'est pas encore en attente, alors elle est considérée comme modifiée. Dans le chapitre 2, vous en apprendrez plus sur ces états et comment vous pouvez en tirez avantage ou éviter la zone d'attente entièrement.
  119
+Si une version particulière d'un fichier est dans le répertoire Git, il est considéré comme commité. S'il est modifié mais a été ajouté dans la zone d'index, il est indéxé. S'il a été modifié depuis le dernier instantané mais n'a pas été indéxé, il est modifié. Dans le chapitre 2, vous en apprendrez plus sur ces états et commment vous pouvez en tirer parti ou complètement les occulter.
120 120
 
121  
-## Installing Git ##
  121
+## Installation de Git ##
122 122
 
123  
-Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform.
  123
+Commençons donc à utiliser Git. La première des choses est de l'installer. Vous pouvez l'obtenir par de nombreuses manières ; les deux principales sont de l'installer à partir des sources ou d'installer un paquetage éxistant sur votre plateforme.
124 124
 
125  
-### Installing from Source ###
  125
+### Installation depuis les sources ###
126 126
 
127  
-If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.
  127
+Si vous le pouvez, il est généralement mieux d'installer Git à partir des sources, car vous obtiendrez la version la plus récente. Chaque nouvelle version de Git tend à inclure des améliorations utiles de l'interface utilisateur, donc récupérer la toute dernière version est souvent le mieux si vous savez compiler des logiciels à partir des sources. Comme la plupart du temps les distributions contiennent des version très anciennes de logiciels, à moins que vous ne travailliez sur une distribution très récente ou que vous n'utilisiez des backports, une installation à partir des sources est gage de meilleur fonctionnement.
128 128
 
129  
-To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies:
  129
+Pour installer Git, vous avez besoin des bibliothèques suivantes : curl, zlib, openssl, expat, libiconv. Par éxemple, si vous avez un système d'exploitation qui utilise yum (tel que Fedora) ou apt-get (tel qu'un système basé sur Debian), vous pouvez utiliser les commandes suivantes pour installer les dépendances :
130 130
 
131 131
 	$ yum install curl-devel expat-devel gettext-devel \
132 132
 	  openssl-devel zlib-devel
133 133
 
134 134
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
135 135
 	  libz-dev
136  
-
137  
-When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site:
  136
+	
  137
+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 :
138 138
 
139 139
 	http://git-scm.com/download
140  
-
141  
-Then, compile and install:
  140
+	
  141
+Puis, compiler et installer
142 142
 
143 143
 	$ tar -zxf git-1.6.0.5.tar.gz
144 144
 	$ cd git-1.6.0.5
145 145
 	$ make prefix=/usr/local all
146 146
 	$ sudo make prefix=/usr/local install
147 147
 
148  
-After this is done, you can also get Git via Git itself for updates:
  148
+Après ceci, vous pouvez obtenir Git par Git lui-même pour le mises à jour :
149 149
 
150 150
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
  151
+	
  152
+### Installation sur Linux ###
151 153
 
152  
-### Installing on Linux ###
153  
-
154  
-If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum:
  154
+Si vous souhaitez installer Git sur Linux via un installeur d'application, vous pouvez généralement le faire via le système de gestion de paquetage de base fourni avec votre distribution. Si vous êtes sur Fedora, vous pouvez utiliser yum :
155 155
 
156 156
 	$ yum install git-core
157 157
 
158  
-Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
  158
+Si vous êtes sur un système basé sur Debian, tel qu'Ubuntu, essayez apt-get :
159 159
 
160 160
 	$ apt-get install git-core
161 161
 
162  
-### Installing on Mac ###
  162
+### Installation sur Mac ###
163 163
 
164  
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
  164
+Il y a deux moyens simples d'installer Git sur Mac. Le plus simple et d'utiliser l'installateur graphique de Git que vous pouvez télécharger depuis les pages Google Code (Cf. Figure 1-7) :
165 165
 
166 166
 	http://code.google.com/p/git-osx-installer
167 167
 
168  
-Insert 18333fig0107.png
169  
-Figure 1-7. Git OS X installer.
  168
+Insert 18333fig0107.png 
  169
+Figure 1-7. Installateur OS X de Git.
170 170
 
171  
-The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
  171
+L'autre méthode consiste à installer Git par les MacPorts ((`http://www.macports.org`). Si vous avez installé MacPorts, installez Git par :
172 172
 
173 173
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
174 174
 
175  
-You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8).
  175
+Vous n'avez pas à ajouter tous les extras, mais vous souhaiterez surement inclure +svn dans le cas où vous chercheriez à utiliser Git avec des dépots Subversion (voir Chapitre 8).
176 176
 
177  
-### Installing on Windows ###
  177
+### Installation sur Windows ###
178 178
 
179  
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it:
  179
+Installer Git sur Windows est très facile. Le projet msysGit fournit une des procédures d'installation les plus faciles. Téléchargez simplement le fichier exe d'installateur depuis la page Google Code, et lancez-le :
180 180
 
181 181
 	http://code.google.com/p/msysgit
182 182
 
183  
-After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
  183
+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.
184 184
 
185  
-## First-Time Git Setup ##
  185
+## Paramétrage à la première utilisation de Git ##
186 186
 
187  
-Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
  187
+Maintenant que vous avez Git installé sur votre système, vous voudrez personnaliser votre environnement Git. Vous ne devriez avoir à réaliser ces réglages qu'une seule fois ; elles persisteront lors des mises à jour. Vous pouvez aussi les changer à tout instant en relançant les mêmes commandes.
188 188
 
189  
-Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
  189
+Git contient un outil appelé git config pour vous permettre de voir et modifier les variables de configuration qui contrôlent tous les aspects de l'apparence et du comportement de Git. Ces variables peuvent être stockées dans trois endroits différents :
190 190
 
191  
-*	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
192  
-*	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
193  
-*	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
  191
+*	Fichier `/etc/gitconfig` : Contient les valeurs pour tous les utilisateurs et tous les dépots du système. Si vous passez l'option `--system` à `git config`, il lit et écrit ce fichier spécifiquement.
  192
+*	Fichier `~/.gitconfig` : Spécifique à votre utilisateur. Vous pouvez forcer Git à lire et écrire ce fichier en passant l'option `--global`.
  193
+*	Fichier `config` dans le répertoire Git (c'est à dire, `.git/config`) du dépot en cours d'utilisation : spécifique au seul dépot en cours. Chaque niveau surcharge le niveau précédent, donc les valeurs dans `.git/config` surchargent celles de `/etc/gitconfig`.
194 194
 
195  
-On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Documents and Settings\$USER` for most people). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
  195
+Sur les systèmes Windows, Git recherche le fichier `.gitconfig` dans le répertoire `$HOME` (`C:\Documents and Settings\$USER` la plupart du temps). Il recherche tout de même `/etc/gitconfig`, bien qu'il soit relatif à la racine MSys, qui se trouve où vous aurez décidé d'installer Git sur votre système Windows.
196 196
 
197  
-### Your Identity ###
  197
+### Votre identité ###
198 198
 
199  
-The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around:
  199
+La première chose à faire après l'installation de Git est de renseigner votre nom et votre adress e-mail. C'est important car tous les commits Git utilisent cette information et elle est indélébile dans tous les commits que vous pourrez manipuler :
200 200
 
201 201
 	$ git config --global user.name "John Doe"
202 202
 	$ git config --global user.email johndoe@example.com
203 203
 
204  
-Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project.
  204
+Encore une fois, cette étape n'est nécessaire qu'une fois si vous passez l'option `--global`, parce que Git utilisera toujours cette information pour tout ce que votre utilisateur fera sur ce système. Si vous souhaitez surcharger ces valeurs avec un nom ou une adresse e-mail différents pour un projet spécifique, vous pouvez lancer ces commandes sans option `--global` lorsque vous êtes dans ce projet.
205 205
 
206  
-### Your Editor ###
  206
+### Votre éditeur de texte ###
207 207
 
208  
-Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:
  208
+À présent que votre identité est renseignée, vous pouvez configurer l'éditeur de texte qui sera utilisé par défaut quand Git vous enjoint à taper un message. Par défaut, Git utilise votre éditeur par défaut au niveau système, qui est généralement Vi ou Vim. Si vous souhaitez utiliser un éditeur de texte différent, comme Emacs, vous pouvez faire ce qui suit :
209 209
 
210 210
 	$ git config --global core.editor emacs
  211
+	
  212
+### Votre outil de diff ###
211 213
 
212  
-### Your Diff Tool ###
213  
-
214  
-Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff:
  214
+Une autre option utile est le paramétrage de l'outil de diff à utiliser pour la résolution des conflits de fusion. Supposons que vous souhaitiez utiliser vimdiff :
215 215
 
216 216
 	$ git config --global merge.tool vimdiff
217 217
 
218  
-Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that.
  218
+Git accepte kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, et opendiff comme outils valides de fusion. Vous pouvez aussi paramétrer un outil personnalisé ; référez-vous au chapitre 7 pour plus d'information sur cette procédure.
219 219
 
220  
-### Checking Your Settings ###
  220
+### Vérifier vos paramètres ###
221 221
 
222  
-If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point:
  222
+Si vous souhaitez vérifier vos réglages, vous pouvez utiliser la commande `git config --list` pour lister tous les réglages que Git a pu trouver jusqu'ici :
223 223
 
224 224
 	$ git config --list
225 225
 	user.name=Scott Chacon
@@ -230,28 +230,28 @@ If you want to check your settings, you can use the `git config --list` command
230 230
 	color.diff=auto
231 231
 	...
232 232
 
233  
-You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees.
  233
+Vous pourrez voir certains paramètres apparaître plusieurs fois, car Git lit les mêmes paramètres depuis plusieurs fichiers (`/etc/gitconfig` et `~/.gitconfig`, par exemple). Git utilise la dernière valeur pour chaque paramètre.
234 234
 
235  
-You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
  235
+Vous pouvez aussi vérifier la valeur particulière utilisée d'un paramètre en tapant `git config {paramètre}`:
236 236
 
237 237
 	$ git config user.name
238 238
 	Scott Chacon
239 239
 
240  
-## Getting Help ##
  240
+## Obtenir de l'aide ##
241 241
 
242  
-If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands:
  242
+Si vous avez besoin d'aide pour utiliser Git, il y a trois moyens d'obtenir les pages de manuel (manpage) pour toutes les commandes de Git :
243 243
 
244  
-	$ git help <verb>
  244
+	$ git help <verbe>
245 245
 	$ git <verb> --help
246  
-	$ man git-<verb>
  246
+	$ man git-<verbe>
247 247
 
248  
-For example, you can get the manpage help for the config command by running
  248
+Par exemple, vous pouvez obtenir la page de manuel pour la commande config en lançant :
249 249
 
250 250
 	$ git help config
251 251
 
252  
-These commands are nice because you can access them anywhere, even offline.
253  
-If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.
  252
+Ces commandes sont vraiment sympathiques car vous pouvez y accéder depuis partout, y compris hors connexion.
  253
+Si les manpages et ce livre ne sont pas suffisants, vous pouvez essayer les canaux `#git` ou `#github` sur le serveur IRC Freenode (irc.freenode.net). Ces canaux sont régulièrement peuplés de centaines de personnes qui ont une bonne connaissance de Git et sont souvent prêtes à aider.
254 254
 
255  
-## Summary ##
  255
+## Résumé ##
256 256
 
257  
-You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics.
  257
+Vous devriez avoir à présent une compréhension initiale de ce que Git est et en quoi il est différent des CVCS que vous pourriez déjà avoir utilisés. Vous devriez aussi avoir une version de Git en état de fonctionnement sur votre système, paramétrée avec votre identité. Il est temps d'apprendre les bases d'utilisation de Git.
1,121  fr/02-git-basics/01-chapter2.markdown
Source Rendered
... ...
@@ -0,0 +1,1121 @@
  1
+# Git Basics #
  2
+
  3
+If you can read only one chapter to get going with Git, this is it. This chapter covers every basic command you need to do the vast majority of the things you’ll eventually spend your time doing with Git. By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. We’ll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories.
  4
+
  5
+## Getting a Git Repository ##
  6
+
  7
+You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server.
  8
+
  9
+### Initializing a Repository in an Existing Directory ###
  10
+
  11
+If you’re starting to track an existing project in Git, you need to go to the project’s directory and type
  12
+
  13
+	$ git init
  14
+
  15
+This creates a new subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton. At this point, nothing in your project is tracked yet. (See Chapter 9 for more information about exactly what files are contained in the `.git` directory you just created.)
  16
+
  17
+If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a commit:
  18
+
  19
+	$ git add *.c
  20
+	$ git add README
  21
+	$ git commit –m 'initial project version'
  22
+
  23
+We’ll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit.
  24
+
  25
+### Cloning an Existing Repository ###
  26
+
  27
+If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone. If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is clone and not checkout. This is an important distinction — Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run `git clone`. In fact, if your server disk gets corrupted, you can use any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there—see Chapter 4 for more details).
  28
+
  29
+You clone a repository with `git clone [url]`. For example, if you want to clone the Ruby Git library called Grit, you can do so like this:
  30
+
  31
+	$ git clone git://github.com/schacon/grit.git
  32
+
  33
+That creates a directory named "grit", initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new `grit` directory, you’ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option:
  34
+
  35
+	$ git clone git://github.com/schacon/grit.git mygrit
  36
+
  37
+That command does the same thing as the previous one, but the target directory is called mygrit.
  38
+
  39
+Git has a number of different transfer protocols you can use. The previous example uses the `git://` protocol, but you may also see `http(s)://` or `user@server:/path.git`, which uses the SSH transfer protocol. Chapter 4 will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each.
  40
+
  41
+## Recording Changes to the Repository ##
  42
+
  43
+You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record.
  44
+
  45
+Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area.  When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. 
  46
+
  47
+As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1.
  48
+
  49
+Insert 18333fig0201.png 
  50
+Figure 2-1. The lifecycle of the status of your files.
  51
+
  52
+### Checking the Status of Your Files ###
  53
+
  54
+The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this:
  55
+
  56
+	$ git status
  57
+	# On branch master
  58
+	nothing to commit (working directory clean)
  59
+
  60
+This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
  61
+
  62
+Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so:
  63
+
  64
+	$ vim README
  65
+	$ git status
  66
+	# On branch master
  67
+	# Untracked files:
  68
+	#   (use "git add <file>..." to include in what will be committed)
  69
+	#
  70
+	#	README
  71
+	nothing added to commit but untracked files present (use "git add" to track)
  72
+
  73
+You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.
  74
+
  75
+### Tracking New Files ###
  76
+
  77
+In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this:
  78
+
  79
+	$ git add README
  80
+
  81
+If you run your status command again, you can see that your README file is now tracked and staged:
  82
+
  83
+	$ git status
  84
+	# On branch master
  85
+	# Changes to be committed:
  86
+	#   (use "git reset HEAD <file>..." to unstage)
  87
+	#
  88
+	#	new file:   README
  89
+	#
  90
+
  91
+You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) — that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
  92
+
  93
+### Staging Modified Files ###
  94
+
  95
+Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this:
  96
+
  97
+	$ git status
  98
+	# On branch master
  99
+	# Changes to be committed:
  100
+	#   (use "git reset HEAD <file>..." to unstage)
  101
+	#
  102
+	#	new file:   README
  103
+	#
  104
+	# Changed but not updated:
  105
+	#   (use "git add <file>..." to update what will be committed)
  106
+	#
  107
+	#	modified:   benchmarks.rb
  108
+	#
  109
+
  110
+The benchmarks.rb file appears under a section named “Changed but not updated” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the benchmarks.rb file, and then run `git status` again:
  111
+
  112
+	$ git add benchmarks.rb
  113
+	$ git status
  114
+	# On branch master
  115
+	# Changes to be committed:
  116
+	#   (use "git reset HEAD <file>..." to unstage)
  117
+	#
  118
+	#	new file:   README
  119
+	#	modified:   benchmarks.rb
  120
+	#
  121
+
  122
+Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:
  123
+
  124
+	$ vim benchmarks.rb 
  125
+	$ git status
  126
+	# On branch master
  127
+	# Changes to be committed:
  128
+	#   (use "git reset HEAD <file>..." to unstage)
  129
+	#
  130
+	#	new file:   README
  131
+	#	modified:   benchmarks.rb
  132
+	#
  133
+	# Changed but not updated:
  134
+	#   (use "git add <file>..." to update what will be committed)
  135
+	#
  136
+	#	modified:   benchmarks.rb
  137
+	#
  138
+
  139
+What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:
  140
+
  141
+	$ git add benchmarks.rb
  142
+	$ git status
  143
+	# On branch master
  144
+	# Changes to be committed:
  145
+	#   (use "git reset HEAD <file>..." to unstage)
  146
+	#
  147
+	#	new file:   README
  148
+	#	modified:   benchmarks.rb
  149
+	#
  150
+
  151
+### Ignoring Files ###
  152
+
  153
+Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore.  Here is an example .gitignore file:
  154
+
  155
+	$ cat .gitignore
  156
+	*.[oa]
  157
+	*~
  158
+
  159
+The first line tells Git to ignore any files ending in .o or .a — object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.
  160
+
  161
+The rules for the patterns you can put in the .gitignore file are as follows:
  162
+
  163
+*	Blank lines or lines starting with # are ignored.
  164
+*	Standard glob patterns work.
  165
+*	You can end patterns with a forward slash (`/`) to specify a directory.
  166
+*	You can negate a pattern by starting it with an exclamation point (`!`).
  167
+
  168
+Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9) . 
  169
+
  170
+Here is another example .gitignore file:
  171
+
  172
+	# a comment – this is ignored
  173
+	*.a       # no .a files
  174
+	!lib.a    # but do track lib.a, even though you're ignoring .a files above
  175
+	/TODO     # only ignore the root TODO file, not subdir/TODO
  176
+	build/    # ignore all files in the build/ directory
  177
+	doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt
  178
+
  179
+### Viewing Your Staged and Unstaged Changes ###
  180
+
  181
+If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. 
  182
+
  183
+Let’s say you edit and stage the README file again and then edit the benchmarks.rb file without staging it. If you run your `status` command, you once again see something like this:
  184
+
  185
+	$ git status
  186
+	# On branch master
  187
+	# Changes to be committed:
  188
+	#   (use "git reset HEAD <file>..." to unstage)
  189
+	#
  190
+	#	new file:   README
  191
+	#
  192
+	# Changed but not updated:
  193
+	#   (use "git add <file>..." to update what will be committed)
  194
+	#
  195
+	#	modified:   benchmarks.rb
  196
+	#
  197
+
  198
+To see what you’ve changed but not yet staged, type `git diff` with no other arguments:
  199
+
  200
+	$ git diff
  201
+	diff --git a/benchmarks.rb b/benchmarks.rb
  202
+	index 3cb747f..da65585 100644
  203
+	--- a/benchmarks.rb
  204
+	+++ b/benchmarks.rb
  205
+	@@ -36,6 +36,10 @@ def main
  206
+	           @commit.parents[0].parents[0].parents[0]
  207
+	         end
  208
+
  209
+	+        run_code(x, 'commits 1') do
  210
+	+          git.commits.size
  211
+	+        end
  212
+	+
  213
+	         run_code(x, 'commits 2') do
  214
+	           log = git.commits('master', 15)
  215
+	           log.size
  216
+
  217
+That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.
  218
+
  219
+If you want to see what you’ve staged that will go into your next commit, you can use `git diff –-cached`. (In Git versions 1.6.1 and later, you can also use `git diff –-staged`, which may be easier to remember.) This command compares your staged changes to your last commit:
  220
+
  221
+	$ git diff --cached
  222
+	diff --git a/README b/README
  223
+	new file mode 100644
  224
+	index 0000000..03902a1
  225
+	--- /dev/null
  226
+	+++ b/README2
  227
+	@@ -0,0 +1,5 @@
  228
+	+grit
  229
+	+ by Tom Preston-Werner, Chris Wanstrath
  230
+	+ http://github.com/mojombo/grit
  231
+	+
  232
+	+Grit is a Ruby library for extracting information from a Git repository
  233
+
  234
+It’s important to note that `git diff` by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. This can be confusing, because if you’ve staged all of your changes, `git diff` will give you no output.
  235
+
  236
+For another example, if you stage the benchmarks.rb file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged:
  237
+
  238
+	$ git add benchmarks.rb
  239
+	$ echo '# test line' >> benchmarks.rb
  240
+	$ git status
  241
+	# On branch master
  242
+	#
  243
+	# Changes to be committed:
  244
+	#
  245
+	#	modified:   benchmarks.rb
  246
+	#
  247
+	# Changed but not updated:
  248
+	#
  249
+	#	modified:   benchmarks.rb
  250
+	#
  251
+
  252
+Now you can use `git diff` to see what is still unstaged
  253
+
  254
+	$ git diff 
  255
+	diff --git a/benchmarks.rb b/benchmarks.rb
  256
+	index e445e28..86b2f7c 100644
  257
+	--- a/benchmarks.rb
  258
+	+++ b/benchmarks.rb
  259
+	@@ -127,3 +127,4 @@ end
  260
+	 main()
  261
+
  262
+	 ##pp Grit::GitRuby.cache_client.stats 
  263
+	+# test line
  264
+
  265
+and `git diff --cached` to see what you’ve staged so far:
  266
+
  267
+	$ git diff --cached
  268
+	diff --git a/benchmarks.rb b/benchmarks.rb
  269
+	index 3cb747f..e445e28 100644
  270
+	--- a/benchmarks.rb
  271
+	+++ b/benchmarks.rb
  272
+	@@ -36,6 +36,10 @@ def main
  273
+	          @commit.parents[0].parents[0].parents[0]
  274
+	        end
  275
+
  276
+	+        run_code(x, 'commits 1') do
  277
+	+          git.commits.size
  278
+	+        end
  279
+	+              
  280
+	        run_code(x, 'commits 2') do
  281
+	          log = git.commits('master', 15)
  282
+	          log.size
  283
+
  284
+### Committing Your Changes ###
  285
+
  286
+Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk.
  287
+In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`:
  288
+
  289
+	$ git commit
  290
+
  291
+Doing so launches your editor of choice. (This is set by your shell’s `$EDITOR` environment variable — usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in Chapter 1). 
  292
+
  293
+The editor displays the following text (this example is a Vim screen):
  294
+
  295
+	# Please enter the commit message for your changes. Lines starting
  296
+	# with '#' will be ignored, and an empty message aborts the commit.
  297
+	# On branch master
  298
+	# Changes to be committed:
  299
+	#   (use "git reset HEAD <file>..." to unstage)
  300
+	#
  301
+	#       new file:   README
  302
+	#       modified:   benchmarks.rb 
  303
+	~
  304
+	~
  305
+	~
  306
+	".git/COMMIT_EDITMSG" 10L, 283C
  307
+
  308
+You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the `-v` option to `git commit`. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out).
  309
+
  310
+Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this:
  311
+
  312
+	$ git commit -m "Story 182: Fix benchmarks for speed"
  313
+	[master]: created 463dc4f: "Fix benchmarks for speed"
  314
+	 2 files changed, 3 insertions(+), 0 deletions(-)
  315
+	 create mode 100644 README
  316
+
  317
+Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.
  318
+
  319
+Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later.
  320
+
  321
+### Skipping the Staging Area ###
  322
+
  323
+Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
  324
+
  325
+	$ git status
  326
+	# On branch master
  327
+	#
  328
+	# Changed but not updated:
  329
+	#
  330
+	#	modified:   benchmarks.rb
  331
+	#
  332
+	$ git commit -a -m 'added new benchmarks'
  333
+	[master 83e38c7] added new benchmarks
  334
+	 1 files changed, 5 insertions(+), 0 deletions(-)
  335
+
  336
+Notice how you don’t have to run `git add` on the benchmarks.rb file in this case before you commit.
  337
+
  338
+### Removing Files ###
  339
+
  340
+To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The `git rm` command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around.
  341
+
  342
+If you simply remove the file from your working directory, it shows up under the “Changed but not updated” (that is, _unstaged_) area of your `git status` output:
  343
+
  344
+	$ rm grit.gemspec
  345
+	$ git status
  346
+	# On branch master
  347
+	#
  348
+	# Changed but not updated:
  349
+	#   (use "git add/rm <file>..." to update what will be committed)
  350
+	#
  351
+	#       deleted:    grit.gemspec
  352
+	#
  353
+
  354
+Then, if you run `git rm`, it stages the file’s removal:
  355
+
  356
+	$ git rm grit.gemspec
  357
+	rm 'grit.gemspec'
  358
+	$ git status
  359
+	# On branch master
  360
+	#
  361
+	# Changes to be committed:
  362
+	#   (use "git reset HEAD <file>..." to unstage)
  363
+	#
  364
+	#       deleted:    grit.gemspec
  365
+	#
  366
+
  367
+The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.
  368
+
  369
+Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option:
  370
+
  371
+	$ git rm --cached readme.txt
  372
+
  373
+You can pass files, directories, and file-glob patterns to the `git rm` command. That means you can do things such as
  374
+
  375
+	$ git rm log/\*.log
  376
+
  377
+Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this:
  378
+
  379
+	$ git rm \*~
  380
+
  381
+This command removes all files that end with `~`.
  382
+
  383
+### Moving Files ###
  384
+
  385
+Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later.
  386
+
  387
+Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a file in Git, you can run something like
  388
+
  389
+	$ git mv file_from file_to
  390
+
  391
+and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file:
  392
+
  393
+	$ git mv README.txt README
  394
+	$ git status
  395
+	# On branch master
  396
+	# Your branch is ahead of 'origin/master' by 1 commit.
  397
+	#
  398
+	# Changes to be committed:
  399
+	#   (use "git reset HEAD <file>..." to unstage)
  400
+	#
  401
+	#       renamed:    README.txt -> README
  402
+	#
  403
+
  404
+However, this is equivalent to running something like this:
  405
+
  406
+	$ mv README.txt README
  407
+	$ git rm README.txt
  408
+	$ git add README
  409
+
  410
+Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
  411
+
  412
+## Viewing the Commit History ##
  413
+
  414
+After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the `git log` command.
  415
+
  416
+These examples use a very simple project called simplegit that I often use for demonstrations. To get the project, run 
  417
+
  418
+	git clone git://github.com/schacon/simplegit-progit.git
  419
+
  420
+When you run `git log` in this project, you should get output that looks something like this:
  421
+
  422
+	$ git log
  423
+	commit ca82a6dff817ec66f44342007202690a93763949
  424
+	Author: Scott Chacon <schacon@gee-mail.com>
  425
+	Date:   Mon Mar 17 21:52:11 2008 -0700
  426
+
  427
+	    changed the version number
  428
+
  429
+	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
  430
+	Author: Scott Chacon <schacon@gee-mail.com>
  431
+	Date:   Sat Mar 15 16:40:33 2008 -0700
  432
+
  433
+	    removed unnecessary test code
  434
+
  435
+	commit a11bef06a3f659402fe7563abf99ad00de2209e6
  436
+	Author: Scott Chacon <schacon@gee-mail.com>
  437
+	Date:   Sat Mar 15 10:31:28 2008 -0700
  438
+
  439
+	    first commit
  440
+
  441
+By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order. That is, the most recent commits show up first. As you can see, this command lists each commit with its SHA-1 checksum, the author’s name and e-mail, the date written, and the commit message.
  442
+
  443
+A huge number and variety of options to the `git log` command are available to show you exactly what you’re looking for. Here, we’ll show you some of the most-used options.
  444
+
  445
+One of the more helpful options is `-p`, which shows the diff introduced in each commit. You can also use `-2`, which limits the output to only the last two entries:
  446
+
  447
+	$ git log –p -2
  448
+	commit ca82a6dff817ec66f44342007202690a93763949
  449
+	Author: Scott Chacon <schacon@gee-mail.com>
  450
+	Date:   Mon Mar 17 21:52:11 2008 -0700
  451
+
  452
+	    changed the version number
  453
+
  454
+	diff --git a/Rakefile b/Rakefile
  455
+	index a874b73..8f94139 100644
  456
+	--- a/Rakefile
  457
+	+++ b/Rakefile
  458
+	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
  459
+	 spec = Gem::Specification.new do |s|
  460
+	-    s.version   =   "0.1.0"
  461
+	+    s.version   =   "0.1.1"
  462
+	     s.author    =   "Scott Chacon"
  463
+
  464
+	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
  465
+	Author: Scott Chacon <schacon@gee-mail.com>
  466
+	Date:   Sat Mar 15 16:40:33 2008 -0700
  467
+
  468
+	    removed unnecessary test code
  469
+
  470
+	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
  471
+	index a0a60ae..47c6340 100644
  472
+	--- a/lib/simplegit.rb
  473
+	+++ b/lib/simplegit.rb
  474
+	@@ -18,8 +18,3 @@ class SimpleGit
  475
+	     end
  476
+
  477
+	 end
  478
+	-
  479
+	-if $0 == __FILE__
  480
+	-  git = SimpleGit.new
  481
+	-  puts git.show
  482
+	-end
  483
+	\ No newline at end of file
  484
+
  485
+This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
  486
+You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option:
  487
+
  488
+	$ git log --stat 
  489
+	commit ca82a6dff817ec66f44342007202690a93763949
  490
+	Author: Scott Chacon <schacon@gee-mail.com>
  491
+	Date:   Mon Mar 17 21:52:11 2008 -0700
  492
+
  493
+	    changed the version number
  494
+
  495
+	 Rakefile |    2 +-
  496
+	 1 files changed, 1 insertions(+), 1 deletions(-)
  497
+
  498
+	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
  499
+	Author: Scott Chacon <schacon@gee-mail.com>
  500
+	Date:   Sat Mar 15 16:40:33 2008 -0700
  501
+
  502
+	    removed unnecessary test code
  503
+
  504
+	 lib/simplegit.rb |    5 -----
  505
+	 1 files changed, 0 insertions(+), 5 deletions(-)
  506
+
  507
+	commit a11bef06a3f659402fe7563abf99ad00de2209e6
  508
+	Author: Scott Chacon <schacon@gee-mail.com>
  509
+	Date:   Sat Mar 15 10:31:28 2008 -0700
  510
+
  511
+	    first commit
  512
+
  513
+	 README           |    6 ++++++
  514
+	 Rakefile         |   23 +++++++++++++++++++++++
  515
+	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
  516
+	 3 files changed, 54 insertions(+), 0 deletions(-)
  517
+
  518
+As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.
  519
+Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The oneline option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:
  520
+
  521
+	$ git log --pretty=oneline
  522
+	ca82a6dff817ec66f44342007202690a93763949 changed the version number
  523
+	085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
  524
+	a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
  525
+
  526
+The most interesting option is `format`, which allows you to specify your own log output format. This is especially useful when you’re generating output for machine parsing — because you specify the format explicitly, you know it won’t change with updates to Git:
  527
+
  528
+	$ git log --pretty=format:"%h - %an, %ar : %s"
  529
+	ca82a6d - Scott Chacon, 11 months ago : changed the version number
  530
+	085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
  531
+	a11bef0 - Scott Chacon, 11 months ago : first commit
  532
+
  533
+Table 2-1 lists some of the more useful options that format takes.
  534
+
  535
+	Option	Description of Output
  536
+	%H	Commit hash
  537
+	%h	Abbreviated commit hash
  538
+	%T	Tree hash
  539
+	%t	Abbreviated tree hash
  540
+	%P	Parent hashes
  541
+	%p	Abbreviated parent hashes
  542
+	%an	Author name
  543
+	%ae	Author e-mail
  544
+	%ad	Author date (format respects the –date= option)
  545
+	%ar	Author date, relative
  546
+	%cn	Committer name
  547
+	%ce	Committer email
  548
+	%cd	Committer date
  549
+	%cr	Committer date, relative
  550
+	%s	Subject
  551
+
  552
+You may be wondering what the difference is between _author_ and _committer_. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in Chapter 5.
  553
+
  554
+The oneline and format options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository:
  555
+
  556
+	$ git log --pretty=format:"%h %s" --graph
  557
+	* 2d3acf9 ignore errors from SIGCHLD on trap
  558
+	*  5e3ee11 Merge branch 'master' of git://github.com/dustin/grit
  559
+	|\  
  560
+	| * 420eac9 Added a method for getting the current branch.
  561
+	* | 30e367c timeout code and tests
  562
+	* | 5a09431 add timeout protection to grit
  563
+	* | e1193f8 support for heads with slashes in them
  564
+	|/  
  565
+	* d6016bc require time for xmlschema
  566
+	*  11d191e Merge branch 'defunkt' into local
  567
+
  568
+Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command.
  569
+
  570
+	Option	Description
  571
+	-p	Show the patch introduced with each commit.
  572
+	--stat	Show statistics for files modified in each commit.
  573
+	--shortstat	Display only the changed/insertions/deletions line from the --stat command.
  574
+	--name-only	Show the list of files modified after the commit information.
  575
+	--name-status	Show the list of files affected with added/modified/deleted information as well.
  576
+	--abbrev-commit	Show only the first few characters of the SHA-1 checksum instead of all 40.
  577
+	--relative-date	Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
  578
+	--graph	Display an ASCII graph of the branch and merge history beside the log output.
  579
+	--pretty	Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
  580
+
  581
+### Limiting Log Output ###
  582
+
  583
+In addition to output-formatting options, git log takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which show only the last two commits. In fact, you can do `-<n>`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time.
  584
+
  585
+However, the time-limiting options such as `--since` and `--until` are very useful. For example, this command gets the list of commits made in the last two weeks:
  586
+
  587
+	$ git log --since=2.weeks
  588
+
  589
+This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”.
  590
+
  591
+You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.)
  592
+
  593
+The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options.
  594
+
  595
+In Table 2-3 we’ll list these and a few other common options for your reference.
  596
+
  597
+	Option	Description
  598
+	-(n)	Show only the last n commits
  599
+	--since, --after	Limit the commits to those made after the specified date.
  600
+	--until, --before	Limit the commits to those made before the specified date.
  601
+	--author	Only show commits in which the author entry matches the specified string.
  602
+	--committer	Only show commits in which the committer entry matches the specified string.
  603
+
  604
+For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:
  605
+
  606
+	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
  607
+	   --before="2008-11-01" --no-merges -- t/
  608
+	5610e3b - Fix testcase failure when extended attribute
  609
+	acd3b9e - Enhance hold_lock_file_for_{update,append}()
  610
+	f563754 - demonstrate breakage of detached checkout wi
  611
+	d1a43f2 - reset --hard/read-tree --reset -u: remove un
  612
+	51a94af - Fix "checkout --track -b newbranch" on detac
  613
+	b0ad11e - pull: allow "git pull origin $something:$cur
  614
+
  615
+Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria.
  616
+
  617
+### Using a GUI to Visualize History ###
  618
+
  619
+If you like to use a more graphical tool to visualize your commit history, you may want to take a look at a Tcl/Tk program called gitk that is distributed with Git. Gitk is basically a visual `git log` tool, and it accepts nearly all the filtering options that `git log` does. If you type gitk on the command line in your project, you should see something like Figure 2-2.
  620
+
  621
+Insert 18333fig0202.png 
  622
+Figure 2-2. The gitk history visualizer.
  623
+
  624
+You can see the commit history in the top half of the window along with a nice ancestry graph. The diff viewer in the bottom half of the window shows you the changes introduced at any commit you click.
  625
+
  626
+## Undoing Things ##
  627
+
  628
+At any stage, you may want to undo something. Here, we’ll review a few basic tools for undoing changes that you’ve made. Be careful, because you can’t always undo some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong.
  629
+
  630
+### Changing Your Last Commit ###
  631
+
  632
+One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the `--amend` option:
  633
+
  634
+	$ git commit --amend
  635
+
  636
+This command takes your staging area and uses it for the commit. If you’ve have made no changes since your last commit (for instance, you run this command immediately after your previous commit), then your snapshot will look exactly the same and all you’ll change is your commit message.
  637
+
  638
+The same commit-message editor fires up, but it already contains the message of your previous commit. You can edit the message the same as always, but it overwrites your previous commit.
  639
+
  640
+As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this:
  641
+
  642
+	$ git commit -m 'initial commit'
  643
+	$ git add forgotten_file
  644
+	$ git commit --amend 
  645
+
  646
+All three of these commands end up with a single commit — the second commit replaces the results of the first.
  647
+
  648
+### Unstaging a Staged File ###
  649
+
  650
+The next two sections demonstrate how to wrangle your staging area and working directory changes. The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. For example, let’s say you’ve changed two files and want to commit them as two separate changes, but you accidentally type `git add *` and stage them both. How can you unstage one of the two? The `git status` command reminds you:
  651
+
  652
+	$ git add .
  653
+	$ git status
  654
+	# On branch master
  655
+	# Changes to be committed:
  656
+	#   (use "git reset HEAD <file>..." to unstage)
  657
+	#
  658
+	#       modified:   README.txt
  659
+	#       modified:   benchmarks.rb
  660
+	#
  661
+
  662
+Right below the “Changes to be committed” text, it says use `git reset HEAD <file>...` to unstage. So, let’s use that advice to unstage the benchmarks.rb file:
  663
+
  664
+	$ git reset HEAD benchmarks.rb 
  665
+	benchmarks.rb: locally modified
  666
+	$ git status
  667
+	# On branch master
  668
+	# Changes to be committed:
  669
+	#   (use "git reset HEAD <file>..." to unstage)
  670
+	#
  671
+	#       modified:   README.txt
  672
+	#
  673
+	# Changed but not updated:
  674
+	#   (use "git add <file>..." to update what will be committed)
  675
+	#   (use "git checkout -- <file>..." to discard changes in working directory)
  676