fr/intro.txt

   1 // -*- mode: doc; mode: visual-line; mode: flyspell; coding: utf-8; fill-column: 79; -*-
   2 == Introduction ==
   3
   4 Je vais me servir d'une analogie pour présenter la gestion de versions.
   5 Référez-vous à http://fr.wikipedia.org/wiki/Gestion_de_versions[la page de
   6 wikipedia sur la gestion de versions] pour une explication plus censée.
   7
   8 === Le travail comme un jeu ===
   9
  10 J'ai joué à des jeux vidéos presque toute ma vie. Par contre, je n'ai commencé
  11 à utiliser des systèmes de gestion de versions qu'à l'âge adulte. Je pense ne
  12 pas être le seul dans ce cas et la comparaison entre les deux peut rendre les
  13 concepts plus simples à expliquer et à comprendre.
  14
  15 Pensez à l'édition de votre code, ou de votre document, comme s'il s'agissait
  16 de jouer à un jeu. Quand vous avez bien progressé, vous aimeriez faire une
  17 sauvegarde. Pour cela vous cliquez sur le bouton 'enregistrer' de votre fidèle
  18 éditeur.
  19
  20 Mais ceci va écraser l'ancienne version. C'est comme ces anciens jeux qui
  21 n'avaient qu'un emplacement : oui vous pouviez faire une sauvegarde mais vous
  22 ne pouviez pas revenir dans un état précédent. Quel dommage, vu que votre
  23 sauvegarde précédente pouvait éventuellement être située à un passage du jeu
  24 particulièrement amusant sur lequel vous seriez bien revenu un de ces
  25 jours. Ou, encore pire, votre seule sauvegarde était dans un état qui ne
  26 permettait pas de gagner et vous deviez tout recommencer à zéro.
  27
  28 === Gestion de versions ===
  29
  30 Lorsque vous modifiez un document, dans le but de conserver les anciennes
  31 versions, vous pouvez l'"Enregistrer Sous..." un nom de fichier différent ou le
  32 recopier ailleurs avant de l'enregistrer. Vous pouvez même compresser ces
  33 copies pour gagner de l'espace. C'est une forme primitive et laborieuse de
  34 gestion de versions. Les jeux vidéo se sont améliorés sur ce point depuis
  35 longtemps pusique la plupart proposent différents emplacements de sauvegarde
  36 automatiquement horodatés.
  37
  38 Rendons le problème légèrement plus coriace. Imaginez que vous ayez un ensemble
  39 de fichiers qui vont ensemble comme le code source d'un projet ou les fichiers
  40 d'un site web. Dans ce cas si vous voulez conserver une ancienne version, vous
  41 devez archiver le dossier en entier. Conserver un grand nombre de versions à la
  42 main n'est pas pratique et devient rapidement fastidieux.
  43
  44 Dans le cas de certains jeux vidéo, l'enregistrement d'une partie est
  45 réellement constitué d'un dossier rempli de fichiers. Ces jeux cachent ce
  46 détail au joueur et présentent une interface adaptée pour gérer différentes
  47 versions de ce dossier.
  48
  49 Les systèmes de gestion de versions ne font pas autre chose. Ils offrent tous
  50 une belle interface pour gérer un dossier rempli de plein de choses. Vous
  51 pouvez enregistrer l'état du dossier aussi souvent que vous voulez et, plus
  52 tard, vous pouvez recharger l'un des états enregistrés. À la différence de la
  53 plupart des jeux vidéos, ils sont généralement habiles pour économiser l'espace
  54 nécessaire. Typiquement, seuls quelques fichiers changent d'une version à une
  55 autre, et pas de beaucoup. Stocker ces différences au lieu des nouvelles copies
  56 complètes économise de l'espace.
  57
  58 === Gestion distribuée ===
  59
  60 Imaginez maintenant un jeu vidéo très difficile. Si difficile à terminer que
  61 plein de joueurs expérimentés de toute la planète décident de faire équipe et
  62 de partager leurs parties enregistrées pour essayer d'en venir à
  63 bout. http://fr.wikipedia.org/wiki/Speedrun[Les Speedruns] en sont un exemple
  64 concret : des joueurs qui se spécialisent dans différents niveaux du même jeu
  65 collaborent pour produire des résultats surprenants.
  66
  67 Quel système mettriez-vous en place pour qu'ils puissent accéder facilement aux
  68 sauvegardes des uns et des autres ? Et pour qu'ils puissent en téléverser de
  69 nouvelles ?
  70
  71 Dans le passé, tous les projets utilisaient une gestion de versions
  72 centralisée. Quelque part un serveur contenait l'ensemble des sauvegardes du
  73 jeu et personne d'autre. Chaque joueur conservait au plus quelques sauvegardes
  74 de parties sur leur machine. Quand un joueur voulait progresser, il
  75 téléchargeait les dernières sauvegardes du serveur, jouait un moment, puis
  76 sauvegardait et téléversait ses nouvelles sauvegardes vers le serveur pour les
  77 mettre à disposition de tous les autres.
  78
  79 Qu'en était-il si pour une raison quelconque, des joueurs voulaient obtenir une
  80 partie enregistrée antérieurement ? Peut-être la sauvegarde actuelle de la
  81 partie était-elle dans un état sans possibilité de victoire parce que quelqu'un
  82 avait oublié de prendre un objet au niveau trois, et voulaient-ils retrouver la
  83 dernière partie enregistrée au moment où la partie pouvait encore être
  84 gagnée. Ou peut-être souhaitaient-ils comparer deux parties enregistrées
  85 précédemment pour voir le travail réalisé par un joueur précis.
  86
  87 Il peut y avoir de nombreuses raisons de vouloir récupérer une ancienne
  88 version, mais le résultat est le même : ils devaient demander au serveur
  89 central cette partie précédemment sauvegardée. Et plus ils voulaient de parties
  90 sauvegardées, plus ils devaient communiquer.
  91
  92 La nouvelle génération des systèmes de gestion de versions, dont Git fait
  93 partie, sont dits systèmes distribués et peuvent être vus comme une
  94 généralisation des systèmes centralisés. Quand les joueurs téléchargent du
  95 serveur principal ils obtiennent toutes les parties sauvegardées, pas
  96 uniquement la dernière. C'est comme s'ils faisaient un
  97 http://fr.wikipedia.org/wiki/Site_miroir[miroir] du serveur central.
  98
  99 Cette opération initiale de clonage peut être coûteuse, surtout s'il y a un
 100 long historique, mais ça paie sur le long terme. Un avantage immédiat est que
 101 lorsqu'on désire une partie enregistrée, quelle qu'en soit la raison, aucune
 102 communication avec le serveur central n'est nécessaire.
 103
 104 === Une superstition idiote ===
 105
 106 Un croyance populaire veut que les systèmes distribués ne soient pas adaptés
 107 aux projets qui ont besoin d'un dépôt central officiel. Rien n'est moins
 108 vrai. Photographier quelqu'un n'a jamais eu pour effet de voler son âme. De
 109 même, cloner le dépôt principal ne diminue pas son importance.
 110
 111 Une première approximation assez bonne est que tout ce qu'un système centralisé
 112 de gestion de versions peut faire, un système distribué bien conçu peut le
 113 faire en mieux. Les ressources réseau sont simplement plus coûteuses que les
 114 ressources locales. Bien que nous verrons plus loin qu'il peut y avoir quelques
 115 inconvénients à l'approche distribuée, il y a moins de risques de faire des
 116 comparaisons erronées en utilisant cette approximation.
 117
 118 Un petit projet peut ne nécessiter qu'une fraction des fonctionnalités offertes
 119 par un tel système, mais utiliser un système qui n'autorise pas les changements
 120 d'échelle pour les petits projets c'est comme utiliser les chiffres romains
 121 pour les calculs sur des petits nombres.
 122
 123 De plus, votre projet peut grossir au-delà de vos prévisions initiales.
 124 Utiliser Git même pour les cas simples est comparable au fait d'avoir sur soi
 125 un couteau Suisse que vous utilisez surtout pour déboucher des bouteilles. Le
 126 jour où vous avez besoin d'un tournevis vous êtes content d'avoir plus qu'un
 127 simple tire-bouchon.
 128
 129 === Conflits fusionnels ===
 130
 131 Pour aborder ce sujet, notre analogie avec le jeu vidéo serait trop tirée par
 132 les cheveux. En revanche, revenons au cas de l'édition d'un document.
 133
 134 Imaginons que Alice insère une ligne au début d'un fichier, et que Bob en
 135 ajoute une à la fin de sa propre copie. Ils envoient tout les deux leurs
 136 modifications. La plupart des systèmes vont automatiquement déduire un
 137 traitement raisonnable des actions : accepter et fusionner leur modifications,
 138 ainsi les modifications de Alice et de Bob sont appliquées.
 139
 140 Maintenant imaginez que Alice et Bob ont fait des modifications différentes sur
 141 la même ligne. Il devient alors impossible de procéder sans intervention
 142 humaine. Celui qui envoie ses modifications en second est informé d'un _conflit
 143 de fusion_ (_merge conflict_), et doit choisir l'une des deux versions de la
 144 ligne, ou revoir complètement cette ligne.
 145
 146 Des situations plus complexes peuvent se présenter. Les systèmes de gestion de
 147 versions s'occupent eux même des cas les plus simples, et laissent les cas
 148 difficiles aux humains. Généralement leur comportement est configurable.
 149
 150 // LocalWords:  doc visual-line Référez-vous wikipedia cliquez web Speedruns Git
 151 // LocalWords:  mettriez-vous téléverser téléchargeait téléversait veulent-ils
 152 // LocalWords:  téléchargent clonage fusionnels Alice merge conflict configurable