From 6a92e38c69241dd65064d610ced6f549ff2d9ecd Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Mon, 1 Dec 2008 20:23:24 +0100 Subject: [PATCH 01/32] Trad. intro --- index.html | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index 8fd1eef..f3d2ae1 100644 --- a/index.html +++ b/index.html @@ -5,7 +5,7 @@ - Why Git is Better Than X + Pourquoi Git est Meilleur Que X @@ -49,7 +49,7 @@
-

Why Git is Better than X

+

Pourquoi Git est Meilleur Que X

-

Cheap Local Branching

+

Branches Locales faciles

@@ -154,7 +154,7 @@

Cheap Local Branching

svn perforce
-

Everything is Local

+

Tout est Local

@@ -199,7 +199,7 @@

Everything is Local

perforce
-

Git is Fast

+

Git est rapide

@@ -362,7 +362,7 @@

Git is Fast

svn
-

Git is Small

+

Git est Léger

@@ -421,7 +421,7 @@

Git is Small

perforce
-

The Staging Area

+

La Zone de Staging

Unlike the other systems, Git has what it calls the "staging area" @@ -459,7 +459,7 @@

The Staging Area

perforce
-

Distributed

+

Distribué

@@ -519,7 +519,7 @@

Distributed

perforce
-

Any Workflow

+

N'importe quel Workflow

@@ -654,7 +654,7 @@

GitHub

perforce
-

Easy to Learn

+

Facile à Apprendre

This did not used to be true - early in Git's life, it was not really @@ -675,7 +675,7 @@

Easy to Learn

-

Mercurial Help

+

Aide Mercurial

 add        add the specified files ...
 annotate   show changeset informati...
@@ -697,7 +697,7 @@ 

Mercurial Help

-

Git Help

+

Aide Git

 add        Add file contents to the index
 bisect     Find the change that introduce...
@@ -752,11 +752,9 @@ 

Git Help


From 418287b7b4a173d965b4ce7847b8a01902f58465 Mon Sep 17 00:00:00 2001 From: Scott Chacon Date: Mon, 1 Dec 2008 12:58:17 -0800 Subject: [PATCH 03/32] french version of the site --- scripts/upload.sh | 2 ++ 1 file changed, 2 insertions(+) create mode 100755 scripts/upload.sh diff --git a/scripts/upload.sh b/scripts/upload.sh new file mode 100755 index 0000000..98b4b27 --- /dev/null +++ b/scripts/upload.sh @@ -0,0 +1,2 @@ +# this script moves the files to my server +rsync -e ssh -av * whygitisbetterthanx.com:/u/apps/whygit-fr/ From d5e756468c19c1911c936d93187e89007d5b934c Mon Sep 17 00:00:00 2001 From: Scott Chacon Date: Mon, 1 Dec 2008 13:07:23 -0800 Subject: [PATCH 04/32] more up to date with english version --- index.html | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/index.html b/index.html index f6d6618..cd92d52 100644 --- a/index.html +++ b/index.html @@ -513,8 +513,6 @@

Distribué

- hg - bzr svn perforce
@@ -574,15 +572,6 @@

Dictator and Lieutenants Workflow

match and choose the workflow that is right for you.
-
- The reason I include this as an applicable argument against the - other DSCMs is that they can't push and delete multiple branches - with and without other branches, which in my opinion, severely limits - the choices of workflow that are easily implementable. They can - do the simple flows I've described above, but they cannot do them - with multiple simultaneous local branches. -
- From 4097e34d6488826d6b5fcee7b3f1e54cd2c3f3c3 Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Mon, 1 Dec 2008 22:15:04 +0100 Subject: [PATCH 05/32] add missing breakline --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index f6d6618..fc29e27 100644 --- a/index.html +++ b/index.html @@ -753,7 +753,7 @@

Aide Git

From cbb3e131f85db69728989542e6185daa8ac91b9e Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Mon, 1 Dec 2008 22:44:11 +0100 Subject: [PATCH 06/32] Traduction du premier chapitre --- index.html | 63 +++++++++++++++++++++++++++--------------------------- 1 file changed, 31 insertions(+), 32 deletions(-) diff --git a/index.html b/index.html index fc29e27..409f3f0 100644 --- a/index.html +++ b/index.html @@ -78,43 +78,42 @@

Pourquoi Git est Meilleur Que X

perforce -

Branches Locales faciles

+

Gestion Rapide des Branches

- Probably Git's most compelling feature that really makes it stand - apart from nearly every other SCM out there is it's branching - model. It is completely different from all of the models I'm - comparing it to here, most of which recommend that the best branch - is basically a clone of the repository in a new directory. + La fonctionnalités majeure qui met Git à part de tous les autres SCM + est le modèle de gestion des branches. Il est cmplétement différent + de tous les modèles que je compare ici, la plupart recommandant que la + meilleure façon de créer une branche est de cloner le dépôt dans un + nouveau répertoire.
- Git does not work like that. Git will allow you to have multiple - local branches that can be entirely independent of each other and - the creation, merging and deletion of those lines of development - take seconds. + Git ne fonctionne pas comme ça. Git vous permettra d'avoir de multiple branches locales + qui peuvent être totalement indépendante les unes des autres, + et dont la création, la fusion (merge) ou la suppression ne prend que quelaues secondes.
- This means that you can do things like : + Cela veut dire que vous pouvez faire ce genre de choses:
    -
  • Create a branch to try out an idea, commit - a few times, switch back to where you branched from, apply a patch, - switch back to where you are experimenting, then merge it in. +
  • Créer une branche pour essayer une nouvelle idée, committer quelques fois, + revenir à l'endroit où vous avez créé cette branche, appliquer un patch, + retourner là où vous expérimentez et fusionnez le avec votre branche principale.
  • -
  • Have a branch that always contains only what goes to production, - another that you merge work into for testing and several smaller - ones for day to day work +
  • Avoir une branche qui contient toujours ce qui va en production, + une autre que vous fusionnez votre travail pour faire des test, + et quelques autres plus petites pour le travail au jour le jour.
  • -
  • Create new branches for each new feature you're working on, so - you can seamlessly switch back and forth between them, then delete - each branch when that feature gets merged into your main line. +
  • Créer une nouvelle branche pour toutes les fonctionnalités que vous développez, + comme ça vous pourrez aller et revenir facilement entre-elles, et effacer chaque branche + une foi que la fonctionnalité sera incluse dans la branche principale.
  • -
  • Create a branch to experiment in, realize it's not going to - work and just delete it, abandoning the work - with nobody else - ever seeing it (even if you've pushed other branches in the meantime) +
  • Créer une branche pour vos expérimentations, et si vous réalisez que ça ne + fonctionnera pas, il vous suffit de la supprimer pour abandonner le travail, + sans personne pour le voir (même si vous poussez d'autres branches entre temps)
@@ -122,18 +121,18 @@

Branches Locales faciles

- Importantly, when you push to a remote repository, you do not - have to push all of your branches. You can only share one of your - branches and not all of them. This tends to free people to try - new ideas without worrying about having to plan how and when they - are going to merge it in or share it with others. + Important: quand vous poussez les modifications sur un dépôt distant, + vous n´êtes pas obligés de poussez toutes vos branches. Vous pouvez + partager les branches que vous désirez. Cela libère les gens pour expérimenter + avec des nouvelles idées sans se soucier de savoir quand et comment ils devront + combiner cette idée ou la partager avec les autres.
- You can find ways to do some of this with other systems, but the work - involved is much more difficult and error-prone. Git makes this - process incredibly easy and it changes the way most developers - work when they learn it. + Vous pouvez trouvez comment faire certaines de ces pratiques avec les autres systèmes, + mais le travail nécessaire est bien plus difficile et peut amener à se tromper. Git rend + ces processus incroyablement simples et ça change la manière de travailler pour la plupart des + développeurs qui les apprennent.
From 6abac0771ff4f4e9b30b77793c3b61608100e9c4 Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 00:32:32 +0100 Subject: [PATCH 07/32] Traduction GitHub --- index.html | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) diff --git a/index.html b/index.html index eb79c3c..c12e9e2 100644 --- a/index.html +++ b/index.html @@ -609,34 +609,28 @@

- I may be biased here, being as how I work for - GitHub, - but I add this section anyway because so many people say that - GitHub itself was specifically why they choose Git. + Github est à l'origine du choix de Git pour beaucoup de gens.
-
- GitHub is a reason to use Git for many people because it is more - like a social network for code than a simple hosting site. People - find other developers or projects that are similar to the things - they are doing, and can easily fork and contribute, creating a very - vibrant community around Git and the projects that people use it +
+ Github est à l'origine du choix de Git pour beaucoup de gens car c'est plus + comme un réseau social pour du code qu'un simple hébergeur. Le site permet de trouver + d'autres développeur ou des projets qui sont similaires aux choses que vous faites, et + auxquels vous pouvez facilement forker ou contribuer, en créant une communauté vibrante autour + de Git et des projets utilisés avec Git. for.
-
- There exist other services, both for Git and for the other SCMs, - but few are user-oriented or socially - targeted, and none have anywhere near the user-base. - This social aspect of GitHub is killer, and this plus all of the above features - make working with Git and GitHub a great combination for rapidly - developing open source projects. +
+ Il y a d'autres services, pour Git ou d'autres SCM, mais peu sont tournés vers l'utilisateur ou + l'usage des réseaux sociaux, et aucun n'arrive à regrouper autant de monde. L'aspect social de Github + est fantastique, et cela, en plus toutes les autres fonctionnalités précédentes, fait de Git et Github + une superbe combinaison pour rapidement développer des projets open source.
-
- This type of community is simply not available in any of the other - SCMs. -
+
+ Ce type de communauté n'existe simplemen pas avec les autres SCM. +
puls twitter From 27c9cc99f13b199913fec0461ebd7e4aa06dd850 Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 00:52:42 +0100 Subject: [PATCH 08/32] Traduction workflow --- index.html | 75 +++++++++++++++++++++++++++--------------------------- 1 file changed, 37 insertions(+), 38 deletions(-) diff --git a/index.html b/index.html index c12e9e2..2226612 100644 --- a/index.html +++ b/index.html @@ -351,7 +351,7 @@

These numbers are really not difficult to recreate, simply clone the Django project in each of the systems and try out the same commands in each.
    -
  • git clone git://github.com/brosner/django.git dj-git
  • +
  • git clone git://GitHub.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • bzr branch lp:django dj-bzr
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
  • @@ -537,55 +537,54 @@

    - One of the amazing things about Git is that because of its distributed - nature and super branching system, you can easily implement pretty - much any workflow you can think of relatively easily. + Une des choses incroyables avec Git, grâce à sa nature distribuée + et à sa superbe gestion des branches, est que vous pouvez facilement + utiliser le type de workflow qui vous semble le plus naturel.
    -

    Subversion-Style Workflow

    +

    Workflow du Style Subversion

    - A very common Git workflow, especially from people transitioning - from a centralized system, is a centralized workflow. Git will - not allow you to push if someone has pushed since the last time - you fetched, so a centralized model where all developers push to - the same server works just fine. + Il est très commun d'utiliser un workflow centralisé avec Git, + surtout pour les personnes venant juste de migrer depuis un + système centralisé. Git ne vous permettra pas de pousser un commit + si quelqu'un a modifié quelque chose depuis votre dernière mise à jour, + ce modèle centralisé où tous les développeurs poussent sur le même serveur + fonctionne très bien.

    -

    Integration Manager Workflow

    +

    Workflow gérer par un Manager d'Intégration

    - Another common Git workflow is where there is an integration - manager - a single person who commits to the 'blessed' repository, - and then a number of developers who clone from that repository, - push to their own independant repositories and ask the integrator - to pull in their changes. This is the type of development model - you often see with open source or GitHub repositories. + Un autre workflow commun à Git consiste à désigner un manager d'intégration - une seule + personne peut faire les commits sur le 'Saint-dépôt'. Le reste des développeurs clone ce + dépôt pour créer des dépôts indépendants sur lesquels ils pourront faire leurs commits, pour + ensuite demander au manager de récupérer leurs changements. C'est le modèle de développement + que vous verrez souvent avec les dépôts open source ou sur GitHub.

    -

    Dictator and Lieutenants Workflow

    +

    Workflow du Dictateur et ses Lieutenants

    - For more massive projects, you can setup your developers similar to - the way the Linux kernel is run, where people are in charge of a - specific subsystem of the project ('lieutenants') and merge in all - changes that have to do with that subsystem. Then another integrator - (the 'dictator') can pull changes from only his/her lieutenants and - the push to the 'blessed' repository that everyone then clones from - again. + Pour les projets de grande taille, vous pouvez organisez vos développeurs à la façon + du kernel Linux, où certaines personnes sont en charge d'un sous-système spécifique + du projet ('lieutenant') et elles combinent tous les changements de leur sous-système. + Puis, un autre intégrateur ('dictateur') peut récupérer seulement les changements de + ses lieutenants, et pousser ces modifications sur le 'Saint-dépôt', que tout le monde + peut cloner à nouveau.

    - Again, Git is entirely flexible about this, so you can mix and - match and choose the workflow that is right for you. -
    + Une fois encore, Git est entièrement flexible avec les workflow, vous pouvez donc mélanger, reproduire + et choisir le workflow qui vous convient. +

@@ -601,7 +600,7 @@

Dictator and Lieutenants Workflow

- GitHub + GitHub

@@ -609,11 +608,11 @@

- Github est à l'origine du choix de Git pour beaucoup de gens. + GitHub est à l'origine du choix de Git pour beaucoup de gens.
- Github est à l'origine du choix de Git pour beaucoup de gens car c'est plus + GitHub est à l'origine du choix de Git pour beaucoup de gens car c'est plus comme un réseau social pour du code qu'un simple hébergeur. Le site permet de trouver d'autres développeur ou des projets qui sont similaires aux choses que vous faites, et auxquels vous pouvez facilement forker ou contribuer, en créant une communauté vibrante autour @@ -622,14 +621,14 @@

- Il y a d'autres services, pour Git ou d'autres SCM, mais peu sont tournés vers l'utilisateur ou - l'usage des réseaux sociaux, et aucun n'arrive à regrouper autant de monde. L'aspect social de Github - est fantastique, et cela, en plus toutes les autres fonctionnalités précédentes, fait de Git et Github - une superbe combinaison pour rapidement développer des projets open source. + Il y a d'autres services, pour Git ou d'autres SCM, mais peu sont tournés vers l'utilisateur ou + l'usage des réseaux sociaux, et aucun n'arrive à regrouper autant de monde. L'aspect social de GitHub + est fantastique, et cela, en plus toutes les autres fonctionnalités précédentes, fait de Git et GitHub + une superbe combinaison pour rapidement développer des projets open source.
- Ce type de communauté n'existe simplemen pas avec les autres SCM. + Ce type de communauté n'existe simplement pas avec les autres SCM.
@@ -756,9 +755,9 @@

Aide Git


From 6e1e115e8b3f0ae28237eb1d040d29d04490ce32 Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 01:04:04 +0100 Subject: [PATCH 09/32] =?UTF-8?q?Traduction=20Distribu=C3=A9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- index.html | 40 +++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/index.html b/index.html index 2226612..c6e7e89 100644 --- a/index.html +++ b/index.html @@ -475,25 +475,27 @@

- -
- One of the coolest features of any of the Distributed SCMs, Git included, is that it's - distributed. This means that instead of doing a "checkout" of the current tip of - the source code, you do a "clone" of the entire reposititory. -
-
- This means that even - if you're using a centralized workflow, every user has what is essentially a full - backup of the main server, each of which could be pushed up to replace the main server - in the event of a crash or corruption. There is basically no single point of failure - with Git unless there is only a single point. -
- -
- This does not slow things down much, either. On average, an SVN checkout is faster than - any of the DSCMs, but not by too much. Furthermore, of the DSCMs, Git was the fastest - in my tests. -
+
+ Une des fonctions les plus cool de n'importe quel SCM distribué, + Git inclus, est qu'il est distribué. Cela veut dire qu'au lieu + de faire un "checkout" sur la dernière version du code, vous pouvez cloner + l'intégralité du dépôt. +
+ +
+ Cela veut dire que même si vous utilisez un workflow centralisé, + chaque utilisateur est essentiellement une sauvegarde complète du + serveur central, chacun pouvant servir à remplacer ce serveur central + en cas de crash ou de corruption. En simplifiant, il n'y a fondamentalement + pas de point de défaillance unique avec Git, à moins que vous n'ayez + qu'une copie de votre dépôt. +
+ +
+ Cela n'affecte en rien les performances. En moyenne, un checkout SVN est plus rapide + que n'importe quel DSCM, mas sans grande différence. De plus, concernant les DSCM, Git + était le plus rapide durant mes tests. +
From f4de12c4cb828183eab6fe8e85c7475debb730ed Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 01:16:13 +0100 Subject: [PATCH 10/32] Traduction Staging Area --- index.html | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/index.html b/index.html index c6e7e89..2c5586c 100644 --- a/index.html +++ b/index.html @@ -430,34 +430,32 @@

- La Zone de Staging + L'Aire d'Assemblage

- Unlike the other systems, Git has what it calls the "staging area" - or "index". This is an intermediate area that you can setup what - you want your commit to look like before you commit it. + A la différence des autres systèmes, Git propose ce qu'il appelle une "Aire d'Assemblage" + ou "index". C'est une zone intermédiaire où vous pouvez configurer votre commit avant de + l'effectuer.
- The cool thing about the staging area, and what sets Git apart - from all these other tools, is that you can easily stage some of - your files as you finish them and then commit them without commiting - all the modified files in your working directory, or having to list - them on the command line during the commit + La chose la plus cool grâce à cette zone, et ce qui fait que Git est à part des autres + outils, est que vous pouvez facilement assembler certains de vos fichiers en les terminant + et puis les commiter sans toucher aux autres fichiers modifiés de votre répertoire de travail, + ni les lister dans la ligne de commande durant le commit.
- This also allows you to stage parts of files that have been modified, - for example to only stage for commit the changes at the top of the - file you've been hacking on, but not the bottom changes. + Cela permet aussi d'assembler certaines parties des fichiers modifiés, + par exemple en assemblant seulement les changements au début du fichier que vous êtes en + train de coder, mais sans les changements en bas de ce fichier.
- Of course, Git also makes it pretty easy to ignore this feature - if you don't want that kind of control - just slap a '-a' to your - commit command. + Bien sur, Git permet aussi d'ignorer assez facilement cette fonctionnalité si vous ne voulez pas + de ce genre de contrôle - ajoutez juste un '-a' à votre commande de commit.
From 39281e612a8f6e5cff0a0750617eed7a4c21e1ae Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 01:22:44 +0100 Subject: [PATCH 11/32] Traduction Git est eger --- index.html | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/index.html b/index.html index 2c5586c..9879dc1 100644 --- a/index.html +++ b/index.html @@ -374,15 +374,14 @@

- Git is really good at conserving space. Your Git directory will - (in general) barely be larger than an SVN checkout - in some cases - actually smaller (apparently a lot can go in those .svn dirs). + Git est très efficace pour minimiser sa taille. Votre répertoire Git sera + (en général) a peine plus lourd qu'un checkout SVN - et voir dans certains cas + plus léger (apparemment beaucoup de choses vont dans ces répertoires .svn).
- The following numbers were taken from clones of the Django project - in each of its semi-official Git mirrors at the same point in - its history. + Les chiffres suivants viennent du clonage du projet Django, + dans chacun de ses mirroirs Git semi-officiels à un certain moment du projet.
@@ -395,7 +394,7 @@

- + @@ -403,7 +402,7 @@

- + @@ -413,9 +412,9 @@

SVN
Repo AloneDépôt Seul 24M 34M 45M
Entire DirectoryRépertoire Entier 43M 53M 64M
- * the second Bzr number is after I ran 'bzr pack', which I thought - would make it smaller, but ended up making it much, much larger for - some reason. + * le second chiffre Bzr est obtenu après avoir lancé 'bzr pack', + pensant le faire plus léger, mais finalement obtenant quelque chose + énormément plus large pour une raison inconnue.
From c7f27c7736da3faf8fea7dfb178293071b2eacc5 Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 01:34:03 +0100 Subject: [PATCH 12/32] Traduction tout en local --- index.html | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/index.html b/index.html index 9879dc1..97058ba 100644 --- a/index.html +++ b/index.html @@ -157,40 +157,38 @@

perforce

- Tout est Local + Tout en Local

- This is basically true of all the distributed SCMs, but in my - experience even more so with Git. There is very little outside - of 'fetch', 'pull' and 'push' that communicates in any way with - anything other than your hard disk. + Cela est par défaut vrai pour tous les SCM distribués, mais d'expérience + encore plus avec Git. En dehors de 'fetch', 'pull' et 'push', peu d'autres + commandes communiquent avec autre chose que votre disque dur.
- This not only makes most operations much faster than you may - be used to, but it also allows you to work on stuff offline. - That may not sound like a big deal, but I'm always amazed at - how often I actually do work offline. Being able to branch, - merge, commit and browse history of your project while on - the plane or train is very productive. + Cela ne permet pas seulement de rendre chaque opération plus rapide que d'habitude, + mais ça vous permet aussi de travailler quand vous n'êtes pas connecté à internet. + Ca n'a pas l'air important, mais je me surprend toujours du nombre de fois où je + travaille déconnecté. Avoir la possibilité de créer des branches, de combiner, de + faire des commit et parcourir l'historique de votre projet dans l'avion ou le train + est très productif.
- Even in Mercurial, common commands like 'incoming' and 'outgoing' hit - the server, where with Git you can 'fetch' all the servers data - before going offline and do comparisons, merges and logs of data - that is on the server but not in your local branches yet. + Même dans Mercurial, les commandes commune comme 'incoming' ou 'outgoing' font une + requête au serveur, alors qu'avec Git vous pouvez 'fetch' toutes les données du + serveur avant de vous déconnecter et faire des comparaisons, combinaisons et des logs + de données qui sont sur le serveurs mais pas encore dans vos branches locales.
- This means that it's very easy to have copies of not only your - branches, but also of everyones branches that are working with - you in your Git repository without having to mess your own stuff - up. + Cela signifie qu'il est très simple d'avoir une copie, non seulement de vos branches, + mais aussi des branches de tous ceux qui travaillent avec vous sur votre dépôt Git + sans avoir à gâcher vos propres affaires.
From 6644f61ad10355780ae3ea052acf8da6d80a59b8 Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 01:59:26 +0100 Subject: [PATCH 13/32] Trduction git est rapide --- index.html | 67 +++++++++++++++++++++++++++--------------------------- 1 file changed, 33 insertions(+), 34 deletions(-) diff --git a/index.html b/index.html index 97058ba..8621717 100644 --- a/index.html +++ b/index.html @@ -207,27 +207,26 @@

- Git is fast. Everyone, even most of the hard core users of these - other systems generally give Git this title. Compared to SVN and - Perforce this is somewhat because all operations are done locally. - However, even compared to the other DSCMs, Git it pretty fast. + Git est rapide. Tout le monde, même les utilisateurs les plus hardcore + des autres systèmes, donne à Git ce titre. Comparé à SVN et Preforce, + cela vient du fait que toutes les opérations se font localement. Cependant, + même comparé aux autres DSCM, Git est vraiment rapide.
- Part of this is likely because it was built to work on the Linux - kernel, which means that it has had to deal effectively with large - repositories from day one. - Another reason is that Git is written in C, and yet another reason - is that the primary developers are, in my experience, very very - preoccupied with this. + Une partie de l'origine de cette vitesse vient du fait que Git a été construit + pour travailler sur le noyau Linux, ce qui veut dire qu'il devait gérer efficacement + un large nombre de dépôt dès le premier jour. + Un autre raison est que Git est écrit en C, et encore une autre raison est que les + développeur à l'origine de git sont, à mon expérience, très très soucieux de la rapidité + de leurs applications.
- The following are a number of benchmarks that I performed on three - copies of the Django source code repository in 3 different SCMs: - Git, Mercurial and Bazaar. I also tested some of this stuff in SVN, - but trust me, it's slower - basically take the Bazaar numbers and - then add network latency... + Voici quelques benchmarks que j'ai effectué sur 3 copies du dépôt des sources de Django + avec 3 SCM différents: Git, Mercurial et Bazaar. J'ai aussi testé quelques parties sur + SVN, mais croyais moi, c'est plus lent - en gros prenez les chiffres de Bazaar et ajoutez + le temps de latence du réseau...
@@ -254,10 +253,11 @@

- The end result was that for everything but adding new files, Git - was fastest. (Also really large commits, which Hg was basically the - same at, but the commit I tested was so large that you're unlikely - to ever do anything like it - normal commits are much faster in Git) + Le résultat final est que pour toutes les commandes, à part l'ajout d'un fichier, + Git est le plus rapide. (Aussi pour les commit très larges, dans lequel Hg a des + résultat similaires, mais le commit que j'ai testé était tellement grand qu'il est + vraisemblable que vous tombiez sur ce genre de cas - les commit normaux sont plus rapides + avec Git)
@@ -310,19 +310,19 @@

- + - + - + @@ -330,24 +330,23 @@

23.002s
Commit (Small)Commit (Petit) 0.086s 0.517s 1.139s
Branch (Cold)Branch (Froid) 1.161s 94.681s 82.249s
Branch (Hot)Branch (Chaud) 0.070s 12.300s 39.411s
- The cold and hot branching numbers are the numbers for the first - and second times that I branched a repo - the second number being - a branch with a hot disk cache. + Les chiffres des branches à froid et à chaud sont les chiffres de la création + d'une première puis d'une seconde branche sur le dépôt - le second chiffre + étant une branche avec un cache disque déjà prêt.
- It should be noted that although the 'add' numbers are much slower, - this was for a massive add operation - over 2000 files. For the - majority of what most people do on a daily basis, add ops in any - of these systems will only take a fraction of a second. All of the - other ops tested here (except for the large commit, possibly) are - more indicitive of things you might actually do day to day. + Bien que les chiffres 'add' sont bien plus petit, c'était une opération d'ajout + massif - plus de 2000 fichiers. Pour la majorité des cas que les gens rencontrent + chaque jour, les opérations d'ajout ne prennent qu'une fraction de seconde. Toutes + les autres opérations testées ici (à part peut-être le l'énorme commit) son plus + indicatifs des choses que vous serez amenés à faire au jour le jour.
- These numbers are really not difficult to recreate, simply clone the Django - project in each of the systems and try out the same commands in each. + Ces chiffres ne sont pas difficiles à reproduire, il vous suffit de cloner le projet Django + avec chaque système et d'essayer la même commande dans chacun.
  • git clone git://GitHub.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • @@ -569,7 +568,7 @@

    Workflow du Dictateur et ses Lieutenants

    Pour les projets de grande taille, vous pouvez organisez vos développeurs à la façon - du kernel Linux, où certaines personnes sont en charge d'un sous-système spécifique + du noyau Linux, où certaines personnes sont en charge d'un sous-système spécifique du projet ('lieutenant') et elles combinent tous les changements de leur sous-système. Puis, un autre intégrateur ('dictateur') peut récupérer seulement les changements de ses lieutenants, et pousser ces modifications sur le 'Saint-dépôt', que tout le monde From 8fb125da0dda4a540a551d061c19fc9b0ce4dd9a Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 02:13:17 +0100 Subject: [PATCH 14/32] Traduction Apprentissage Facile --- index.html | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/index.html b/index.html index 8621717..5256ce6 100644 --- a/index.html +++ b/index.html @@ -651,24 +651,25 @@

    - Facile à Apprendre + Apprentissage Facile

    -
    - This did not used to be true - early in Git's life, it was not really - an SCM so much as a bunch of tools that let you do versioned filesystem - work in a distributed manner. However, today, the command set and - learning curve of Git are pretty similar to any other SCM, and even - better than some. +
    + Ce n'a pas toujours été le cas - dans les premières version de Git, + ce n'était pas vraiment un SCM, sinon un groupe d'outils qui vous + permettez de travailler avec des versions sur un système de fichier, + de manière décentralisé. Cependant, aujourd'hui, la liste des commandes + et la vitesse d'apprentissage de Git sont assez similaires aux autres + SCM, et même meilleures que certains.
    -
    - Since this is difficult to prove objectively without some sort of - study, I'll just show the difference between the default 'help' menu for the - Mercurial and Git commands. I've highlighted the commands that are - identical (or nearly) between the two systems. (In Hg, if you type 'hg help', you - get a list of 40-some commands.) +
    + Il est difficile de prouver objectivement cela sans quelque sorte d'étude, + je vais vous montrer la différence entre le menu 'help' par défaut pour les + commandes Git et Mercurial. J'ai surligné les commandes qui sont identiques + (ou presque) entre les 2 systèmes. (avec Hg, si vous tapez 'hg help', vous + obtiendrez un liste d'une quarantaine de commandes).
    @@ -723,18 +724,17 @@

    Aide Git

    -
    - Prior to Git 1.6, all of the Git commands used to be in the executable - path, which was very confusing to people. Although Git still recognizes - all of those commands, the only command in the path is now 'git'. - So, if you look at Mercurial and Git, Git has a nearly identical - command set and help system - there is very little difference from - a beginning UI perspective today. +
    + Avant Git 1.6, toutes les commandes Git étaient des chemin vers des fichiers exécutables, + cela était très déroutant pour beaucoup de monde. Bien que Git reconnaisse toujours toutes + ces commandes, 'git' est maintenant la seule commande dans le path. Donc, si vous regardez + Mercurial et Git, Git a maintenant une liste de commande, et un système d'aide, presque + identique - il y a très peu de différence au niveau de l'interface auourd'hui.
    -
    - These days it's pretty hard to argue that Mercurial or Bazaar is any - easier to learn than Git is. +
    + Ces jours-ci, il est plutôt difficile de dire que Mercurial ou Bazaar sont plus facile à + apprendre que Git.
    From aff5c4aacbb9fd9caef66e096fb1020a20ae1384 Mon Sep 17 00:00:00 2001 From: John Mettraux Date: Tue, 2 Dec 2008 11:57:09 +0900 Subject: [PATCH 15/32] typo fixing and some rephrasing --- index.html | 71 +++++++++++++++++++++++++----------------------------- 1 file changed, 33 insertions(+), 38 deletions(-) diff --git a/index.html b/index.html index 5256ce6..4c68039 100644 --- a/index.html +++ b/index.html @@ -85,17 +85,17 @@

    - La fonctionnalités majeure qui met Git à part de tous les autres SCM - est le modèle de gestion des branches. Il est cmplétement différent - de tous les modèles que je compare ici, la plupart recommandant que la + La fonctionnalité majeure qui met Git à part de tous les autres SCM + est le modèle de gestion des branches. Il est complétement différent + de tous les modèles comparés ici, la plupart recommandant que la meilleure façon de créer une branche est de cloner le dépôt dans un nouveau répertoire.
    - Git ne fonctionne pas comme ça. Git vous permettra d'avoir de multiple branches locales + Git ne fonctionne pas comme ça. Git vous permettra d'avoir de multiples branches locales qui peuvent être totalement indépendante les unes des autres, - et dont la création, la fusion (merge) ou la suppression ne prend que quelaues secondes. + et dont la création, la fusion (merge) ou la suppression ne prennent que quelques secondes.
    @@ -112,10 +112,10 @@

  • Créer une nouvelle branche pour toutes les fonctionnalités que vous développez, comme ça vous pourrez aller et revenir facilement entre-elles, et effacer chaque branche - une foi que la fonctionnalité sera incluse dans la branche principale. + une fois que la fonctionnalité est incluse dans la branche principale.
  • Créer une branche pour vos expérimentations, et si vous réalisez que ça ne - fonctionnera pas, il vous suffit de la supprimer pour abandonner le travail, + fonctionne pas, il vous suffit de la supprimer pour abandonner le travail, sans personne pour le voir (même si vous poussez d'autres branches entre temps)
@@ -132,8 +132,8 @@

- Vous pouvez trouvez comment faire certaines de ces pratiques avec les autres systèmes, - mais le travail nécessaire est bien plus difficile et peut amener à se tromper. Git rend + Vous pouvez repliquer certaines de ces pratiques avec les autres systèmes, + mais l'effort nécessaire est bien plus grand et peut amener à se tromper. Git rend ces processus incroyablement simples et ça change la manière de travailler pour la plupart des développeurs qui les apprennent.
@@ -172,7 +172,7 @@

mais ça vous permet aussi de travailler quand vous n'êtes pas connecté à internet. Ca n'a pas l'air important, mais je me surprend toujours du nombre de fois où je travaille déconnecté. Avoir la possibilité de créer des branches, de combiner, de - faire des commit et parcourir l'historique de votre projet dans l'avion ou le train + faire des commit et de parcourir l'historique de votre projet dans l'avion ou le train est très productif.

@@ -182,7 +182,7 @@

Même dans Mercurial, les commandes commune comme 'incoming' ou 'outgoing' font une requête au serveur, alors qu'avec Git vous pouvez 'fetch' toutes les données du serveur avant de vous déconnecter et faire des comparaisons, combinaisons et des logs - de données qui sont sur le serveurs mais pas encore dans vos branches locales. + de données qui sont sur les serveurs mais pas encore dans vos branches locales.
@@ -208,24 +208,24 @@

Git est rapide. Tout le monde, même les utilisateurs les plus hardcore - des autres systèmes, donne à Git ce titre. Comparé à SVN et Preforce, + des autres systèmes, donnent à Git ce titre. Comparé à SVN et Preforce, cela vient du fait que toutes les opérations se font localement. Cependant, même comparé aux autres DSCM, Git est vraiment rapide.
Une partie de l'origine de cette vitesse vient du fait que Git a été construit - pour travailler sur le noyau Linux, ce qui veut dire qu'il devait gérer efficacement + pour travailler le source du noyau Linux, ce qui veut dire qu'il devait gérer efficacement un large nombre de dépôt dès le premier jour. Un autre raison est que Git est écrit en C, et encore une autre raison est que les - développeur à l'origine de git sont, à mon expérience, très très soucieux de la rapidité + développeurs à l'origine de git sont, à mon expérience, très très soucieux de la rapidité de leurs applications.
- Voici quelques benchmarks que j'ai effectué sur 3 copies du dépôt des sources de Django + Voici quelques benchmarks que j'ai effectués sur 3 copies du dépôt des sources de Django avec 3 SCM différents: Git, Mercurial et Bazaar. J'ai aussi testé quelques parties sur - SVN, mais croyais moi, c'est plus lent - en gros prenez les chiffres de Bazaar et ajoutez + SVN, mais croyez moi, c'est plus lent - en gros prenez les chiffres de Bazaar et ajoutez le temps de latence du réseau...
@@ -339,7 +339,7 @@

Bien que les chiffres 'add' sont bien plus petit, c'était une opération d'ajout massif - plus de 2000 fichiers. Pour la majorité des cas que les gens rencontrent chaque jour, les opérations d'ajout ne prennent qu'une fraction de seconde. Toutes - les autres opérations testées ici (à part peut-être le l'énorme commit) son plus + les autres opérations testées ici (à part peut-être le l'énorme commit) sont plus indicatifs des choses que vous serez amenés à faire au jour le jour.

@@ -372,7 +372,7 @@

Git est très efficace pour minimiser sa taille. Votre répertoire Git sera - (en général) a peine plus lourd qu'un checkout SVN - et voir dans certains cas + (en général) à peine plus lourd qu'un checkout SVN - et voir dans certains cas plus léger (apparemment beaucoup de choses vont dans ces répertoires .svn).
@@ -450,7 +450,7 @@

- Bien sur, Git permet aussi d'ignorer assez facilement cette fonctionnalité si vous ne voulez pas + Bien sûr, Git permet aussi d'ignorer assez facilement cette fonctionnalité si vous ne voulez pas de ce genre de contrôle - ajoutez juste un '-a' à votre commande de commit.
@@ -552,10 +552,10 @@

Workflow du Style Subversion


-

Workflow gérer par un Manager d'Intégration

+

Workflow géré par un Manager d'Intégration

- Un autre workflow commun à Git consiste à désigner un manager d'intégration - une seule + Un autre workflow commun pour Git consiste à désigner un manager d'intégration - une seule personne peut faire les commits sur le 'Saint-dépôt'. Le reste des développeurs clone ce dépôt pour créer des dépôts indépendants sur lesquels ils pourront faire leurs commits, pour ensuite demander au manager de récupérer leurs changements. C'est le modèle de développement @@ -603,23 +603,18 @@

-
- GitHub est à l'origine du choix de Git pour beaucoup de gens. -
-
GitHub est à l'origine du choix de Git pour beaucoup de gens car c'est plus - comme un réseau social pour du code qu'un simple hébergeur. Le site permet de trouver - d'autres développeur ou des projets qui sont similaires aux choses que vous faites, et + un "réseau social pour code source" qu'un simple hébergeur. Le site permet de trouver + d'autres développeurs ou des projets qui sont similaires aux choses que vous faites, et auxquels vous pouvez facilement forker ou contribuer, en créant une communauté vibrante autour de Git et des projets utilisés avec Git. - for.
Il y a d'autres services, pour Git ou d'autres SCM, mais peu sont tournés vers l'utilisateur ou l'usage des réseaux sociaux, et aucun n'arrive à regrouper autant de monde. L'aspect social de GitHub - est fantastique, et cela, en plus toutes les autres fonctionnalités précédentes, fait de Git et GitHub + est fantastique, et cela, en plus de toutes les autres fonctionnalités précédentes, fait de Git et GitHub une superbe combinaison pour rapidement développer des projets open source.
@@ -656,16 +651,16 @@

- Ce n'a pas toujours été le cas - dans les premières version de Git, + Cela n'a pas toujours été le cas - dans les premières versions de Git, ce n'était pas vraiment un SCM, sinon un groupe d'outils qui vous - permettez de travailler avec des versions sur un système de fichier, - de manière décentralisé. Cependant, aujourd'hui, la liste des commandes + permettaient de travailler avec des versions sur un système de fichier, + de manière décentralisée. Cependant, aujourd'hui, la liste des commandes et la vitesse d'apprentissage de Git sont assez similaires aux autres - SCM, et même meilleures que certains. + SCM, et même meilleures.
- Il est difficile de prouver objectivement cela sans quelque sorte d'étude, + Il est difficile de prouver objectivement cela sans une étude de quelque sorte; je vais vous montrer la différence entre le menu 'help' par défaut pour les commandes Git et Mercurial. J'ai surligné les commandes qui sont identiques (ou presque) entre les 2 systèmes. (avec Hg, si vous tapez 'hg help', vous @@ -725,15 +720,15 @@

Aide Git

- Avant Git 1.6, toutes les commandes Git étaient des chemin vers des fichiers exécutables, + Avant Git 1.6, toutes les commandes Git étaient des chemins vers des fichiers exécutables, cela était très déroutant pour beaucoup de monde. Bien que Git reconnaisse toujours toutes ces commandes, 'git' est maintenant la seule commande dans le path. Donc, si vous regardez - Mercurial et Git, Git a maintenant une liste de commande, et un système d'aide, presque - identique - il y a très peu de différence au niveau de l'interface auourd'hui. + Mercurial et Git, Git a maintenant une liste de commandes, et un système d'aide, presque + identique - il y a très peu de différence au niveau de l'interface actuellement.
- Ces jours-ci, il est plutôt difficile de dire que Mercurial ou Bazaar sont plus facile à + Ces jours-ci, il est plutôt difficile de dire que Mercurial ou Bazaar sont plus simples à apprendre que Git.
From 694e1f3357d92b891ee695fc04cf87125f0cd80e Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Tue, 2 Dec 2008 21:40:23 +0100 Subject: [PATCH 16/32] keep one-liners in footer --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 5b86a93..586491c 100644 --- a/index.html +++ b/index.html @@ -763,7 +763,7 @@

Aide Git

From 2ffff369e7f5cd2482693ca0bcc8b019cd6cab3d Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Wed, 3 Dec 2008 01:29:03 +0100 Subject: [PATCH 17/32] translate idiomatics in header --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 1de7f8c..3855ca7 100644 --- a/index.html +++ b/index.html @@ -68,7 +68,7 @@

Pourquoi Git est Meilleur Que X

- Ce site existe car je passe beaucoup de temps dernièrement à défendre les Gitsters contre les attaques de *fanboys*, *bandwagonism* et les *koolaid-thirst*. Donc, voici pourquoi les gens passent à Git après avoir utilisé X, et pourquoi vous devriez le faire aussi. Cliquez simplement sur une raison pour la voir entièrement. + Ce site existe car je passe beaucoup de temps dernièrement à défendre les Gitsters contre les critiques des hordes de fan, de moutons et de jackys vista. Donc, voici pourquoi les gens passent à Git après avoir utilisé X, et pourquoi vous devriez le faire aussi. Cliquez simplement sur une raison pour la voir entièrement.
From ef60235ec6014ca4c3ebe09bb7094b59702eb063 Mon Sep 17 00:00:00 2001 From: Jean-Pierre PRUNARET Date: Tue, 2 Aug 2011 17:07:30 +0200 Subject: [PATCH 27/32] typo --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index a2de560..e2a0ba3 100644 --- a/index.html +++ b/index.html @@ -181,7 +181,7 @@

mais ça vous permet aussi de travailler quand vous n'êtes pas connecté à internet. Ca n'a pas l'air important, mais je me surprend toujours du nombre de fois où je travaille déconnecté. Avoir la possibilité de créer des branches, de combiner, de - faire des commit et de parcourir l'historique de votre projet dans l'avion ou le train + faire des commit(s) et de parcourir l'historique de votre projet dans l'avion ou le train est très productif.

From 0dbcfd100aaf126777d2a476e0eab16e7f17d133 Mon Sep 17 00:00:00 2001 From: Jean-Pierre PRUNARET Date: Tue, 2 Aug 2011 17:13:45 +0200 Subject: [PATCH 28/32] some french words were missing or not accurate --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index e2a0ba3..01dd1ef 100644 --- a/index.html +++ b/index.html @@ -223,8 +223,8 @@

- Une partie de l'origine de cette vitesse vient du fait que Git a été construit - pour travailler le source du noyau Linux, ce qui veut dire qu'il devait gérer efficacement + Une partie de l'origine de cette vitesse vient du fait que Git a été conçu + pour gérer le code source du noyau Linux, ce qui veut dire qu'il devait gérer efficacement un large nombre de dépôt dès le premier jour. Un autre raison est que Git est écrit en C, et encore une autre raison est que les développeurs à l'origine de git sont, à mon expérience, très très soucieux de la rapidité From 4d031acad878230906c9adc9404c8d411c4e8d77 Mon Sep 17 00:00:00 2001 From: Jean-Pierre PRUNARET Date: Tue, 2 Aug 2011 17:16:21 +0200 Subject: [PATCH 29/32] negation word was missing ! * without : "it will happend" * with : "most of time, it won't happend" --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 01dd1ef..5341c2b 100644 --- a/index.html +++ b/index.html @@ -265,7 +265,7 @@

Le résultat final est que pour toutes les commandes, à part l'ajout d'un fichier, Git est le plus rapide. (Aussi pour les commit très larges, dans lequel Hg a des résultat similaires, mais le commit que j'ai testé était tellement grand qu'il est - vraisemblable que vous tombiez sur ce genre de cas - les commit normaux sont plus rapides + vraisemblable que vous tombiez pas sur ce genre de cas - les commit normaux sont plus rapides avec Git)

From 67b6ddec95bf1bb63a04229bb2ccaca5ed40224c Mon Sep 17 00:00:00 2001 From: Jean-Pierre PRUNARET Date: Tue, 2 Aug 2011 17:18:58 +0200 Subject: [PATCH 30/32] dot missing --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 5341c2b..714cbed 100644 --- a/index.html +++ b/index.html @@ -266,7 +266,7 @@

Git est le plus rapide. (Aussi pour les commit très larges, dans lequel Hg a des résultat similaires, mais le commit que j'ai testé était tellement grand qu'il est vraisemblable que vous tombiez pas sur ce genre de cas - les commit normaux sont plus rapides - avec Git) + avec Git).

From 39f89571b80494ccc0866c1a0dbbc1707b39ad10 Mon Sep 17 00:00:00 2001 From: Jean-Pierre PRUNARET Date: Tue, 2 Aug 2011 17:23:10 +0200 Subject: [PATCH 31/32] focus on original text (no need to do something) --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 714cbed..b49a2f0 100644 --- a/index.html +++ b/index.html @@ -448,7 +448,7 @@

La chose la plus cool grâce à cette zone, et ce qui fait que Git est à part des autres outils, est que vous pouvez facilement assembler certains de vos fichiers en les terminant et puis les commiter sans toucher aux autres fichiers modifiés de votre répertoire de travail, - ni les lister dans la ligne de commande durant le commit. + sans avoir besoin de les lister dans la ligne de commande durant le commit.
From 9012dcdf0c1c878fe03bf6e74839f855a9eaeb85 Mon Sep 17 00:00:00 2001 From: Jean-Pierre PRUNARET Date: Tue, 2 Aug 2011 17:35:12 +0200 Subject: [PATCH 32/32] wrong auxiliary --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index b49a2f0..8e296d2 100644 --- a/index.html +++ b/index.html @@ -487,7 +487,7 @@

Cela veut dire que même si vous utilisez un workflow centralisé, - chaque utilisateur est essentiellement une sauvegarde complète du + chaque utilisateur a essentiellement une sauvegarde complète du serveur central, chacun pouvant servir à remplacer ce serveur central en cas de crash ou de corruption. En simplifiant, il n'y a fondamentalement pas de point de défaillance unique avec Git, à moins que vous n'ayez