URL: https://linuxfr.org/users/giga/journaux/pourquoi-git-mimporte Title: Pourquoi Git m'importe ? Authors: Jean-Philippe Garcia Ballester Date: 2008年04月01日T15:59:18+02:00 Tags: git Score: 1 Dans mon précédent journal, j'ai clairement indiqué ma préférence sur Git, par rapport a Subversion. Je n'avais alors pas justifié ma position, mais je souhaite maintenant le faire. C'est vrai ça, pourquoi Git* m'importe ? Un des arguments souvent rencontrés pour justifier l'intérêt de Git est la vitesse des opérations. C'est vrai que c'est agréable de pouvoir commiter instantanément. Pourtant, je travaille régulièrement avec svn, et ce manque de rapidité n'est pas quelque chose qui me gêne beaucoup. Cet argument à lui seul ne suffit pas à justifier le passage de svn à Git. Les gestionnaires de versions distribués permettent, par définition, de commiter depuis n'importe où (dans le train, le métro, l'avion, les toilettes, etc.). Pourtant, ce genre d'utilisations reste assez marginal, et à l'exception de quelques personnes, c'est une possibilité extrêmement peu utilisée. On peut également reprocher certaines choses à svn (comme l'impossibilité d'annuler un commit), mais ce sont des choix de design de subversion, et un autre gestionnaire centralisé pourrait les corriger. Pour ma part, je pense que le plus grand apport de git est son aspect bling bling, ce qui permet de mettre entre toutes les mains un gestionnaire de versions avec les avantages (scientifiquement prouvés) du bling bling. Avec subversion, seules les personnes maitrisant le shell et les regexps peuvent accéder au bling bling pour faire des essais. De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale, continuer à suivre les développements fait sur le dépôt officiel et utiliser le bling bling en un clin d'oeil. Prenons un exemple (fictif) : je suis un utilisateur régulier du logiciel XYZ, j'en suis content, mais je n'arrive jamais à m'y retrouver dans l'écran des options. Je décide donc d'essayer de refaire cet écran, mais comme je passe beaucoup de temps sur la tribune, il va probablement me falloir plusieurs semaines avant de pouvoir proposer un patch à l'auteur. Premier cas : le logiciel XYZ est versionné avec subversion. Je fais donc un checkout du trunk, et je commence à travailler dessus. Au bout de deux semaines, je commence à avoir une version intéressante de cet écran, mais entre temps, le développement a continué sur le trunk, et une nouvelle option est apparue. Je décide de faire un svn up, mais malheureusement, l'inévitable se produit : un conflit sur plusieurs fichiers. Ce n'est pas très grave, j'arrive à les corriger, et je peux me remettre au travail. J'arrive enfin à un écran des options qui me convient, et juste au moment où j'allais me décider à envoyer mon patch à l'auteur, je me dis que j'essayerais bien d'intervertir 2 options. Je fais ce dernier changement, mais pas le temps de le tester, je pars en vacances. A mon retour, je me rends compte qu'intervertir ces 2 options était une mauvaise idée. Malheureusement, comme je n'ai pas pu commité mes changements, je me retrouve à devoir me rappeler ce que j'avais fait avant de partir pour pouvoir annuler ces changements. Ecœuré par tant de dur labeur si ardu, j'abandonne. Deuxième cas : je fais un svn export du même dépôt, puis je créé un dépôt svn local pour gérer mes avancées. Je peux tranquillement travailler sur mon écran d'options. Quand j'arrive à quelque chose de convaincant, je propose un patch à l'auteur, qui le refuse, car celui-ci ne s'applique pas sur le trunk. J'essaye alors de me synchroniser avec le dépôt officiel, mais entre les nombreux conflits et le trunk qui n'arrête pas d'évoluer, je finis par abandonner :( Maintenant, le même scénario avec Git se serait beaucoup mieux passé. En effet, j'aurais eu exactement les mêmes problèmes : merges qui echouent, patch refusé parce qu'écrit n'importe comment, etc. Par contre, il y a une difference de taille : le bling bling intégré. Après de longues heures de dur labeur, au lieu d'abandonner degoûté devant l'ampleur de la tâche, j'aurais simplement fait : $ git config --global color.diff.old blink\ cyan\ magenta $ git config --global color.diff.new blink\ yellow\ green $ git config --global color.diff auto $ PAGER= git diff Devant la beauté du résultat, je serais reparti avec plus d'ardeur qu'un gnu en rut devant un manchot femelle, et j'aurais terminé dans la joie et la bonne humeur mon patch. Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages (maitriser les regexps et les pipes), mais imaginer que vous vouliez vous mettre à plusieurs pour proposer une nouvelle fonctionnalité majeure pour votre logiciel préféré. Comment programmer dans une ambience saine et conviviale sans un minimum de bling bling ? Pour moi, la grande force de git est là : pouvoir utiliser du bling bling sans maitriser des outils d'une complexité affolante. Le bling bling est la seule façon sereine de faire des développements expérimentaux tout en continuant à se synchroniser sur la base de code officielle. Git casse cette barrière entre ceux qui ont savent faire leur bling bling eux-mêmes et ceux qui ne savent pas.

AltStyle によって変換されたページ (->オリジナル) /