-i : l'option de Git qui sauve les bordéliques

Imaginez un gars qui code (n’allez pas chercher loin), mais qui n’arrive pas à développer de manière organisée. Bien sur, ce type utilise déjà une gestion de version pour limiter les dégâts, genre git.

Mais, n’empêche, quand il commence à modifier son projet, il papillonne à droite et à gauche, si bien que sa copie de travail ressemble assez rapidement à un champ de bataille. On lui a pourtant dit qu’il fallait mieux créer une branche de développement par sujet de modification pour travailler plus efficacement, mais le naturel étant ce qu’il est, sa copie de travail rassemble souvent des modifications liées à des sujets différents, voire pire, des modifications dans le même fichier…

Et c’est là que Git lui sauve encore la mise. Avec l’option -i de la commande add, il peut revoir chaque section modifiée d’un fichier et décider de l’inclure ou non dans son prochain commit. Et voilà comment on redonne forme à un tas des modifications !

Maintenant, poussons le bouchon un peu plus loin : même avec cette option magique, notre développeur a effectué une suite de validations sans queue ni tête. Il n’a rien publié encore, le résultat de ses élucubrations n‘étant vraiment pas prêt pour être vu par ses pairs. git rebase -i à la rescousse ! Avec cette commande, il peut réécrire son historique de validation, modifiant tel commit, fusionnant deux commits qui se rapportent au même sujet, divisant un commit mal formé.

Avec ses options magiques, il devient possible de rendre limpide et présentable ce qui au départ se présentait comme un travail expérimental…

GodSlayer Monday 04 October 2010 at 10:34 pm | | Logiciels libres
Used tags:

One comment

Régis

Excellent article, je note, je note…
Any news ?

Régis, (Email ) - 08-10-’10 15:53
(optional field)
(optional field)
Remember personal info?
Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.