<linkrel="alternate"lang="fr"xml:lang="fr"title="Git pour les nuls"type="text/html"hreflang="fr"href="/Scratch/fr/blog/2009-11-12-Git-for-n00b/Git-pour-quoi-faire/"/>
<linkrel="alternate"lang="en"xml:lang="en"title="Git for n00b"type="text/html"hreflang="en"href="/Scratch/en/blog/2009-11-12-Git-for-n00b/Git-pour-quoi-faire/"/>
<divid="sousliens"><ul><li><ahref="/Scratch/fr/blog/2009-11-12-Git-for-n00b/">la conclusion pour commencer <spanclass="nicer">»</span></a></li><li><spanclass="active"title="You're here.">Git pour quoi faire ? <spanclass="nicer">»</span></span></li><li><ahref="/Scratch/fr/blog/2009-11-12-Git-for-n00b/conf-et-install/">Avant l'utilisation, la configuration <spanclass="nicer">»</span></a></li><li><ahref="/Scratch/fr/blog/2009-11-12-Git-for-n00b/c-est-parti-pour-l-aventure/">Utiliser git avec quelques commandes simples <spanclass="nicer">»</span></a></li><li><ahref="/Scratch/fr/blog/2009-11-12-Git-for-n00b/comprendre/">Comprendre <spanclass="nicer">»</span></a></li><li><ahref="/Scratch/fr/blog/2009-11-12-Git-for-n00b/commandes-avancees/">Liste de commandes <spanclass="nicer">»</span></a></li></ul></div>
<p>Si tout ce qui vous intéresse c’est d’utiliser <ahref="http://git-scm.org"title="Git">Git</a><strong>tout de suite</strong>. Lisez simplement les parties sur fond noir. Je vous conseille aussi de revenir relire tout ça un peu plus tard, pour mieux comprendre les fondements des systèmes de versions et ne pas faire de bêtises quand vous les utilisez.</p>
<p><ahref="http://git-scm.org"title="Git">Git</a> est un <abbrtitle="Decentralized Concurent Versions System">DCVS</abbr>, c’est-à-dire un système de versions concurrentes décentralisé. Analysons chaque partie de cette appellation compliquée.</p>
<p>Lorsqu’on modifie un fichier un peu critique et qu’on a pas envie de perdre, on se retrouve souvent à le recopier sous un autre nom. Par exemple</p>
<p>Du coups, ce nouveau fichier joue le rôle de <em>backup</em>. Si on casse tout, on peut toujours écraser les modifications que nous avons faites. Évidemment le problème avec cette façon de faire c’est que ce n’est pas très professionnel. Et puis c’est un peu limité. Si on veut faire trois ou quatre modifications on se retrouve avec plein de fichiers. Parfois avec des nom bizarres comme :</p>
<p>Bon alors si on veut que ça marche il faut se fixer des conventions de nommage. Les fichiers prennent beaucoup de place alors que souvent il n’y a que quelques lignes différentes entre le fichier et son backup…</p>
<p>Il suffit de signaler que l’on va faire une nouvelle version d’un fichier et le système de version se débrouille pour l’enregistrer quelque part où on pourra facilement le retrouver. Et en général, le système de version fait les choses bien. C’est-à-dire qu’il n’utilise que très peu d’espace disque pour faire ces backups.</p>
<p>Il fut un temps où les versions étaient gérées fichier par fichier. Je pense à CVS. Puis on s’est vite aperçu qu’un projet c’est un ensemble de fichiers cohérents. Et donc il ne suffit pas de pouvoir revenir en arrière par fichier, mais plutôt dans le temps. Les numéros de versions sont donc passé d’un numéro par fichier à un numéro par projet tout entier. </p>
<li>backup automatique de tous les fichiers: <em>Revenir dans le temps.</em> ;</li>
<li>donne la possibilité de voir les différences entre chaque version et les différences entre la version en cours et les modifications locales ;</li>
<li>permet d’avoir un historique des modifications. Car en général il est demandé aux utilisateurs d’ajouter un petit commentaire à chaque nouvelle version.</li>
<p>Les systèmes de versions sont déjà intéressants pour gérer ses projets personnels. Car ils permettent de mieux organiser celui-ci. De ne (presque) plus se poser de questions à propos des backups. Je dis presque parce qu’il faut quand même penser à protéger par backup son repository. Mais là où les systèmes de versions deviennent vraiment intéressants, c’est pour la gestion de projets à plusieurs.</p>
<p>Un système de version aurait <em>mergé</em> les deux fichiers au moment où Béatrice voulait envoyer la modification sur le serveur. Et comme par magie, sur le serveur le fichier deviendra :</p>
<p>En pratique, au moment où Béatrice veut envoyer ses modifications, le système de version la préviens qu’une modification a eu lieu sur le serveur. Elle utilise la commande qui rapatrie les modifications localement et qui va mettre à jour le fichier. Ensuite Béatrice renvoie le nouveau fichier sur le serveur.</p>
<li>permet de gérer les conflits. Je n’en ai pas parlé, mais quand un conflit arrive (ça peut arriver si deux personnes modifient la même ligne avec deux contenus différents), les <abbrtitle="Systèmes de versions concurrentes">SVC</abbr> proposent leur aide pour les résoudre. J’en dirai un mot plus loin.</li>
<p>Tout d’abord, jusqu’à très récemment (SVN) il fallait être connecté sur un serveur distant pour avoir des informations sur un projet. Comme avoir l’historique. Les nouveaux systèmes décentralisés permettent de travailler avec un <em>REPOSITORY</em> (le répertoire contenant tous les backups, et les différentes info nécessaires au fonctionnement du système de versions) local au projet. Ainsi on peut avoir l’historique du projet sans avoir à se connecter au serveur.</p>
<p>Et la signification pratique est très importante. Ça veut dire que tout les utilisateurs travaillent de façon complètement indépendante les uns des autres. Et c’est l’outil de version qui se charge de mettre tout ça ensemble.</p>
<p>Ça va même encore plus loin. Ça permet de développer plusieurs features de manière complètement indépendantes. Sous les autres systèmes c’était plus difficile.</p>
<p>Je peux très facilement avec un système décentralisé, revenir sur la version qui pose problème. Résoudre le bug. Renvoyer les modifications. Puis revenir à ma version avec les améliorations en cours. Et même récupérer la correction de bug dans ma nouvelle version avec les améliorations.</p>
<p>Dans un système non décentralisé, cela est possible, mais fastidieux. Les systèmes décentralisés rendent ce type de comportement très naturels. Ainsi, il devient naturel de tirer des <em>branches</em> pour toutes les features, les bug…</p>