cbbe543fce
Remplacement de toutes les phrases du style « Dernière modification le ... [par ...] » par <date value="from git" />, qui produit une phrase du genre à partir de l'historique du dépôt. Le « from git » n'a pas d'importance, c'est juste parce que la DTD de TML (que je préfère ne pas changer) exige un attribut value. Last-change: ignore this commit
237 lines
10 KiB
XML
237 lines
10 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE html
|
||
PUBLIC "-//ENS/Tuteurs//DTD TML 1//EN"
|
||
"tuteurs://DTD/tml.dtd">
|
||
<html>
|
||
<head>
|
||
<title>Git</title>
|
||
</head>
|
||
<body>
|
||
|
||
<h1>Contrôle de versions avec Git</h1>
|
||
|
||
<h2>C'est quoi ?</h2>
|
||
|
||
<p>Le logiciel <code>git</code> est utilisé notamment par les développeurs
|
||
du noyau Linux. Il s'agit d'un logiciel de contrôle de version, comme SVN,
|
||
CVS, Arch ou encore Darcs, qui utilise des dépôts décentralisés. Il permet
|
||
ainsi de travailler tout en gardant une trace des modifications apportées
|
||
successivement, et de retrouver ainsi l'état antérieur de ses données.</p>
|
||
|
||
<p>Il permet également, comme beaucoup de ses congénères, de travailler Ã
|
||
plusieurs sur un même projet. Mais contrairement à CVS ou Subversion, par
|
||
exemple, Git ne fait pas de différence entre un dépôt principal et les
|
||
copies locales chez les différents contributeurs.</p>
|
||
|
||
<p>Ce système permet également une organisation hiérarchisée de
|
||
gros projets, comme c'est le cas du noyau Linux, en rendant
|
||
complètement naturelle l'existence de dépôts alternatifs pour chaque
|
||
sous-projet, avec une granularité de modifications très fine, et Ã
|
||
plus grande échelle, une faible granularité du dépôt principal qui
|
||
reçoit périodiquement les modifications par paquets.</p>
|
||
|
||
<p>à l'inverse, pour travailler à deux, <code>git</code> évite le
|
||
casse-tête des droits d'accès dans le dépôt de l'autre. On peut en
|
||
effet travailler de manière totalement symétrique, chacun recopiant
|
||
les modifications de l'autre : il suffit d'un accès en lecture aux
|
||
fichiers de ses collaborateurs.</p>
|
||
|
||
<p>J'expliquerai ici comment se servir de la version 1.5 de
|
||
git. Dans la version 1.4, par exemple, la commande <code>git init</code>
|
||
est appelée <code>git init-db</code>. Cette dernière, dans la version
|
||
1.5, n'est qu'un autre nom pour <code>git init</code>.</p>
|
||
|
||
<h2>Créer un dépôt git</h2>
|
||
|
||
<p>Pour créer un dépôt <code>git</code>, il suffit de taper la commande
|
||
suivante dans son répertoire de travail (que nous désignerons dans la
|
||
suite par <code>monsiteweb</code>).</p>
|
||
|
||
<pre>git init</pre>
|
||
|
||
<p>Le dépôt est initialement vide. Imaginons que l'on souhaite
|
||
suivre les modifications du fichier <code>sommaire.html</code> qui se
|
||
trouve dans le répertoire <code>monsiteweb</code>.</p>
|
||
|
||
<pre>git add sommaire.html
|
||
git commit</pre>
|
||
|
||
<p>La première indique à git notre modification : le fichier
|
||
<code>sommaire.html</code> existe et doit être pris en compte. Il n'est
|
||
pas toujours pertinent de suivre les modifications de n'importe quel
|
||
fichier. En particulier, lorsque des fichiers sont engendrés
|
||
automatiquement à partir de fichiers source, ce sont les fichiers
|
||
source et les générateurs qu'il est important de conserver. La
|
||
commande <code>git commit</code> sert à enregistrer dans le dépôt les
|
||
modifications apportées.</p>
|
||
|
||
<p>Lors d'un <em>check-in</em> (avec la commande <code>git
|
||
commit</code>), git demande un texte de journal (<em>commit
|
||
log</em>). Ce texte permet de repérer facilement les modifications
|
||
effectuées par chaque commit, aussi bien pour les autres que pour
|
||
soi-même. Chaque commit est identifié par un numéro unique,
|
||
représenté comme une suite de chiffres hexadécimaux. Ce numéro sert
|
||
de référence, par exemple, lors qu'on veut annuler une
|
||
modification.</p>
|
||
|
||
<p>La commande <code>git add</code> ajoute un fichier dans le dépôt. On
|
||
peut également s'en servir pour des répertoires entiers. Les
|
||
commandes suivantes permettent ainsi de créer et remplir un dépôt git
|
||
dans un répertoire avec tout son contenu.</p>
|
||
|
||
<pre>git init
|
||
git add *
|
||
git commit</pre>
|
||
|
||
<div class="encadre">Le dépôt git est enregistré dans le sous-répertoire
|
||
<code>.git</code> du répertoire où il a été créé. Ce dépôt peut différer du
|
||
contenu du répertoire proprement dit, si on a modifié les fichiers depuis
|
||
le dernier <em>commit</em> ou si on a importé les modifications d'un autre
|
||
contributeur. Noter que ce répertoire est souvent invisible dans les
|
||
explorateurs de fichiers et dans la sortie de la commande <code>ls</code>,
|
||
puisque son nom commence par un point. Les dépôts git peuvent être
|
||
compressés pour occuper moins de place (voir la commande <code>git
|
||
repack</code> et <code>git gc</code>).</div>
|
||
|
||
<p>On dispose d'une interface graphique (<code>git-gui</code>) et d'une
|
||
interface Web (gitweb) pour explorer agréablement un dépôt git.</p>
|
||
|
||
<h2>Travailler sur un projet géré par git</h2>
|
||
|
||
<p>Une autre manière de créer un dépôt git consiste à cloner un dépôt déjÃ
|
||
existant. Si la dénommée Xanadu possède un dépôt git dans son répertoire
|
||
<code>/home/xanadu/these</code>, le dénommé Yoda peut l'aider en clonant
|
||
son dépôt par la commande suivante</p>
|
||
|
||
<pre>git clone /home/xanadu/these cible</pre>
|
||
|
||
<p class="continue">où <code>cible</code> est le répertoire qui contiendra la copie. Yoda
|
||
peut alors travailler librement dans le répertoire <code>cible</code> comme
|
||
sur n'importe quel dépôt git dont il est le propriétaire.</p>
|
||
|
||
<div class="encadre">Ceci s'applique également aux projets situés sur des
|
||
machines distantes. On peut ainsi remplacer le répertoire par une adresse
|
||
du type <code>ssh://login@machine/home/xanadu/these</code>, si le
|
||
répertoire se trouve sur une machine à laquelle on accède par
|
||
<code>ssh</code>. La plupart des projets de logiciels libres indiquent des
|
||
adresses de la forme <code>git://git.logiciel.org/trunk</code> ou encore
|
||
<code>http://git.logiciel.org/trunk</code>.</div>
|
||
|
||
<p>Yoda effectue alors quelques opérations sur les fichiers. Il enregistre
|
||
régulièrement ses modifications dans le dépôt proprement dit en tapant</p>
|
||
|
||
<pre>git commit -a</pre>
|
||
|
||
<p>qui lui demande un texte de description pour le journal des
|
||
modifications.</p>
|
||
|
||
<p>Si d'aventure Xanadu continuait de travailler sur son projet, Yoda peut
|
||
importer les dernières modifications en lançant la commande
|
||
</p>
|
||
|
||
<pre>git pull</pre>
|
||
|
||
<p>dans son dépôt. Quant à Xanadu, si elle veut bénéficier des
|
||
modifications apportées par Yoda, se trouvant dans le répertoire
|
||
<code>/home/yoda/cible</code>, elle peut lancer la commande suivante chez
|
||
elle.</p>
|
||
|
||
<pre>git pull /home/yoda/cible</pre>
|
||
|
||
<p>Si Yoda pouvait accéder en écriture aux fichiers de Xanadu, il
|
||
pourrait également lui transmettre ses modifications par la commande
|
||
</p>
|
||
|
||
<pre>git push</pre>
|
||
|
||
<p>Entraînée par sa paresse naturelle, Xanadu aimerait facilement récupérer
|
||
les modifications de Yoda sans avoir à se rappeler le répertoire exact où
|
||
il les enregistre. Elle définit donc un raccourci de la manière
|
||
suivante</p>
|
||
|
||
<pre>git remote add yoda /home/yoda/cible</pre>
|
||
|
||
<p>La commande <code>git remote show yoda</code> permet de consulter
|
||
les informations sur le dépôt de Yoda, et <code>git pull yoda</code>
|
||
permet de récupérer directement ses modifications. On peut également
|
||
utiliser les commandes </p>
|
||
|
||
<pre>git fetch yoda
|
||
git merge yoda/master</pre>
|
||
|
||
<p class="encadre">Ici, <code>master</code> est la branche du dépôt de Yoda
|
||
que Xanadu souhaite utiliser. Un dépôt git peut comporter plusieurs
|
||
branches correspondant à autant de directions différentes de
|
||
développement. Ce système permet d'essayer diverses orientations, avant de
|
||
retenir la meilleure. La commande <code>git remote show</code> permet de
|
||
voir la liste des branches d'un dépôt enregistré dans la liste des
|
||
<em>remotes</em></p>
|
||
|
||
<h2>Travailler sur un projet géré par Subversion</h2>
|
||
|
||
<p>Contrairement à git, Subversion, dans un usage normal, ne clone pas
|
||
entièrement le dépôt distant avec ses modifications successives, mais
|
||
conserve seulement une copie de la dernière version. Il est possible
|
||
d'utiliser le modèle de travail de git tout en interagissant avec un dépôt
|
||
Subversion en utilisant le script <code>git-svn</code>. Ceci permet, par
|
||
exemple, de travailler facilement à plusieurs sur un sous-projet donné, en
|
||
envoyant périodiquement le résultat du travail.</p>
|
||
|
||
<pre>git-svn clone http://svn.site.org/svnroot/projet -T trunk -b branches -t tags</pre>
|
||
|
||
<p>La commande précédente permet d'importer la totalité d'un projet
|
||
Subversion, avec ses différentes branches et tags (correpondant
|
||
généralement aux différentes versions publiées). Attention, cela prend
|
||
généralement beaucoup de place. Cependant, l'utilisation de
|
||
<code>git-gc</code> permet de compresser les données et réduit l'espace
|
||
occupé à l'ordre de grandeur de la taille d'un <em>checkout</em> Subversion
|
||
(mais ici on garde tout l'historique).</p>
|
||
|
||
<p>On peut alors travailler normalement sur son dépôt. Les
|
||
commandes</p>
|
||
<pre>git-svn rebase
|
||
git-svn dcommit</pre>
|
||
<p class="continue">permettent respectivement de recevoir et d'envoyer les modifications
|
||
apportées.</p>
|
||
|
||
<h2>Travailler sur un projet géré par CVS</h2>
|
||
|
||
<p>Pour aspirer le contenu d'un dépôt CVS avec son historique et
|
||
l'enregistrer sous forme de dépôt git, on dispose de la commande
|
||
<code>git-cvsimport</code>.</p>
|
||
|
||
<pre>git-cvsimport -d:pserver:anonymous@cvs.truc.org:/sources projet</pre>
|
||
|
||
<p class="encadre">On peut ajouter l'option <code>-p -Z,3</code> pour
|
||
activer la compression. Pour utiliser <code>git-cvsimport</code>, il faut
|
||
au préalable s'assurer de la présence du programme <code>cvsps</code> sur
|
||
son ordinateur.</p>
|
||
|
||
<h2>Travailler sur un projet géré par Arch</h2>
|
||
|
||
<p>Pour aspirer le contenu d'un dépôt Arch avec son historique et
|
||
l'enregistrer sous forme de dépôt git, on dispose de la commande
|
||
<code>git-archimport</code>.</p>
|
||
|
||
<pre><span class="prompt">machine $</span> tla register-archive http://arch.foobar.org/archives/software
|
||
user@arch.foobar.org
|
||
<span class="prompt">machine $</span> tla my-default-archive user@arch.foobar.org
|
||
<span class="prompt">machine $</span> git-archimport software--devo--0:master</pre>
|
||
|
||
<p class="encadre">L'utilisation de <code>git-archimport</code> requiert la présence
|
||
du client <code>tla</code> qui est la façon la plus commune d'accéder aux
|
||
dépôts GNU Arch.</p>
|
||
|
||
<h2>En savoir plus</h2>
|
||
|
||
<ul>
|
||
<li>Le <a href="http://git.or.cz/">site officiel</a></li>
|
||
</ul>
|
||
|
||
<div class="metainformation">
|
||
Auteur : Rémy Oudompheng.
|
||
<date value="from git" />
|
||
</div>
|
||
|
||
</body>
|
||
</html>
|