fr/clone.txt

   1 // -*- mode: doc; mode: flyspell; coding: utf-8; fill-column: 79; -*-
   2 == Clonons gaiement ==
   3
   4 Avec les anciens systèmes de gestion de versions, l'opération standard pour
   5 obtenir des fichiers est le checkout. Vous obtenez un ensemble de fichiers
   6 correspondant à un état particulier précédemment enregistré.
   7
   8 Avec Git et d'autres systèmes distribués de gestion de versions, le clonage est
   9 l'opération standard. Pour obtenir des fichiers, on crée un 'clone' du dépôt
  10 entier. En d'autres termes, il s'agit de faire un
  11 http://fr.wikipedia.org/wiki/Site_miroir[miroir] du serveur central. Tout ce
  12 qui peut se faire sur le dépôt central peut être fait sur le vôtre.
  13
  14 === Synchronisation entre machines ===
  15
  16 Je peux imaginer faire des archives *tar* ou utiliser *rsync* pour des
  17 sauvegardes ou une synchronisation simple. Mais parfois j'édite sur mon
  18 portable, d'autres fois sur mon fixe, et les deux peuvent ne pas avoir
  19 communiqué entre temps.
  20
  21 Initialisez un dépôt Git et faites un *commit* de vos fichiers depuis une
  22 machine. Ensuite sur l'autre :
  23
  24  $ git clone autre.ordinateur:/chemin/vers/les/fichiers
  25
  26 pour créer une deuxième copie de ces fichiers et du dépôt Git.
  27
  28 À partir de ce moment,
  29
  30  $ git commit -a
  31  $ git pull autre.ordinateur:/chemin/vers/les/fichiers HEAD
  32
  33 ira chercher l'état des fichiers sur l'autre ordinateur pour mettre à jour
  34 celui sur lequel vous travaillez. Si récemment vous avez fait des modifications
  35 d'un même fichier en conflit entre elles, Git vous le signalera et vous devrez
  36 répéter à nouveau le commit après avoir résolu ces conflits.
  37
  38 === Gestion classique des sources ===
  39
  40 Initialisez le dépôt Git de vos fichiers :
  41
  42  $ git init
  43  $ git add .
  44  $ git commit -m "Commit initial"
  45
  46 Sur le serveur central, initialisez un 'dépôt nu' (*bare* dans la terminologie
  47 Git) dans un dossier quelconque :
  48
  49  $ mkdir proj.git
  50  $ cd proj.git
  51  $ git init --bare
  52  $  # variante en une ligne : GIT_DIR=proj.git git init
  53
  54 Si besoin, démarrez le démon (service) :
  55
  56  $ git daemon --detach  # peut être tourne-t-il déjà
  57
  58 Pour les services d'hébergement en ligne, suivez les instructions fournies pour
  59 mettre en place le dépôt Git initialement vide. En général il s'agit de remplir
  60 un formulaire sur une page web.
  61
  62 'Poussez' votre projet vers le serveur central en utilisant :
  63
  64  $ git push git://serveur.central/chemin/du/proj.git HEAD
  65
  66 Pour obtenir les sources, un développeur saisit :
  67
  68  $ git clone git://serveur.central/chemin/du/proj.git
  69
  70 Après avoir fait des modifications, le développeur les enregistre en local :
  71
  72  $ git commit -a
  73
  74 Pour se mettre à jour par rapport à la dernière version :
  75
  76  $ git pull
  77
  78 Tout conflit lors de la fusion doit être résolu puis validé :
  79
  80  $ git commit -a
  81
  82 Pour envoyer les modifications locales vers le dépôt central :
  83
  84  $ git push
  85
  86 Si le serveur principal a de nouvelles modifications dues à d'autres
  87 développeurs, l'envoi échoue et le développeur doit se mettre à jour de la
  88 dernière version, résoudre les éventuels conflits de fusion, puis essayer à
  89 nouveau.
  90
  91 === Dépôts nus ===
  92
  93 Un dépôt nu (*bare repository*) est nommé ainsi car il n'a pas de dossier de
  94 travail : il ne contient que des fichiers qui sont normalement cachés dans le
  95 sous dossier `.git`. En d'autres termes, il ne conserve que l'historique d'un
  96 projet et ne contient jamais le rendu d'une version donnée.
  97
  98 Un dépôt nu joue un rôle similaire à celui du serveur principal dans un système
  99 de gestion de versions centralisé : le réceptacle de vos projets. Les
 100 développeurs clonent vos projets à partir de celui-ci et y poussent les
 101 dernières modifications officielles. En général il est placé sur un serveur qui
 102 ne fait quasiment que ce travail de distribution de l'information. Le
 103 développement s'opère sur les clones de sorte que le dépôt principal peut se
 104 passer d'un dossier de travail.
 105
 106 Beaucoup des commandes de Git échouent sur un dépôt nu tant que la variable
 107 d'environnement `GIT_DIR` n'est pas renseignée avec le chemin vers le dépôt ou
 108 que l'option `--bare` n'est pas utilisée.
 109
 110 === Envoi vs rapatriement (push vs pull) ===
 111
 112 Pourquoi a-t-on introduit la commande `push` (_pousser_ ou _envoyer_) au lieu
 113 de se contenter de la commande `pull` (_tirer_ ou _rapatrier_) plus familière ?
 114 Premièrement, la commande `pull` échoue sur un dépôt nu : il faut y utiliser la
 115 commande `fetch` dont nous parlerons plus tard. Mais même si nous conservions
 116 un dépôt standard sur le serveur central, y rapatrier les modifications serait
 117 peu pratique. Nous devrions d'abord nous connecter au serveur et donner en
 118 argument à la commande `pull` l'adresse de la machine depuis laquelle nous
 119 souhaitons rapatrier des modifications. Des pare-feux peuvent éventuellement
 120 nous embêter, et comment faire si nous n'avons pas d'accès `shell` au serveur ?
 121
 122 Quoi qu'il en soit, ce cas mis à part, nous décourageons l'envoi ( en
 123 comparaison du rapatriement ) parce que cela peut entraîner des confusions
 124 lorsque la destination possède un dossier de travail.
 125
 126 En résumé, pendant votre phase d'apprentissage de Git, n'utilisez l'envoi
 127 ( push ) que lorsque la destination est un dépôt nu ; sinon rapatriez ( pull ).
 128
 129 === Forker un projet ===
 130
 131 Vous en avez marre de la manière dont est géré un projet ? Vous pensez pouvoir
 132 faire mieux ? Dans ce cas, sur votre serveur :
 133
 134  $ git clone git://serveur.principal/chemin/vers/les/fichiers
 135
 136 Ensuite, informez tout le monde du fork de ce projet sur votre serveur.
 137
 138 Par la suite, vous pouvez fusionner les modifications venant du projet originel
 139 grâce à :
 140
 141  $ git pull
 142
 143 === Système ultime de sauvegarde ===
 144
 145 Vous voulez des archives redondantes et géographiquement distribuées,
 146 permettant de faire face à un désastre ? Si votre projet a beaucoup de
 147 développeurs, ne faites rien ! Chaque clone de votre code est de fait une
 148 sauvegarde. Non seulement de l'état actuel, mais de l'historique complet. Grâce
 149 aux empreintes cryptographiques, si le clone de quelqu'un est corrompu, il sera
 150 repéré dès qu'il tentera de communiquer avec d'autres.
 151
 152 Si votre projet n'est pas si populaire, trouvez autant de serveurs que possible
 153 afin d'héberger vos clones.
 154
 155 Le vrai paranoïaque devrait toujours noter la dernière empreinte SHA1 de 20
 156 octets du HEAD dans un endroit sûr. Ce doit être sûr, pas privé. Par exemple,
 157 la publier dans un quotidien marcherait bien, parce qu'il est difficile de
 158 réaliser une attaque modifiant l'ensemble des exemplaires d'un journal.
 159
 160 === Le multi-tâche à la vitesse de la lumière ===
 161
 162 Imaginons que vous souhaitiez travailler sur plusieurs fonctionnalités en
 163 parallèle. Dans ce cas validez (`commit`) votre projet et lancez :
 164
 165  $ git clone . /un/nouveau/dossier
 166
 167 Grâce aux http://fr.wikipedia.org/wiki/Lien_mat%C3%A9riel[liens matériels], les
 168 clones locaux sont créés plus rapidement et occupent moins de place que de
 169 simples copies.
 170
 171 Vous pouvez maintenant travailler simultanément sur deux fonctionnalités
 172 indépendantes. Par exemple vous pouvez modifier l'un des clones pendant que
 173 l'autre est en cours de compilation.  À tout moment vous pouvez valider
 174 (`commit`) vos modifications puis rapatrier (`pull`) les modifications depuis
 175 l'autre clone.
 176
 177  $ git pull /mon/autre/clone HEAD
 178
 179 === Guérilla de la gestion de versions ===
 180
 181 Alors que vous travaillez sur un projet qui utilise un autre système de gestion
 182 de versions, Git vous manque ? Dans ce cas, initialisez un dépôt Git dans votre
 183 dossier de travail.
 184
 185  $ git init
 186  $ git add .
 187  $ git commit -m "Commit initial"
 188
 189 puis clonez-le :
 190
 191  $ git clone . /un/nouveau/dossier
 192
 193 Allez ensuite dans le nouveau dossier et travaillez plutôt là, utilisant Git
 194 comme vous le voulez. De temps à autre, quand vous voulez vous synchroniser
 195 avec les autres, rendez-vous dans le dossier de départ, synchronisez-le en
 196 utilisant l'autre système de gestion de version, puis saisissez :
 197
 198  $ git add .
 199  $ git commit -m "Synchro avec les autres"
 200
 201 Ensuite allez dans le nouveau dossier et lancez :
 202
 203  $ git commit -a -m "Description de mes modifications"
 204  $ git pull
 205
 206 La procédure pour partager vos modifications avec les autres dépend de l'autre
 207 système de gestion de versions. Le nouveau dossier contient les fichiers avec
 208 vos modifications. Lancez toute commande de l'autre système de gestion de
 209 versions nécessaire pour les envoyer au dépôt central.
 210
 211 Subversion, qui est peut être le meilleur système de gestion de versions
 212 centralisé est utilisé par d'innombrables projets. La commande *git svn*
 213 automatise la procédure ci-dessus pour les dépôts Subversion, et peut aussi
 214 être utilisée pour exporter un projet Git vers un dépôt Subversion.
 215
 216 === Mercurial ===
 217
 218 Mercurial est un système de gestion de versions similaire qui peut travailler
 219 quasiment sans heurt avec Git. Avec le plugin `hg-git` un utilisateur de
 220 Mercurial peut, sans rien perdre, envoyer (push) vers ou rapatrier (pull)
 221 depuis un dossier Git.
 222
 223 Téléchargez le plugin `hg-git` avec Git :
 224
 225  $ git clone git://github.com/schacon/hg-git.git
 226
 227 ou Mercurial:
 228
 229  $ hg clone http://bitbucket.org/durin42/hg-git/
 230
 231 Malheureusement, il ne semble pas y avoir de plugin analogue pour Git. Pour
 232 cette raison, il semble préférable d'utiliser Git plutôt que Mercurial pour le
 233 dépôt principal. Avec un dépôt Mercurial, il faut généralement un volontaire
 234 qui maintienne un dépôt Git en parallèle alors que, grâce au plugin `hg-git`,
 235 un dépôt Git fait l'affaire même pour les utilisateurs de Mercurial.
 236
 237 Bien que ce plugin puisse convertir un dépôt Mercurial en un dépôt Git en le
 238 poussant dans un dépôt vide, cette tâche est plus simple avec le script
 239 `hg-fast-export-git`, disponible via :
 240
 241  $ git clone git://repo.or.cz/fast-export.git
 242
 243 Pour faire une conversion, dans un nouveau dossier :
 244
 245  $ git init
 246  $ hg-fast-export.sh -r /depot/hg
 247
 248 ceci après avoir ajouté le script à votre `$PATH`.
 249
 250 === Bazaar ===
 251
 252 Nous allons rapidement évoquer Bazaar parce que c'est le système de gestion de
 253 versions distribué libre le plus populaire après Git et Mercurial.
 254
 255 Bazaar à l'avantage d'avoir plus de recul, étant donné qu'il est relativement
 256 jeune ; ses concepteurs ont pu tirer les leçons du passé et éviter des petits
 257 écueils historiques. De plus ses développeurs ont le souci de la portabilité et
 258 de l'interopérabilité avec les autres systèmes de gestion de versions.
 259
 260 Un plugin `bzr-git` permet aux utilisateurs de Bazaar de travailler avec les
 261 dépôts Git dans une certaine mesure, et permet de le faire de manière
 262 incrémentale, tandis que `bzr-fast-export` est fait pour les conversions
 263 uniques.
 264
 265 === Pourquoi j'utilise Git ===
 266
 267 Au départ j'ai choisi Git parce que j'ai entendu qu'il gérait
 268 l'inimaginablement ingérable source du noyaux Linux. Je n'ai jamais ressenti le
 269 besoin d'en changer. Git m'a rendu de fiers services et je ne me suis toujours
 270 pas heurté à ses limites. Comme j'utilise surtout Linux, les éventuels
 271 problèmes sur d'autres plateformes n'entrent pas en ligne de compte.
 272
 273 De plus je préfère les programmes C et les scripts bash aux exécutables comme
 274 les scripts Pythons : il y a moins de dépendances et je suis accro aux temps
 275 d'exécution rapides.
 276
 277 J'ai réfléchi à la manière d'améliorer Git, allant jusqu'à écrire mes propres
 278 outils de type Git, mais uniquement à des fins de recherche. Même si j'avais
 279 terminé ce projet j'aurais tout de même continué avec Git vu que les avantages
 280 sont trop peu significatifs pour justifier l'utilisation d'un système farfelu.
 281
 282 Bien sur, vos besoins et envies diffèrent sûrement et vous pouvez très bien
 283 vous trouver mieux avec un autre système. Néanmoins vous ne pouvez pas faire
 284 une grosse erreur en choisissant Git.
 285
 286 // LocalWords:  visual-line checkout Git doc Clonons clonage synchros tar rsync
 287 // LocalWords:  git HEAD init add bare mkdir proj.git cd DIR daemon detach web
 288 // LocalWords:  tourne-t-il push repository clonent fetch pare-feux shell Forker
 289 // LocalWords:  fork cryptographiques SHA multi-tâche clonez-le synchronisez-le
 290 // LocalWords:  Synchro svn Mercurial plugin hg-git Téléchargez hg-fast-export.sh
 291 // LocalWords:  hg-fast-export-git PATH Bazaar portabilité l'interopérabilité
 292 // LocalWords:  bzr-git incrémentale bzr-fast-export l'inimaginablement ingérable
 293 // LocalWords:  Linux plateformes bash accro