<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Pourquoi Git est Meilleur Que X</title>
<link rel="stylesheet" href="blueprint/screen.css" type="text/css" media="screen, projection">
<link rel="stylesheet" href="blueprint/print.css" type="text/css" media="print">
<!--[if IE]><link rel="stylesheet" href="blueprint/ie.css" type="text/css" media="screen, projection"><![endif]-->
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script src="javascripts/main.js" type="text/javascript"></script>
<style type="text/css">
html { overflow-y: scroll; }
.header h1 { font-size: 2.5em; color: #666; }
.expand_collapse_links { text-align: center; }
.expand_collapse_links a { color: #555; }
img { margin-bottom: 10px; }
.text, p { font-size: 1.2em; margin-bottom: 10px; text-align: justify;}
.intro { color: #444; }
ul li { margin-top: 10px; }
.section h2 { padding-left: 5px; background-color: #eee; cursor: pointer;}
.section h2 a { color: #333; text-decoration:none; display: block; }
.section { margin-bottom: 20px; }
.contents { padding: 0 10px; }
.args { float:right; }
.lang { padding: 3px; font-weight: bold;}
.section .lang { font-size: 0.8em; padding: 2px; font-weight: normal;}
.svn { color: hsl(260,57%,24%); background: hsl(260,57%,83%) }
.perforce { color: hsl(0,57%,24%); background: hsl(0,57%,83%) }
.bzr { color: hsl(60,57%,24%); background: hsl(60,57%,83%) }
.hg { color: hsl(190,57%,24%); background: hsl(190,57%,83%) }
.sweet { color: #363; background: #beb; }
.compare { color: #663; background: #eeb; }
.help pre { font-size: 12px; }
.help td { vertical-align: top; }
code { font-size: 90%; }
.footer { text-align: center; color: #663; background-color: #eea; padding: 10px; font-size: 90%;}
.footer a { color: #440; }
</style>
</head>
<body>
<div class="container">
<br/>
<div class="span-24 header">
<table width="100%">
<tr><td>
<h1>Pourquoi Git est Meilleur Que X</h1>
</td><td align="right">
<div id="menu">
<span class="lang hg">hg</span>
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<img style="float: right" src="images/wherex.gif">
</td></tr>
</table>
</div>
<div class="span-24">
<div class="text intro">
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 'je-sais-tout'. 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.
</div>
<div class="expand_collapse_links" style="display: none;">
<a href="#" class="expand_all">Ouvrir tout</a> |
<a href="#" class="collapse_all">Fermer tout</a>
</div>
</div>
<br/>
<div class="span-24 section">
<div class="args">
<span class="lang hg">hg</span>
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="cheap-local-branching" href="#cheap-local-branching">Gestion Rapide des Branches</a>
</h2>
<div class="contents">
<div class="text">
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.
</div>
<div class="text">
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 prennent que quelques secondes.
</div>
<div class="text">
Cela veut dire que vous pouvez faire ce genre de choses:
<ul>
<li>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.
</li>
<li>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.
</li>
<li>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 fois que la fonctionnalité est incluse dans la branche principale.
</li>
<li>Créer une branche pour vos expérimentations, et si vous réalisez que ça ne
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)
</li>
</ul>
</div>
<img src="images/branches.png">
<div class="text">
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.
</div>
<div class="text">
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.
</div>
<!-- TODO : (short screencast showing the awesomeness of git branches) -->
<!-- TODO : (show tweets somehow) -->
<div class="tweets">
<img alt='jamis twitter' width="300" src="http://twictur.es/i/1022811017.gif">
<img alt='trevorturk twitter' width="300" src="http://twictur.es/i/1022886570.gif">
<img alt='thillerson twitter' width="300" src="http://twictur.es/i/1022842917.gif">
<img alt='boblmartens twitter' width="300" src="http://twictur.es/i/1022818467.gif">
<img alt='mathie twitter' width="300" src="http://twictur.es/i/1022816942.gif">
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="everything-is-local" href="#everything-is-local">Tout en Local</a>
</h2>
<div class="contents">
<div class="text">
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.
</div>
<div class="text">
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 de parcourir l'historique de votre projet dans l'avion ou le train
est très productif.
</div>
<center><img width="500px" src="images/local-remote.png"></center>
<div class="text">
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 les serveurs mais pas encore dans vos branches locales.
</div>
<div class="text">
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.
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="git-is-fast" href="#git-is-fast">Git est rapide</a>
</h2>
<div class="contents">
<div class="text">
Git est rapide. Tout le monde, même les utilisateurs les plus hardcore
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.
</div>
<div class="text">
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
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é
de leurs applications.
</div>
<div class="text">
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 croyez moi, c'est plus lent - en gros prenez les chiffres de Bazaar et ajoutez
le temps de latence du réseau...
</div>
<table>
<tr><td nowrap>
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:2,5,60&chds=0,60&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Init">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:85,3,23&chds=0,100&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Add">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:45,194,1474&chds=0,1474&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Status">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:5,21,142&chds=0,142&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Diff">
</td><td rowspan="2">
<img src="http://chart.apis.google.com/chart?cht=bvg&chs=190x275&chd=t:1,123,390|11,946,820&chds=0,1210&chxt=x&chco=4d89f9,c6d9fd&chl=git|hg|bzr&chtt=Branching">
</td></tr>
<tr><td nowrap>
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:5,120,189&chds=0,230&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Tag">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:7,26,90&chds=0,90&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Log">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:124,125,230&chds=0,230&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Commit (Lg)">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:8,51,113&chds=0,113&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Commit (Sm)">
</td></tr>
</table>
<div class="text">
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)
</div>
<table>
<tr>
<th></th>
<th>Git</th>
<th>Hg</th>
<th>Bzr</th>
</tr>
<tr>
<th>Init</th>
<td class="sweet">0.024s</td>
<td>0.059s</td>
<td>0.600s</td>
</tr>
<tr>
<th>Add</th>
<td>8.535s</td>
<td class="sweet">0.368s</td>
<td>2.381s</td>
</tr>
<tr>
<th>Status</th>
<td class="sweet">0.451s</td>
<td>1.946s</td>
<td>14.744s</td>
</tr>
<tr>
<th>Diff</th>
<td class="sweet">0.543s</td>
<td>2.189s</td>
<td>14.248s</td>
</tr>
<tr>
<th>Tag</th>
<td class="sweet">0.056s</td>
<td>1.201s</td>
<td>1.892s</td>
</tr>
<tr>
<th>Log</th>
<td class="sweet">0.711s</td>
<td>2.650s</td>
<td>9.055s</td>
</tr>
<tr>
<th>Commit (Large)</th>
<td class="sweet">12.480s</td>
<td>12.500s</td>
<td>23.002s</td>
</tr>
<tr>
<th>Commit (Petit)</th>
<td class="sweet">0.086s</td>
<td>0.517s</td>
<td>1.139s</td>
</tr>
<tr>
<th>Branch (Froid)</th>
<td class="sweet">1.161s</td>
<td>94.681s</td>
<td>82.249s</td>
</tr>
<tr>
<th>Branch (Chaud)</th>
<td class="sweet">0.070s</td>
<td>12.300s</td>
<td>39.411s</td>
</tr>
</table>
<div class="text">
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.
</div>
<div class="text">
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) sont plus
indicatifs des choses que vous serez amenés à faire au jour le jour.
</div>
<div class="text">
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.
<ul>
<li><code>git clone git://GitHub.com/brosner/django.git dj-git</code></li>
<li><code>hg clone http://hg.dpaste.com/django/trunk dj-hg</code></li>
<li><code>bzr branch lp:django dj-bzr</code></li>
<li><code>svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn</code></li>
</ul>
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
</div>
<h2>
<a name="git-is-small" href="#git-is-small">Git est Léger</a>
</h2>
<div class="contents">
<div class="text">
Git est très efficace pour minimiser sa taille. Votre répertoire Git sera
(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).
</div>
<div class="text">
Les chiffres suivants viennent du clonage du projet Django,
dans chacun de ses mirroirs Git semi-officiels à un certain moment du projet.
</div>
<table>
<tr>
<th></th>
<th>Git</th>
<th>Hg</th>
<th>Bzr</th>
<th>Bzr*</th>
<th>SVN</th>
</tr>
<tr>
<td>Dépôt Seul</td>
<td class="sweet">24M</td>
<td>34M</td>
<td>45M</td>
<td>89M</td>
<td></td>
</tr>
<tr>
<td>Répertoire Entier</td>
<td class="compare">43M</td>
<td>53M</td>
<td>64M</td>
<td>108M</td>
<td class="compare">61M</td>
</tr>
</table>
<div class="text"><small>
* 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.
</small></div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang hg">hg</span>
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="the-staging-area" href="#the-staging-area">L'Aire d'Assemblage</a>
</h2>
<div class="contents">
<div class="text">
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.
</div>
<div class="text">
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.
</div>
<center><img src="images/index1.png"></center>
<div class="text">
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.
</div>
<div class="text">
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.
</div>
<center><img src="images/index2.png"></center>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="distributed" href="#distributed">Distribué</a>
</h2>
<div class="contents">
<div class="text">
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.
</div>
<div class="text">
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.
</div>
<div class="text">
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.
</div>
<table>
<tr><td>
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=200x150&chd=t:120,144,311,64&chds=0,320&chco=4d89f9&chl=git|hg|bzr|svn&chtt=Clone">
</td><td width="80%">
<table>
<tr>
<th>Git</th>
<td class="sweet">1m 59s</td>
</tr>
<tr>
<th>Hg</th>
<td>2m 24s</td>
</tr>
<tr>
<th>Bzr</th>
<td>5m 11s</td>
</tr>
<tr>
<th>SVN</th>
<td>1m 4s</td>
</tr>
</table>
</td></tr>
</table>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="any-workflow" href="#any-workflow">Workflow Adapté</a>
</h2>
<div class="contents">
<div class="text">
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.
</div>
<h3>Workflow du Style Subversion</h3>
<div class="text">
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.
</div>
<center><img src="images/workflow-a.png"></center><br/>
<h3>Workflow géré par un Manager d'Intégration</h3>
<div class="text">
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
que vous verrez souvent avec les dépôts open source ou sur GitHub.
</div>
<center><img src="images/workflow-b.png"></center><br/>
<h3>Workflow du Dictateur et ses Lieutenants</h3>
<div class="text">
Pour les projets de grande taille, vous pouvez organisez vos développeurs à la façon
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
peut cloner à nouveau.
</div>
<center><img src="images/workflow-c.png"></center><br/>
<div class="text">
Une fois encore, Git est entièrement flexible avec les workflow, vous pouvez donc mélanger, reproduire
et choisir le workflow qui vous convient.
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang hg">hg</span>
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="GitHub" href="#GitHub">GitHub</a>
</h2>
<div class="contents">
<img style="float:right; padding:10px" src="images/octocat.png">
<div class="text">
GitHub est à l'origine du choix de Git pour beaucoup de gens car c'est plus
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.
</div>
<div class="text">
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 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.
</div>
<div class="text">
Ce type de communauté n'existe simplement pas avec les autres SCM.
</div>
<div class="tweets">
<img alt='puls twitter' width="300" src="http://twictur.es/i/1022858126.gif">
<img alt='twitter' width="300" src="http://twictur.es/i/1022857633.gif">
</div>
</div>
</div>
<!--
OTHER IDEAS:
* easy merging
* easy server setup
* non destructive
-->
<!-- GIT MYTHS -->
<div class="span-24 section">
<div class="args">
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="easy-to-learn" href="#easy-to-learn">Apprentissage Facile</a>
</h2>
<div class="contents">
<div class="text">
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
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.
</div>
<div class="text">
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
obtiendrez un liste d'une quarantaine de commandes).
</div>
<table class="help">
<tr><td valign="top">
<h3>Aide Mercurial</h3>
<pre>
<span class="compare">add</span> add the specified files ...
<span class="compare">annotate</span> show changeset informati...
<span class="compare">clone</span> make a copy of an existi...
<span class="compare">commit</span> commit the specified fil...
<span class="compare">diff</span> diff repository (or sele...
export dump the header and diff...
<span class="compare">init</span> create a new repository ...
<span class="compare">log</span> show revision history of...
<span class="compare">merge</span> merge working directory ...
parents show the parents of the ...
<span class="compare">pull</span> pull changes from the sp...
<span class="compare">push</span> push changes to the spec...
<span class="compare">remove</span> remove the specified fil...
serve export the repository vi...
<span class="compare">status</span> show changed files in th...
update update working directory
</pre>
</td><td valign="top">
<h3>Aide Git</h3>
<pre>
<span class="compare">add</span> Add file contents to the index
<span class="compare">bisect</span> Find the change that introduce...
<span class="compare">branch</span> List, create, or delete branches
checkout Checkout a branch or paths to ...
<span class="compare">clone</span> Clone a repository into a new ...
<span class="compare">commit</span> Record changes to the repository
<span class="compare">diff</span> Show changes between commits, ...
fetch Download objects and refs from...
grep Print lines matching a pattern
<span class="compare">init</span> Create an empty git repository
<span class="compare">log</span> Show commit logs
<span class="compare">merge</span> Join two or more development h...
mv Move or rename a file, a direc...
<span class="compare">pull</span> Fetch from and merge with anot...
<span class="compare">push</span> Update remote refs along with ...
rebase Forward-port local commits to ...
reset Reset current HEAD to the spec...
<span class="compare">rm</span> Remove files from the working ...
show Show various types of objects
<span class="compare">status</span> Show the working tree status
<span class="compare">tag</span> Create, list, delete or verify...
</pre>
</td></tr>
</table>
<div class="text">
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 commandes, et un système d'aide, presque
identique - il y a très peu de différence au niveau de l'interface actuellement.
</div>
<div class="text">
Ces jours-ci, il est plutôt difficile de dire que Mercurial ou Bazaar sont plus simples à
apprendre que Git.
</div>
</div>
</div>
<!--
THINGS GIT IS STILL NOT GOOD AT
* windows (all)
* large files (svn)
-->
<br/>
<div class="span-24">
<div class="expand_collapse_links" style="display: none;">
<a href="#" class="expand_all">Expand all</a> |
<a href="#" class="collapse_all">Collapse all</a>
</div>
</div>
<br />
<div class="span-24 footer">
Ce site est construit et maintenu par <a href="http://github.com/schacon">Scott Chacon</a>, un <a href="http://GitHub.com">GitHubber</a>.<br/>
Si vous n'êtes pas d'accord avec certains points de ce site, <a href="mailto:alex.girard@gmail.com">envoyez-moi un mail</a> pour que je puisse corriger ces erreurs.<br/>
Le code de ce site est disponible <a href="http://GitHub.com/alx/whygitisbetter">sur GitHub</a> - n'hésitez pas à envoyer vos patches si vous voulez l'améliorer.
</div>
</div>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-82337-13");
pageTracker._trackPageview();
} catch(err) {}</script>
</body>
</html>
) is private.
