Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

[fr] Typographical improvements

Use French double quotes, more unbreakable spaces,
   more long dashes, more ** around kept English terms, etc.
  • Loading branch information...
commit b1951b628b3d091078d5360abd82639f7090c6dc 1 parent 93c71bf
@PhiLhoSoft PhiLhoSoft authored
View
1  .gitignore
@@ -13,3 +13,4 @@ epub/temp
*~
.#*
figures/*
+*/*.session
View
6 fr/01-introduction/01-chapter1.markdown
@@ -49,7 +49,7 @@ 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.
+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.
### Les systèmes de gestion de version distribués ###
@@ -118,7 +118,7 @@ Nous explorerons les bénéfices qu'il y a à penser les données de cette mani
### Presque toutes les opérations sont locales ###
-La plupart des opérations de 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.
+La plupart des opérations de 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é leurs pouvoirs à Git.
Comme vous disposez de l'historique complet du projet localement sur votre disque dur, la plupart des opérations semblent instantanées.
@@ -160,7 +160,7 @@ Par contre, comme dans la plupart des systèmes de gestion de version, vous pouv
mais dès que vous avez validé 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épôt distant.
Cela fait de l'usage de Git un vrai plaisir, car on peut expérimenter sans danger de casser définitivement son projet.
-Pour une information plus approfondie sur la manière dont Git stocke ses données et comment récupérer des données qui pourraient sembler perdues, référez-vous au chapitre 9 "Les tripes de Git".
+Pour une information plus approfondie sur la manière dont Git stocke ses données et comment récupérer des données qui pourraient sembler perdues, référez-vous au chapitre 9 « Les tripes de Git ».
### Les trois états ###
View
16 fr/03-git-branching/01-chapter3.markdown
@@ -24,7 +24,7 @@ Indexer les fichiers signifie calculer la somme de contrôle pour chacun (la fon
$ git add LISEZMOI test.rb LICENCE
$ git commit -m 'commit initial de mon projet'
-Lorsque vous créez le *commit* en lançant la commande `git *commit*`, Git calcule la somme de contrôle de chaque répertoire (ici, seulement pour le répertoire racine) et stocke ces objets arbres dans le dépôt Git.
+Lorsque vous créez le *commit* en lançant la commande `git commit`, Git calcule la somme de contrôle de chaque répertoire (ici, seulement pour le répertoire racine) et stocke ces objets arbres dans le dépôt Git.
Git crée alors un objet *commit* qui contient les méta-données et un pointeur vers l'arbre projet d'origine de manière à pouvoir recréer l'instantané si besoin.
Votre dépôt Git contient à présent cinq objets :
@@ -65,7 +65,7 @@ Il conserve un pointeur spécial appelé `HEAD`.
Remarquez que sous cette appellation se cache un concept très différent de celui utilisé dans les autres VCS tels que Subversion ou CVS.
Dans Git, c'est un pointeur sur la branche locale où vous vous trouvez.
Dans notre cas, vous vous trouvez toujours sur `master`.
-La commande git branch n'a fait que créer une nouvelle branche — elle n'a pas fait basculer la copie de travail vers cette branche (Cf. figure 3-5).
+La commande `git branch` n'a fait que créer une nouvelle branche — elle n'a pas fait basculer la copie de travail vers cette branche (cf. figure 3-5).
Insert 18333fig0305.png
Figure 3-5. fichier `HEAD` pointant sur la branche active
@@ -99,7 +99,7 @@ Retournons sur la branche `master` :
La figure 3-8 montre le résultat.
Insert 18333fig0308.png
-Figure 3-8. `HEAD` se déplace sur une autre branche lors d'un checkout.
+Figure 3-8. `HEAD` se déplace sur une autre branche lors d'un *checkout*.
Cette commande a réalisé deux actions.
Elle a remis le pointeur `HEAD` sur la branche `master` et elle a replacé les fichiers de la copie de travail dans l'état pointé par `master`.
@@ -220,7 +220,7 @@ Vous réalisez ceci au moyen de la commande `git merge` :
LISEZMOI | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
-Vous noterez la mention "Fast forward" qui signifie avance rapide dans cette fusion.
+Vous noterez la mention « Fast forward » qui signifie avance rapide dans cette fusion.
Comme le *commit* pointé par la branche que vous avez fusionné était directement descendant du *commit* sur lequel vous vous trouvez, Git a avancé le pointeur en avant.
Autrement dit, lorsque l'on cherche à fusionner un *commit* qui peut être joint en suivant l'historique depuis le *commit* d'origine, Git avance simplement le pointeur car il n'y a pas de travaux divergeant à réellement fusionner — ceci s'appelle l'avance rapide.
@@ -236,7 +236,7 @@ Vous pouvez l'effacer avec l'option `-d` de la commande `git branch` :
$ git branch -d correctif
Deleted branch correctif (3a0874c).
-Maintenant, il est temps de basculer sur la branche "travaux en cours" sur le problème #53 et de continuer à travailler dessus (voir figure 3-15) :
+Maintenant, il est temps de basculer sur la branche « travaux en cours » sur le problème #53 et de continuer à travailler dessus (voir figure 3-15) :
$ git checkout prob53
Switched to branch "prob53"
@@ -344,7 +344,7 @@ Si vous souhaitez utiliser un outil graphique pour résoudre ces problèmes, vou
{remote}: modified
Hit return to start merge resolution tool (opendiff):
-Si vous souhaitez utiliser un outil de fusion autre que celui par défaut (Git a choisi `opendiff` pour moi dans ce cas car j'utilise la commande sous Mac), vous pouvez voir tous les outils supportés après l'indication "merge tool candidates".
+Si vous souhaitez utiliser un outil de fusion autre que celui par défaut (Git a choisi `opendiff` pour moi dans ce cas car j'utilise la commande sous Mac), vous pouvez voir tous les outils supportés après l'indication « merge tool candidates ».
Tapez le nom de l'outil que vous préféreriez utiliser.
Au chapitre 7, nous expliquerons comment changer cette valeur par défaut dans votre environnement.
@@ -451,7 +451,7 @@ Figure 3-19. Représentation des branches comme des silos.
Vous pouvez reproduire ce schéma sur plusieurs niveaux de stabilité.
Des projets plus gros ont aussi une branche `proposed` ou `pu` (proposed updates) qui permet d'intégrer des branches qui ne sont pas encore prêtes pour la prochaine version ou pour `master`.
-L'idée reste que les branches évoluent à différents niveaux de stabilité ; quand elles atteignent un niveau plus stable, elles peuvent être fusionnées dans la branche de stabilité supérieure.
+L'idée reste que les branches évoluent à différents niveaux de stabilité ; quand elles atteignent un niveau plus stable, elles peuvent être fusionnées dans la branche de stabilité supérieure.
Une fois encore, les branches au long cours ne sont pas nécessaires, mais s'avèrent souvent utiles, spécialement dans le cadre de projets gros ou complexes.
### Les branches thématiques ###
@@ -562,7 +562,7 @@ La prochaine fois qu'un de vos collaborateurs récupère les données depuis le
From git@github.com:schacon/simplegit
* [new branch] correctionserveur -> origin/correctionserveur
-Important : lorsque l'on récupère une nouvelle branche depuis un serveur distant, il n'y a pas de création automatique d'une copie locale éditable.
+Important : lorsque l'on récupère une nouvelle branche depuis un serveur distant, il n'y a pas de création automatique d'une copie locale éditable.
En d'autres termes, il n'y a pas de branche `correctionserveur`, seulement un pointeur sur la branche `origin/correctionserveur` qui n'est pas modifiable.
Pour fusionner ce travail dans votre branche actuelle de travail, vous pouvez lancer `git merge origin/correctionserveur`.
View
40 fr/04-git-server/01-chapter4.markdown
@@ -5,7 +5,7 @@ Néanmoins, pour pouvoir collaborer avec d'autres personnes au moyen de Git, vou
Bien que vous puissiez techniquement tirer des modifications et pousser des modification avec des dépôts individuels, cette pratique est découragée parce qu'elle introduit très facilement une confusion avec votre travail actuel.
De plus, vous souhaitez que vos collaborateurs puissent accéder à votre dépôt de sources, y compris si vous n'êtes pas connecté — disposer d'un dépôt accessible en permanence peut s'avérer utile.
De ce fait, la méthode canonique pour collaborer consiste à instancier un dépôt intermédiaire auquel tous ont accès, que ce soit pour pousser ou tirer.
-Nous nommerons ce dépôt le "serveur Git" mais vous vous apercevrez qu'héberger un serveur de dépôt Git ne consomme que peu de ressources et qu'en conséquence, on n'utilise que rarement une machine dédiée à cette tâche.
+Nous nommerons ce dépôt le « serveur Git » mais vous vous apercevrez qu'héberger un serveur de dépôt Git ne consomme que peu de ressources et qu'en conséquence, on n'utilise que rarement une machine dédiée à cette tâche.
Un serveur Git est simple à lancer.
Premièrement, vous devez choisir quels protocoles seront supportés.
@@ -15,8 +15,8 @@ Enfin, nous traiterons de quelques types d'hébergement, si vous souhaitez hébe
Si vous ne voyez pas d'intérêt à gérer votre propre serveur, vous pouvez sauter directement à la dernière partie de ce chapitre pour détailler les options pour mettre en place un compte hébergé, avant de continuer dans le chapitre suivant où les problématiques de développement distribué sont abordées.
-Un dépôt distant est généralement un _dépôt nu_ ( *bare repository* ), un dépôt Git qui n'a pas de copie de travail.
-Comme ce dépôt n'est utilisé que comme centralisateur de collaboration, il n'y a aucune raison d'extraire un instantané sur le disque ; seules les données Git sont nécessaires.
+Un dépôt distant est généralement un _dépôt nu_ (*bare repository*), un dépôt Git qui n'a pas de copie de travail.
+Comme ce dépôt n'est utilisé que comme centralisateur de collaboration, il n'y a aucune raison d'extraire un instantané sur le disque ; seules les données Git sont nécessaires.
Pour simplifier, un dépôt nu est le contenu du répertoire `.git` sans fioriture.
## Protocoles ##
@@ -697,7 +697,7 @@ Dans les exemples qui suivent, un compte `git` sur un serveur `gitserver` sera u
Pour commencer, créez un utilisateur nommé `git` et loggez vous avec cet utilisateur.
Copiez votre clé publique ssh depuis votre station de travail en la renommant `VotreNom.pub`.
-Ensuite, lancez les commandes ci-dessous :
+Ensuite, lancez les commandes ci-dessous :
git clone git://github.com/sitaramc/gitolite
gitolite/install -ln
@@ -707,7 +707,7 @@ Ensuite, lancez les commandes ci-dessous :
Enfin, de retour sur la station de travail, lancez `git clone git@gitserver:gitolite-admin`.
-C'est fini !
+C'est fini !
Gitolite est à présent installé sur le serveur ainsi qu'un nouveau dépôt appelé `gitolite-admin` qui a été cloné sur la station de travail.
L'administration de gitolite passe par des modifications dans ce dépôt suivi d'une poussée sur le serveur.
@@ -715,7 +715,7 @@ L'administration de gitolite passe par des modifications dans ce dépôt suivi d
### Personnalisation de l'installation ###
L'installation rapide par défaut suffit à la majorité des besoins, mais il existe des moyens de la paramétrer plus finement.
-Ces modifications sont réalisées en éditant le fichier "rc" utilisé par le serveur, mais si cela ne s'avère pas suffisant, il existe plus d'information dans la documentation sur la personnalisation de Gitolite.
+Ces modifications sont réalisées en éditant le fichier « rc » utilisé par le serveur, mais si cela ne s'avère pas suffisant, il existe plus d'information dans la documentation sur la personnalisation de Gitolite.
### Fichier de configuration et règles de contrôle d'accès ###
@@ -735,10 +735,10 @@ Une fois l'installation terminée, vous pouvez basculer vers le clone `gitolite-
repo testing
RW+ = @all
-Notez que "sitaram" (le nom de la clef publique pour la commande `gl-setup` ci-dessus) détient les permissions en lecture-écriture sur le dépôt `gitolite-admin` ainsi qu'une clé publique du même nom.
+Notez que « sitaram » (le nom de la clef publique pour la commande `gl-setup` ci-dessus) détient les permissions en lecture-écriture sur le dépôt `gitolite-admin` ainsi qu'une clé publique du même nom.
L'ajout d'utilisateurs est simple.
-Pour ajouter une utilisation appelé "alice", demandez-lui de vous fournir une clef publique ssh, renommez-la `alice.pub`, et placez-la dans le répertoire `keydir` du clone du dépôt `gitolite-admin` sur la station de travail.
+Pour ajouter une utilisation appelé « alice », demandez-lui de vous fournir une clef publique ssh, renommez-la `alice.pub`, et placez-la dans le répertoire `keydir` du clone du dépôt `gitolite-admin` sur la station de travail.
Validez le fichier dans le dépôt et poussez les modifications sur le serveur.
L'utilisatrice alice vient d'être ajoutée.
@@ -757,9 +757,9 @@ Cette distinction ne sert que lors de *l'utilisation* de la « macro ».
@engineers = sitaram dilbert wally alice
@staff = @admins @engineers @interns
-Vous pouvez contrôler les permissions au niveau "ref".
-Dans l'exemple suivant, les stagiaires (intern) ne peuvent pousser que sur la branche "int".
-Les ingénieurs peuvent pousser toutes les branches dont le nom commence par "eng" et les étiquettes qui commencent par "rc" suivi d'un chiffre.
+Vous pouvez contrôler les permissions au niveau « re ».
+Dans l'exemple suivant, les stagiaires (intern) ne peuvent pousser que sur la branche « int ».
+Les ingénieurs peuvent pousser toutes les branches dont le nom commence par « eng » et les étiquettes qui commencent par « rc » suivi d'un chiffre.
Les administrateurs ont tous les droits (y compris le rembobinage) sur toutes les réfs.
repo @oss_repos
@@ -769,7 +769,7 @@ Les administrateurs ont tous les droits (y compris le rembobinage) sur toutes le
RW+ = @admins
L'expression après les `RW` ou les `RW+` est une expression rationnelle (ou regex) qui filtre le nom de la référence (ref).
-Elle s'appelle donc une « refex » !
+Elle s'appelle donc une « refex » !
Bien entendu, une « refex » peut être bien plus puissante que celles montrées ci-dessus et il est inutile de trop chercher si vous n'êtes pas à l'aise avec les regex perl.
De plus, logiquement, Gitolite préfixe les refex qui ne commencent pas par `refs/` avec la chaîne `refs/heads/`.
@@ -794,11 +794,11 @@ La règles d'accès sont vérifiées par ordre d'apparition dans le fichier de c
Si une correspondance est trouvée, l'accès en poussée est accepté.
Si aucune correspondance n'est trouvée, l'accès est refusé.
-### Contrôle d'accès avancé avec les règles "deny" ###
+### Contrôle d'accès avancé avec les règles « deny » ###
Jusqu'ici, les seuls types de permissions rencontrés ont été `R`, `RW` ou `RW+`.
-Néanmoins, gitolite connaît une autre permission : `-` qui signifie "deny", accès refusé.
-Cela vous donne bien plus de possibilités, au prix d'une complexité accrue car à présent l'absence de correspondance n'est plus la *seule* manière de refuser l'accès, mais il devient nécessaire de faire attention à l'ordre des règles !
+Néanmoins, gitolite connaît une autre permission : `-` qui signifie « deny », accès refusé.
+Cela vous donne bien plus de possibilités, au prix d'une complexité accrue car à présent l'absence de correspondance n'est plus la *seule* manière de refuser l'accès, mais il devient nécessaire de faire attention à l'ordre des règles !
Supposons que dans la situation ci-dessus, nous souhaitons que les ingénieurs soient capables de rembobiner n'importe quelle branche *excepté* master et integ.
Voici comment faire :
@@ -831,7 +831,7 @@ Référez-vous au guide de migration pour plus de détails.
### Branches personnelles ###
-Gitolite a aussi une fonction appelée "branches personnelles" (ou plutôt "espace de branches personnelles") qui peuvent s'avérer très utiles en environnement professionnel.
+Gitolite a aussi une fonction appelée « branches personnelles » (ou plutôt « espace de branches personnelles ») qui peuvent s'avérer très utiles en environnement professionnel.
Dans le monde de git, une grande quantité d'échange de code se passe par requêtes de tirage.
En environnement professionnel, cependant, les accès non-authentifiés sont inimaginables et une authentification poste à poste est impossible.
@@ -839,10 +839,10 @@ Il est donc nécessaire de pousser sur le serveur central et demander à quelqu'
Cela provoquerait normalement le même bazar de branches que dans les VCS centralisés, avec en plus la surcharge pour l'administrateur de la gestion des permissions.
-Gitolite permet de définir un préfixe d'espace de nom "personnel" ou "brouillon" pour chaque développeur (par exemple, `refs/personnel/<nom du dev>/*`).
+Gitolite permet de définir un préfixe d'espace de nom « personnel » ou « brouillon » pour chaque développeur (par exemple, `refs/personnel/<nom du dev>/*`).
Référez-vous à la documentation pour plus de détails.
-### Dépôts "joker" ###
+### Dépôts « joker » ###
Gitolite permet de spécifier des dépôts avec jokers (en fait des regex perl), comme par exemple, au hasard, `devoirs/s[0-9][0-9]/a[0-9][0-9]`.
Un nouveau mode de permission devient accessible (« C »).
@@ -854,7 +854,7 @@ Référez-vous à la documentation pour plus de détail.
Nous terminerons cette section avec quelques échantillons d'autres fonctions qui sont toutes décrites, ainsi que d'autres dans la documentation.
**Journalisation** : Gitolite enregistre tous les accès réussis.
-Si vous étiez réticent à donner aux utilisateurs des droits de rembobiner (`RW+`) et qu'un plaisantin a complètement cassé "master", le journal des activités est là pour vous aider à trouver facilement et rapidement le SHA qui a tout déclenché.
+Si vous étiez réticent à donner aux utilisateurs des droits de rembobiner (`RW+`) et qu'un plaisantin a complètement cassé « master », le journal des activités est là pour vous aider à trouver facilement et rapidement le SHA qui a tout déclenché.
**Rapport sur les droits d'accès** : une autre fonctionnalité très utile concerne la prise en charge de la connexion ssh au serveur.
Gitolite vous affiche quels dépôts vous pouvez accéder et avec quels droits.
@@ -997,7 +997,7 @@ Figure 4-3. La page d'enregistrement de GitHub
Si vous l'avez, c'est le bon moment pour ajouter votre clef publique SSH.
Nous avons détaillé comment en générer précédemment au chapitre « Petites installations ».
Copiez le contenu de la clef publique et collez-le dans la boîte à texte « SSH Public Keys » (clés SSH publiques).
-En cliquant sur le lien « Need help with public keys? » (besoin d'aide avec les clés publiques ?), vous aurez accès aux instructions (en anglais) pour créer des clés sur la majorité des systèmes d'exploitation.
+En cliquant sur le lien « Need help with public keys? » (besoin d'aide avec les clés publiques ?), vous aurez accès aux instructions (en anglais) pour créer des clés sur la majorité des systèmes d'exploitation.
Cliquez sur le bouton « Create an account » (créer un compte) pour avoir accès à votre tableau de bord de nouvel utilisateur (voir figure 4-4).
Insert 18333fig0404.png
View
2  fr/05-distributed-git/01-chapter5.markdown
@@ -514,7 +514,7 @@ La séquence ressemble globalement à ceci :
Vous pouvez utiliser `rebase -i` pour réduire votre travail à une seule validation ou pour réarranger les modifications dans des *commits* qui rendront les patchs plus faciles à relire pour le mainteneur — référez-vous au chapitre 6 pour plus d'information sur comment rebaser de manière interactive.
-Lorsque votre branche de travail est prête et que vous êtes prêt à la fournir au mainteneur, rendez-vous sur la page du projet et cliquez sur le bouton "Fork" pour créer votre propre projet dupliqué sur lequel vous aurez les droits en écriture.
+Lorsque votre branche de travail est prête et que vous êtes prêt à la fournir au mainteneur, rendez-vous sur la page du projet et cliquez sur le bouton « Fork » pour créer votre propre projet dupliqué sur lequel vous aurez les droits en écriture.
Vous devez alors ajouter l'URL de ce nouveau dépôt en tant que second dépôt distant, dans notre cas nommé `macopie` :
$ git remote add macopie (url)
View
44 fr/06-git-tools/01-chapter6.markdown
@@ -63,7 +63,7 @@ Un des plus gros projets utilisant Git, le kernel Linux, nécessite de plus en p
### QUELQUES MOTS SUR SHA-1 ###
Beaucoup de gens se soucient qu'à un moment donné ils auront, par des circonstances hasardeuses, deux objets dans leur référentiel de hachage de même empreinte SHA-1.
-Qu'en est-il réellement ?
+Qu'en est-il réellement ?
S'il vous arrivait de valider un objet qui se hache de la même empreinte SHA-1 qu'un objet existant dans votre référentiel, Git verrait l'objet existant déjà dans votre base de données et présumerait qu'il était déjà enregistré.
Si vous essaiyez de récupérer l'objet de nouveau à un moment donné, vous auriez toujours les données du premier objet.
@@ -88,7 +88,7 @@ Par exemple, si vous souhaitez afficher le dernier *commit* d'une branche, les c
$ git show sujet1
Pour connaître l'empreinte SHA sur laquelle pointe une branche ou pour savoir parmi tous les exemples précédents ce que cela donne en terme de SHA, vous pouvez utiliser la commande de plomberie nommée `rev-parse`.
-Référez-vous au chapitre 9 pour plus d'informations sur les commandes de plomberie ; `rev-parse` sert aux opérations de bas niveau et n'est pas conçue pour être utilisée au jour le jour.
+Référez-vous au chapitre 9 pour plus d'informations sur les commandes de plomberie ; `rev-parse` sert aux opérations de bas niveau et n'est pas conçue pour être utilisée au jour le jour.
Quoi qu'il en soit, elle se révèle utile pour comprendre ce qui se passe.
Je vous invite à tester `rev-parse` sur votre propre branche.
@@ -97,7 +97,7 @@ Je vous invite à tester `rev-parse` sur votre propre branche.
### Raccourcis RefLog ###
-Git maintient en arrière-plan un historique des références où sont passés HEAD et vos branches sur les derniers mois - ceci s'appelle le reflog.
+Git maintient en arrière-plan un historique des références où sont passés HEAD et vos branches sur les derniers mois ceci s'appelle le reflog.
Vous pouvez le consulter avec la commande `git reflog` :
@@ -162,7 +162,7 @@ Supposons que vous consultiez votre historique :
* 1c36188 ignore *.gem
* 9b29157 ajout open3_detach à la liste des fichiers gemspcec
-Alors, vous pouvez consulter le *commit* précédent en spécifiant `HEAD^`, ce qui signifie "le parent de HEAD" :
+Alors, vous pouvez consulter le *commit* précédent en spécifiant `HEAD^`, ce qui signifie « le parent de HEAD » :
$ git show HEAD^
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
@@ -172,7 +172,7 @@ Alors, vous pouvez consulter le *commit* précédent en spécifiant `HEAD^`, ce
Merge commit 'phedders/rdocs'
-Vous pouvez également spécifier un nombre après `^` — par exemple, `d921970^2` signifie "le second parent de d921970.".
+Vous pouvez également spécifier un nombre après `^` — par exemple, `d921970^2` signifie « le second parent de d921970. ».
Cette syntaxe ne sert que pour les *commits* de fusion, qui ont plus d'un parent.
Le premier parent est la branche où vous avez fusionné, et le second est le *commit* de la branche que vous avez fusionnée :
@@ -193,7 +193,7 @@ Le premier parent est la branche où vous avez fusionné, et le second est le *c
Une autre solution courante pour spécifier une référence est le `~`.
Il fait également référence au premier parent, donc `HEAD~` et `HEAD^` sont équivalents.
La différence se fait sentir si vous spécifiez un nombre.
-`HEAD~2` signifie "le premier parent du premier parent," ou bien "le grand-parent" ; on remonte les premiers parents autant de fois que demandé.
+`HEAD~2` signifie « le premier parent du premier parent », ou bien « le grand-parent » ; on remonte les premiers parents autant de fois que demandé.
Par exemple, dans l'historique précédemment présenté, `HEAD~3` serait :
$ git show HEAD~3
@@ -217,7 +217,7 @@ Vous pouvez également combiner ces syntaxes — vous pouvez obtenir le second p
### Plages de *commits* ###
A présent que vous pouvez spécifier des *commits* individuels, voyons comment spécifier des plages de *commits*.
-Ceci est particulièrement pratique pour la gestion des branches — si vous avez beaucoup de branches, vous pouvez utiliser les plages pour répondre à des questions telles que "Quel travail sur cette branche n'ai-je pas encore fusionné sur ma branche principale ?".
+Ceci est particulièrement pratique pour la gestion des branches — si vous avez beaucoup de branches, vous pouvez utiliser les plages pour répondre à des questions telles que « Quel travail sur cette branche n'ai-je pas encore fusionné sur ma branche principale ? ».
#### Double point ####
@@ -253,7 +253,7 @@ Par exemple, vous pouvez obtenir les mêmes résultats que précédemment en tap
#### Emplacements multiples ####
-La syntaxe double-point est pratique comme raccourci ; mais peut-être souhaitez-vous utiliser plus d'une branche pour spécifier une révision, comme pour voir quels *commits* sont dans plusieurs branches mais sont absents de la branche courante.
+La syntaxe double-point est pratique comme raccourci ; mais peut-être souhaitez-vous utiliser plus d'une branche pour spécifier une révision, comme pour voir quels *commits* sont dans plusieurs branches mais sont absents de la branche courante.
Git vous permet cela avec `^` ou `--not` en préfixe de toute référence de laquelle vous ne souhaitez pas voir les *commits*.
Les 3 commandes ci-après sont équivalentes :
@@ -272,7 +272,7 @@ Ceci vous fournit un système de requêtage des révisions très puissant, pour
#### Triple point ####
La dernière syntaxe majeure de sélection de plage de *commits* est la syntaxe triple-point qui spécifie tous les *commits* accessibles par l'une des deux références, exclusivement.
-Toujours avec l'exemple d'historique à la figure 6-1, si vous voulez voir ce qui ce trouve sur `master` ou `experience` mais pas sur les 2, exécutez :
+Toujours avec l'exemple d'historique à la figure 6-1, si vous voulez voir ce qui ce trouve sur `master` ou `experience` mais pas sur les 2, exécutez :
$ git log master...experience
F
@@ -630,7 +630,7 @@ Vous indexez les modifications que vous voulez en exécutant `git add` ou `git r
Vous devez être prudent avec cette technique car votre modification modifie également le SHA-1 du *commit*.
Cela ressemble à un tout petit `rebase`.
-Ne modifiez pas votre dernière validation si vous l'avez déjà publiée !
+Ne modifiez pas votre dernière validation si vous l'avez déjà publiée !
### Modifier plusieurs messages de validation ###
@@ -680,7 +680,7 @@ Il commencera au *commit* que vous spécifiez sur la ligne de commande (`HEAD~3`
Il ordonne donc le plus vieux au début, plutôt que le plus récent, car c'est celui qu'il refera en premier.
Vous devez éditer le script afin qu'il s'arrête au *commit* que vous voulez modifier.
-Pour cela, remplacer le mot "pick" par le mot "edit" pour chaque *commit* après lequel vous voulez que le script s'arrête.
+Pour cela, remplacer le mot « pick » par le mot « edit » pour chaque *commit* après lequel vous voulez que le script s'arrête.
Par exemple, pour modifier uniquement le message du troisième *commit*, vous modifiez le fichier pour ressembler à :
edit f7f3f6d changed my name a bit
@@ -710,13 +710,13 @@ Puis exécutez :
$ git rebase --continue
Cette commande appliquera les deux autres *commits* automatiquement.
-Si vous remplacez "pick" en "edit" sur plusieurs lignes, vous pouvez répéter ces étapes pour chaque *commit* que vous avez marqué pour modification.
+Si vous remplacez « pick » en « edit » sur plusieurs lignes, vous pouvez répéter ces étapes pour chaque *commit* que vous avez marqué pour modification.
Chaque fois, Git s'arrêtera, vous laissant modifier le *commit* et continuera lorsque vous aurez fini.
### Réordonner les commits ###
Vous pouvez également utiliser les rebasages interactifs afin de réordonner ou supprimer entièrement des *commits*.
-Si vous voulez supprimer le *commit* "added cat-file" et modifier l'ordre dans lequel les deux autres *commits* se trouvent dans l'historique, vous pouvez modifier le script de rebasage :
+Si vous voulez supprimer le *commit* « added cat-file » et modifier l'ordre dans lequel les deux autres *commits* se trouvent dans l'historique, vous pouvez modifier le script de rebasage :
pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
@@ -728,7 +728,7 @@ afin qu'il ressemble à ceci :
pick f7f3f6d changed my name a bit
Lorsque vous sauvegardez et quittez l'éditeur, Git remet votre branche au niveau du parent de ces *commits*, applique `310154e` puis `f7f3f6d` et s'arrête.
-Vous venez de modifier l'ordre de ces *commits* et de supprimer entièrement le *commit* "added cat-file".
+Vous venez de modifier l'ordre de ces *commits* et de supprimer entièrement le *commit* « added cat-file ».
### Rassembler des *commits* ###
@@ -745,7 +745,7 @@ Le script affiche des instructions utiles dans le message de rebasage :
# However, if you remove everything, the rebase will be aborted.
#
-Si, à la place de "pick" ou "edit", vous spécifiez "squash", Git applique cette modification et la modification juste précédente et fusionne les messages de validation.
+Si, à la place de « pick » ou « edit », vous spécifiez "squash", Git applique cette modification et la modification juste précédente et fusionne les messages de validation.
Donc, si vous voulez faire un seul *commit* de ces trois validations, vous faites en sorte que le script ressemble à ceci :
pick f7f3f6d changed my name a bit
@@ -772,8 +772,8 @@ Lorsque vous sauvegardez cela, vous obtenez un seul *commit* amenant les modific
Pour diviser un *commit*, il doit être défait, puis partiellement indexé et validé autant de fois que vous voulez pour en finir avec lui.
Par exemple, supposons que vous voulez diviser le *commit* du milieu dans l'exemple des trois *commits* précédents.
-Plutôt que "updated README formatting and added blame", vous voulez le diviser en deux *commits* : "updated README formatting" pour le premier, et "added blame" pour le deuxième.
-Vous pouvez le faire avec le script `rebase -i` en remplaçant l'instruction sur le *commit* que vous voulez divisez en "edit" :
+Plutôt que « updated README formatting and added blame », vous voulez le diviser en deux *commits* : « updated README formatting » pour le premier, et « added blame » pour le deuxième.
+Vous pouvez le faire avec le script `rebase -i` en remplaçant l'instruction sur le *commit* que vous voulez divisez en « edit » :
pick f7f3f6d changed my name a bit
edit 310154e updated README formatting and added blame
@@ -781,7 +781,7 @@ Vous pouvez le faire avec le script `rebase -i` en remplaçant l'instruction sur
Puis, lorsque le script vous laissera accès à la ligne de commande, vous annulerez (reset) ce *commit*, vous reprendrez les modifications que vous voulez pour créer plusieurs *commits*.
En reprenant l'exemple, lorsque vous sauvegardez et quittez l'éditeur, Git revient au parent de votre premier *commit* de votre liste, applique le premier *commit* (`f7f3f6d`), applique le deuxième (`310154e`), et vous laisse accès à la console.
-Là, vous pouvez faire une réinitialisation mélangée (mixed reset) de ce *commit* avec `git reset HEAD^`, qui défait ce *commit* et laisse les fichiers modifiés non indexés.
+Là, vous pouvez faire une réinitialisation mélangée (*mixed reset*) de ce *commit* avec `git reset HEAD^`, qui défait ce *commit* et laisse les fichiers modifiés non indexés.
Maintenant, vous pouvez indexer et valider les fichiers sur plusieurs validations, et exécuter `git rebase --continue` quand vous avez fini :
$ git reset HEAD^
@@ -814,14 +814,14 @@ Cela arrive assez fréquemment.
Quelqu'un a accidentellement validé un énorme fichier binaire avec une commande `git add .` irréfléchie, and vous voulez le supprimer partout.
Vous avez peut-être validé un fichier contenant un mot de passe et vous voulez rendre votre projet open source.
`filter-branch` est l'outil que vous voulez probablement utiliser pour nettoyer votre historique entier.
-Pour supprimer un fichier nommé "passwords.txt" de tout votre historique, vous pouvez utiliser l'option `--tree-filter` de `filter-branch` :
+Pour supprimer un fichier nommé « passwords.txt » de tout votre historique, vous pouvez utiliser l'option `--tree-filter` de `filter-branch` :
$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
Ref 'refs/heads/master' was rewritten
L'option `--tree-filter` exécute la commande spécifiée pour chaque *commit* et les revalide ensuite
-Dans le cas présent, vous supprimez le fichier nommé "passwords.txt" de chaque contenu, qu'il existait ou non.
+Dans le cas présent, vous supprimez le fichier nommé « passwords.txt » de chaque contenu, qu'il existait ou non.
Si vous voulez supprimer tous les fichiers temporaires des éditeurs validés accidentellement, vous pouvez exécuter une commande telle que `git filter-branch --tree-filter 'rm -f *~' HEAD`.
Vous pourrez alors regarder Git réécrire l'arbre des *commits* et revalider à chaque fois, pour finir en modifiant la référence de la branche.
@@ -913,7 +913,7 @@ En annotant `GITPackUpload.m` avec l'option `-C`, je peux voir quelles sections
56ef2caf GITServerHandler.m (Scott 2009-01-05 152) [refDict setOb
56ef2caf GITServerHandler.m (Scott 2009-01-05 153)
-C'est vraiment utile, non ?
+C'est vraiment utile, non ?
Normalement, vous obtenez comme *commit* original celui dont votre code a été copié, puisque ce fut la première fois que vous avez touché à ces lignes dans ce fichier.
Git vous montre le *commit* d'origine, celui où vous avez écrit ces lignes, même si c'était dans un autre fichier.
@@ -1135,7 +1135,7 @@ Si un autre développeur modifie le code de `rack` et valide, que vous tiriez ce
# modified: rack
#
-En réalité, vous n'avez fusionné que la modification de la référence de votre sous-module, mais Git n'a pas mis à jour le code dans le répertoire du sous-module, de ce fait, cela ressemble à un état "en cours" dans votre répertoire de travail :
+En réalité, vous n'avez fusionné que la modification de la référence de votre sous-module, mais Git n'a pas mis à jour le code dans le répertoire du sous-module, de ce fait, cela ressemble à un état « en cours » dans votre répertoire de travail :
$ git diff
diff --git a/rack b/rack
View
16 fr/08-git-and-other-scms/01-chapter8.markdown
@@ -301,7 +301,7 @@ Pour créer une nouvelle branche dans Subversion, vous pouvez utiliser la comman
r89 = 9b6fe0b90c5c9adf9165f700897518dbc54a7cbf (opera)
Cela est équivalent à la commande Subversion `svn copy trunk branches/opera` et réalise l'opération sur le serveur Subversion.
-Remarquez que cette commande ne vous bascule pas sur cette branche ; si vous validez, le *commit* s'appliquera à `trunk` et non à la branche `opera`.
+Remarquez que cette commande ne vous bascule pas sur cette branche ; si vous validez, le *commit* s'appliquera à `trunk` et non à la branche `opera`.
### Basculer de branche active ###
@@ -313,7 +313,7 @@ Si vous voulez une branche `opera` sur laquelle travailler séparément, vous po
$ git branch opera remotes/opera
À présent, si vous voulez fusionner votre branche `opera` dans `trunk` (votre branche `master`), vous pouvez le faire en réalisant un `git merge` normal.
-Mais vous devez préciser un message de validation descriptif (via `-m`), ou la fusion indiquera simplement "Merge branch opera" au lieu d'un message plus informatif.
+Mais vous devez préciser un message de validation descriptif (via `-m`), ou la fusion indiquera simplement « Merge branch opera » au lieu d'un message plus informatif.
Souvenez-vous que bien que vous utilisez `git merge` qui facilitera l'opération de fusion par rapport à Subversion (Git détectera automatiquement l'ancêtre commun pour la fusion), ce n'est pas un *commit* de fusion normal de Git.
Vous devrez pousser ces données finalement sur le serveur Subversion qui ne sait pas tracer les *commits* possédant plusieurs parents.
@@ -349,7 +349,7 @@ Si vous êtes habitué à Subversion, vous pouvez lancer `git svn log` pour visu
updated the changelog
-Deux choses importantes à connaître sur `git svn log` : premièrement, à la différence de la commande réelle `svn log` qui interroge le serveur, cette commande fonctionne hors connexion ; deuxièmement, elle ne montre que les *commits* qui ont été effectivement remontés sur le serveur Subversion.
+Deux choses importantes à connaître sur `git svn log` : premièrement, à la différence de la commande réelle `svn log` qui interroge le serveur, cette commande fonctionne hors connexion ; deuxièmement, elle ne montre que les *commits* qui ont été effectivement remontés sur le serveur Subversion.
Les *commits* locaux qui n'ont pas encore été remontés via `dcommit` n'apparaissent pas, pas plus que ceux qui auraient été poussés sur le serveur par des tiers entre deux `git svn rebase`.
Cela donne plutôt le dernier état connu des *commits* sur le serveur Subversion.
@@ -412,7 +412,7 @@ Les outils `git svn` sont utiles si vous êtes bloqué avec un serveur Subversio
Il faut cependant les considérer comme une version tronquée de Git ou vous pourriez rencontrer des problèmes de conversion synonymes de troubles pour vous et vos collaborateurs.
Pour éviter tout problème, essayez de suivre les principes suivants :
-* Garder un historique Git linéaire qui ne contient pas de *commits* de fusion issus de `git merge`. Rebasez tout travail réalisé en dehors de la branche principale sur celle-ci ; ne la fusionnez pas.
+* Garder un historique Git linéaire qui ne contient pas de *commits* de fusion issus de `git merge`. Rebasez tout travail réalisé en dehors de la branche principale sur celle-ci ; ne la fusionnez pas.
* Ne mettez pas en place et ne travaillez pas en parallèle sur un serveur Git. Si nécessaire, montez-en un pour accélérer les clones pour de nouveaux développeurs mais n'y poussez rien qui n'ait déjà une entrée `git-svn-id`. Vous devriez même y ajouter un crochet `pre-receive` qui vérifie la présence de `git-svn-id` dans chaque message de validation et rejette les remontées dont un des *commits* n'en contiendrait pas.
Si vous suivez ces principes, le travail avec un serveur Subversion peut être supportable.
@@ -433,7 +433,7 @@ Si vous avez lu la section précédente sur l'utilisation de `git svn`, vous pou
Ensuite, arrêtez d'utiliser le serveur Subversion, poussez sur un nouveau serveur Git et commencez à l'utiliser.
Si vous voulez l'historique, vous pouvez l'obtenir aussi rapidement que vous pourrez tirer les données du serveur Subversion (ce qui peut prendre un certain temps).
-Cependant, l'import n'est pas parfait ; et comme cela prend autant de temps, autant le faire bien.
+Cependant, l'import n'est pas parfait ; et comme cela prend autant de temps, autant le faire bien.
Le premier problème est l'information d'auteur.
Dans Subversion, chaque personne qui valide dispose d'un compte sur le système qui est enregistré dans l'information de validation.
Les exemples de la section précédente montrent `schacon` à certains endroits, tels que la sortie de `blame` ou de `git svn log`.
@@ -609,7 +609,7 @@ Comme vous pouvez vous en souvenir, Git est à la base une liste chaînée d'obj
Tout ce qu'il y a à faire donc, et d'indiquer à `fast-import` ce que sont les instantanés de contenu, quelles données de *commit* pointent dessus et l'ordre dans lequel ils s'enchaînent.
La stratégie consistera à parcourir les instantanés un par un et à créer des *commits* avec le contenu de chaque répertoire, en le reliant à son prédécesseur.
-Comme déjà fait dans la section "Un exemple de règle appliquée par Git" du chapitre 7, nous l'écrirons en Ruby parce que c'est le langage avec lequel je travaille en général et qu'il est assez facile à lire.
+Comme déjà fait dans la section « Un exemple de règle appliquée par Git » du chapitre 7, nous l'écrirons en Ruby parce que c'est le langage avec lequel je travaille en général et qu'il est assez facile à lire.
Vous pouvez facilement retranscrire cet exemple dans votre langage de prédilection, la seule contrainte étant qu'il doit pouvoir afficher les informations appropriées sur stdout.
Si vous travaillez sous Windows, cela signifie que vous devrez faire particulièrement attention à ne pas introduire de retour chariot à la fin de vos lignes.
`git fast-import` n'accepte particulièrement que les sauts de ligne (line feed LF) et pas les retour chariot saut de ligne (CRLF) utilisés par Windows.
@@ -632,7 +632,7 @@ La boucle principale ressemble à ceci :
end
end
-Dans chaque répertoire, nous lançons `print_export` qui prend le manifest et la marque de l'instantané précédent et retourne le manifest et la marque de l'actuel ; de cette manière, vous pouvez les chaîner correctement.
+Dans chaque répertoire, nous lançons `print_export` qui prend le manifest et la marque de l'instantané précédent et retourne le manifest et la marque de l'actuel ; de cette manière, vous pouvez les chaîner correctement.
« Marque » est le terme de `fast-import` pour nommer un identifiant que vous donnez à un *commit*.
Au fur et à mesure de la création des *commits*, vous leur attribuez une marque individuelle qui pourra être utilisée pour y faire référence depuis d'autres *commits*.
La première chose à faire dans `print_export` est donc de générer une marque à partir du nom du répertoire :
@@ -824,7 +824,7 @@ Pour les avoir, vous devez réinitialiser votre branche sur `master` :
file.rb lib
Vous pouvez faire bien plus avec l'outil `fast-import` — gérer différents modes, les données binaires, les branches multiples et la fusion, les étiquettes, les indicateurs de progrès, et plus encore.
-Des exemples de scénarios plus complexes sont disponibles dans le répertoire `contrib/fast-import` du code source Git ; un des meilleurs est justement le script `git-p4` traité précédemment.
+Des exemples de scénarios plus complexes sont disponibles dans le répertoire `contrib/fast-import` du code source Git ; un des meilleurs est justement le script `git-p4` traité précédemment.
## Résumé ##
View
38 fr/09-git-internals/01-chapter9.markdown
@@ -7,7 +7,7 @@ J'en ai donc fait le dernier chapitre de ce livre pour que vous puissiez le lire
Je vous laisse le choix.
Maintenant que vous êtes ici, commençons.
-Tout d'abord et même si ce n'est pas clair tout de suite, Git est fondamentalement un système de fichiers adressables par contenu (content-addressable filesystem) avec l'interface utilisateur d'un VCS au-dessus.
+Tout d'abord et même si ce n'est pas clair tout de suite, Git est fondamentalement un système de fichiers adressables par contenu (*content-addressable filesystem*) avec l'interface utilisateur d'un VCS au-dessus.
Vous en apprendrez plus à ce sujet dans quelques instants.
Aux premiers jours de Git (surtout avant la version 1.5), l'interface utilisateur était beaucoup plus complexe, car elle était centrée sur le système de fichier plutôt que sur l'aspect VCS.
@@ -18,9 +18,9 @@ Ensuite, vous apprendrez les mécanismes de transport/transmission/communication
## Plomberie et porcelaine ##
-Ce livre couvre l'utilisation de Git avec une trentaine de verbes comme `checkout`, `branch`, `remote` ...
-Mais, puisque Git était initialement une boîte à outils (N.d.T : Toolkit) pour VCS, plutôt qu'un VCS complet et conviviale, il dispose de tout un ensemble d'actions pour les tâches bas niveau qui étaient conçues pour être liées à la UNIX ou appelées depuis des scripts.
-Ces commandes sont dites commandes de "plomberie" (N.d.T "plumbing") et les autres, plus conviviales sont appelées "porcelaines" (N.d.T : "porcelain").
+Ce livre couvre l'utilisation de Git avec une trentaine de verbes comme `checkout`, `branch`, `remote`...
+Mais, puisque Git était initialement une boîte à outils (*toolkit*) pour VCS, plutôt qu'un VCS complet et conviviale, il dispose de tout un ensemble d'actions pour les tâches bas niveau qui étaient conçues pour être liées à la UNIX ou appelées depuis des scripts.
+Ces commandes sont dites commandes de « plomberie » (*plumbing*) et les autres, plus conviviales sont appelées « porcelaines » (*porcelain*).
Les huit premiers chapitres du livre concernent presque exclusivement les commandes porcelaine.
Par contre, dans ce chapitre, vous serez principalement confronté aux commandes de plomberie bas niveaux, car elles vous donnent accès au fonctionnement interne de Git et aident à montrer comment et pourquoi Git fonctionne comme il le fait.
@@ -146,7 +146,7 @@ Git peut vous donner le type d'objet de n'importe quel objet Git, étant donné
Le prochain type que vous allez étudier est l'objet arbre (N.d.t 'tree') qui résout le problème de stockage d'un groupe de fichiers.
Git stocke du contenu de la même manière, mais plus simplement, qu'un système de fichier UNIX.
Tout le contenu est stocké comme des objets de type arbre ou blob : un arbre correspondant à un répertoire UNIX et un blob correspond à peu près à un i-noeud ou au contenu d'un fichier.
-Un unique arbre contient une ou plusieurs entrées de type arbre, chacune incluant un pointeur SHA-1 vers un blob, un sous-arbre (N.d.T sub-tree), ainsi que les droits d'accès (N.d.t 'mode'), le type et le nom de fichier.
+Un unique arbre contient une ou plusieurs entrées de type arbre, chacune incluant un pointeur SHA-1 vers un blob, un sous-arbre (*sub-tree*), ainsi que les droits d'accès (*mode*), le type et le nom de fichier.
L'arbre le plus récent du projet simplegit pourrait ressembler, par exemple à ceci :
$ git cat-file -p master^{tree}
@@ -317,7 +317,7 @@ Figure 9-3. Tous les objets de votre répertoire Git.
On a parlé plus tôt de l'en-tête présent avec le contenu.
Prenons un moment pour étudier la façon dont Git stocke les objets.
-On verra comment stocker interactivement un objet Blob (ici, la chaîne "what is up, doc?") avec le langage Ruby.
+On verra comment stocker interactivement un objet Blob (ici, la chaîne « what is up, doc? ») avec le langage Ruby.
Vous pouvez démarrer Ruby en mode interactif avec la commande `irb` :
$ irb
@@ -500,7 +500,7 @@ Le noyau linux contient aussi une étiquette ne pointant pas vers un *commit* :
### Références distantes ###
-Le troisième type de références que l'on étudiera sont les références distantes (N.d.T remotes).
+Le troisième type de références que l'on étudiera sont les références distantes (*remotes*).
Si l'on ajoute une référence distante et que l'on pousse des objets vers elle, Git stocke la valeur que vous avez poussée en dernière vers cette référence pour chaque branche dans le répertoire `refs/remotes`.
Vous pouvez par exemple, ajouter une référence distante nommée `origin` et y pousser votre branche `master` :
@@ -590,7 +590,7 @@ Il y a donc deux objets de 4Ko quasiment identiques sur le disque.
Ne serait-ce pas bien si Git pouvait enregistrer qu'un objet en entier, le deuxième n'étant qu'un delta (une différence) avec le premier ?
Il se trouve que c'est possible.
-Le format initial dans lequel Git enregistre les objets sur le disque est appelé le format brut ("loose object").
+Le format initial dans lequel Git enregistre les objets sur le disque est appelé le format brut (*loose object*).
De temps en temps, Git compacte plusieurs de ces objets en un seul fichier binaire appelé packfile (fichier groupé), afin d'économiser de l'espace et d'être plus efficace.
Git effectue cette opération quand il y a trop d'objets au format brut, ou si l'on exécute manuellement la commande `git gc`, ou encore quand on pousse vers un serveur distant.
Pour voir cela en action, vous pouvez demander manuellement à Git de compacter les objets en exécutant la commande `git gc` :
@@ -612,7 +612,7 @@ Si l'on jette un œil dans le répertoire des objets, on constatera que la plupa
.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack
Les objets restant sont des blobs qui ne sont pointés par aucun *commit*.
-Dans notre cas, il s'agit des blobs "what is up, doc?" et "test content" créés plus tôt comme exemple.
+Dans notre cas, il s'agit des blobs « what is up, doc? » et « test content » créés plus tôt comme exemple.
Puisqu'ils n'ont été ajoutés à aucun *commit*, ils sont considérés en suspend et ne sont pas compactés dans le nouveau fichier groupé.
Les autres fichiers sont le nouveau fichier groupé et un index.
@@ -756,7 +756,7 @@ La spécification de référence ressemble à `<src>:<dst>`, mais en laissant vi
## Protocoles de transfert ##
-Git peut transférer des données entre deux dépôts, de deux façons principales : via HTTP et via un protocole dit "intelligent" utilisé par les transports `file://`, `ssh://` et `git://`.
+Git peut transférer des données entre deux dépôts, de deux façons principales : via HTTP et via un protocole dit « intelligent » utilisé par les transports `file://`, `ssh://` et `git://`.
Cette section fait un tour d'horizon du fonctionnement de ces deux protocoles.
### Protocole stupide ###
@@ -931,9 +931,9 @@ Dans tous les cas, après que `fetch-pack` se connecte, `upload-pack` lui répon
C'est très proche de ce que répondait `receive-pack` mais les compétences sont différentes.
En plus, il vous répond la référence HEAD, afin que le client sache quoi récupérer dans le cas d'un clone.
-À ce moment, l'exécutable `fetch-pack` regarde quels objets il a et répond avec les objets dont il a besoin en envoyant "want" (vouloir) suivi du SHA qu'il veut.
-Il envoie tous les objets qu'il a déjà avec "have" suivi du SHA.
-À la fin de la liste, il écrit "done" pour initialiser l'exécutable `upload-pack` à commencer à envoyer le fichier groupé des données demandées :
+À ce moment, l'exécutable `fetch-pack` regarde quels objets il a et répond avec les objets dont il a besoin en envoyant « want » (vouloir) suivi du SHA qu'il veut.
+Il envoie tous les objets qu'il a déjà avec « have » suivi du SHA.
+À la fin de la liste, il écrit « done » pour initialiser l'exécutable `upload-pack` à commencer à envoyer le fichier groupé des données demandées :
0054want ca82a6dff817ec66f44342007202690a93763949 ofs-delta
0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
@@ -952,17 +952,17 @@ Cette section couvrira certains de ces scénarios.
### Maintenance ###
-De temps en temps, Git exécute automatiquement une commande appelée "auto gc".
+De temps en temps, Git exécute automatiquement une commande appelée « auto gc ».
La plupart du temps, cette commande ne fait rien.
Cependant, s'il y a trop d'objets bruts (des objets qui ne sont pas dans des fichiers groupés), ou trop de fichiers groupés, Git lance une commande `git gc` à part entière.
-`gc` est l'abréviation pour "garbage collect" (ramasse-miettes) et la commande fait plusieurs choses : elle rassemble plusieurs objets bruts et les place dans un fichiers groupés, elle consolide des fichiers groupés en un gros fichier groupé et elle supprime des objets qui ne sont plus accessibles depuis un *commit* et qui sont vieux de plusieurs mois.
+`gc` est l'abréviation pour « garbage collect » (ramasse-miettes) et la commande fait plusieurs choses : elle rassemble plusieurs objets bruts et les place dans un fichiers groupés, elle consolide des fichiers groupés en un gros fichier groupé et elle supprime des objets qui ne sont plus accessibles depuis un *commit* et qui sont vieux de plusieurs mois.
Vous pouvez exécuter `auto gc` manuellement :
$ git gc --auto
Encore une fois, cela ne fait généralement rien.
-Vous devez avoir environ 7.000 objets bruts ou plus de 50 fichiers groupés pour que Git appelle une vraie commande `gc`.
+Vous devez avoir environ 70 000 objets bruts ou plus de 50 fichiers groupés pour que Git appelle une vraie commande `gc`.
Vous pouvez modifier ces limites avec les propriétés de configuration `gc.auto` et `gc.autopacklimit`, respectivement.
`gc` regroupera aussi vos références dans un seul fichier.
@@ -1024,7 +1024,7 @@ Le problème est de trouver ce SHA, ce n'est pas comme si vous l'aviez mémoris
Souvent, la manière la plus rapide est d'utiliser l'outil `git reflog`
Pendant que vous travaillez, Git enregistre l'emplacement de votre HEAD chaque fois que vous le changez.
À chaque *commit* ou commutation de branche, le journal des références (reflog) est mis à jour.
-Le journal des références est aussi mis à jour par la commande `git update-ref`, qui est une autre raison de l'utiliser plutôt que de simplement écrire votre valeur SHA dans vos fichiers de références, comme mentionné dans la section "Git References" plus haut dans ce chapitre.
+Le journal des références est aussi mis à jour par la commande `git update-ref`, qui est une autre raison de l'utiliser plutôt que de simplement écrire votre valeur SHA dans vos fichiers de références, comme mentionné dans la section « Git References » plus haut dans ce chapitre.
Vous pouvez voir où vous étiez à n'importe quel moment en exécutant `git reflog` :
$ git reflog
@@ -1084,7 +1084,7 @@ Si vous l'exécutez avec l'option `--full`, il vous montre tous les objets qui n
dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
-Dans ce cas, vous pouvez voir votre *commit* manquant après "dangling commit".
+Dans ce cas, vous pouvez voir votre *commit* manquant après « dangling commit ».
Vous pouvez le restaurez de la même manière que précédemment, en créant une branche qui référence cette empreinte SHA.
### Suppression d'objets ###
@@ -1216,7 +1216,7 @@ Voyons combien d'espace vous avez récupéré :
garbage: 0
La taille du dépôt regroupé est retombée à 7Ko, ce qui est beaucoup moins que 2Mo.
-Vous pouvez voir dans la valeur "size" que votre gros objet est toujours dans vos objets bruts, il n'est donc pas parti; mais il ne sera plus transféré lors d'une poussée vers un serveur ou un clone, ce qui est l'important dans l'histoire.
+Vous pouvez voir dans la valeur « size » que votre gros objet est toujours dans vos objets bruts, il n'est donc pas parti; mais il ne sera plus transféré lors d'une poussée vers un serveur ou un clone, ce qui est l'important dans l'histoire.
Si vous voulez réellement, vous pouvez supprimer complètement l'objet en exécutant `git prune --expire`.
## Résumé ##
View
32 fr/glossaire-git.adoc
@@ -1,16 +1,16 @@
Glossaire de Git
================
-:Auteur: Emmanuel Trillaud
+:Auteur: Emmanuel Trillaud
:Email: <etrillaud (at) gmail (dot) com>
-:Date: 11/02/10 15:04
+:Date: 11/02/10 15:04
:Revision: 2
Glossaire de l'outil de gestion de version Git créé à partir des traductions de
* git-gui, http://repo.or.cz/w/git-gui.git[Sources]
* gitk, http://git.kernel.org/?p=gitk/gitk.git;a=summary[Sources]
-* du « Git Community Book » http://book.git-scm.com/[en], http://alx.github.com/gitbook/[fr] et
+* du « Git Community Book » http://book.git-scm.com/[en], http://alx.github.com/gitbook/[fr] et
* du livre « Progit » http://progit.org/book/[en]
Autre doc utile
@@ -26,9 +26,10 @@ un « ? » à côté d'un mot signifie que la traduction proposée est discutabl
- loose object ->
* Tree (Object) -> Arbre
* Commit (Objet) -> Commit
-* Tag (Object) -> Tag
- - annotated -> tag annoté
- - ligthweigt tag -> tag léger
+* commit -> valider / validation (pourait être "soumission" / soumettre)(une autre traduction propose consigner / consigne)
+* Tag (Object) -> Étiquette
+ - annotated -> étiquette annotée
+ - ligthweigt tag -> étiquette légère
* Blob (Object) -> Blob
* refs -> références
@@ -51,7 +52,7 @@ un « ? » à côté d'un mot signifie que la traduction proposée est discutabl
- fast-forward reference -> avance rapide
* repository -> dépôt
* diff -> diff
-* patch -> patch
+* patch -> patch (traduction officielle : "retouche" ou "correctif" ; en Canadien, "rustine")
.SHA-1
* hash -> empreinte
@@ -61,32 +62,33 @@ un « ? » à côté d'un mot signifie que la traduction proposée est discutabl
* SHA-1 -> empreinte SHA-1
.Actions/Commandes
-Si le mot fait référence à la commande, on ne traduit pas. Par contre,
+Si le mot fait référence à la commande, on ne traduit pas. Par contre,
si on fait référence à l'action, on peut traduire.
-* checkout ->
+* checkout -> extraction
+* checkin -> archivage
* branch(es) -> branches
- remote branches -> branche distante
* remote -> distant
a remote -> un dépôt distant
-* pull -> tirer ("retirer" est peut-être mieux)
+* pull -> tirer ("retirer" est peut-être mieux)(ou "récupérer")
* fetch -> récupérer
-* push -> pousser (pourquoi pas "publier")
+* push -> pousser (pourquoi pas "publier")(+1)
* stash -> remiser
* add -> ajouter
* log -> journal
* gc ->
- - garbage collector -> ramasse-miette
+ - garbage collector -> ramasse-miettes
* reset -> réinitialiser
- hard reset ->
- soft reset ->
- mixed reset ->
* bisect -> bissecter
* archive -> archiver
-* cherry-pick -> sélectionner (a été préféré à "cueillir")
+* cherry-pick -> sélectionner (a été préféré à "cueillir")(vu au chapitre 5: "picorer")
* cherry-picking -> sélection (préféré à "cueillette")
* clean -> nettoyer
-* clone -> clôner
+* clone -> cloner
* To merge (a branch) -> fusionner
* To merge (a change) -> incorporer
- a merge -> une fusion
@@ -102,5 +104,5 @@ si on fait référence à l'action, on peut traduire.
* hook -> crochet
* namespace -> espace de noms
* Content-addressable filesystem -> système de fichier adressable par le contenu
-* DAG(Direct Acyclic Graph) -> Graphe orienté acyclique
+* DAG (Direct Acyclic Graph) -> Graphe orienté acyclique
* pattern -> motif
Please sign in to comment.
Something went wrong with that request. Please try again.