D’abord, je dois dire que cet article est plutôt technique et est destiné à des développeurs, des designers, des gestionnaires de projet ou bien des dirigeants en technologies :-).
Si vous êtes pressés et ne voulez pas lire mon blabla, allez à la fin voir mon résumé.
Dans ma carrière, j’ai eu à utiliser plusieurs logiciels de « version control ». SVN, CVS avec Tortoise, etc…
À l’Université Laval, on utilisait un, ou l’autre de ces deux choix avec un GUI: Tortoise. Sous Windows, c’est vraiment bien. Icônes dans un menu déroulant, icône sur les fichiers modifiés et les dossiers en contenant: tout cela est bien pratique.
Lorsque j’avais ma boîte de web, sparko.ca, un des gars de mon équipe (pour ne pas nommer Mongo) m’a recommandé d’essayer Git qui gagnait alors en popularité. Pourquoi pas !
Je dois dire que si vous ne travaillez que dans un environnement Windows (serveurs et clients), vous aurez davantage de difficultés lors de l’installation. En effet, Git fonctionne sous SSH. Vous aurez donc besoin d’installer d’abord SSH sur votre serveur Git, puis des clients sur chaque machine.
Si vous êtes sous Mac ou Linux, ça va être plus simple.
Je n’entrerai pas dans les détails d’installation car il y a déjà beaucoup de documentation sur Git. Je me contenterai d’énoncer les avantages.
D’abord, j’utilise SmartGit pour MacOSX comme client qui est aussi dispo pour Windows et Linux. En tant que gestionnaire et maître des mises-en-prod (!), j’apprécie énormément l’interface de log qui me permet de voir en un coup d’oeil qui a fait quoi, quand, quel « merge » a été fait, sur quelle branche, et quand datent mes « Releases » et mes « patchs ».
J’apprécie également que ce logiciel ait brisé le paradigme du « shell » à-la-tortoise. Avec SmartGit, on a une belle interface avec un « treeview » pour parcourir l’arborescence des fichiers, avec plusieurs filtres. En un coup d’oeil, on peut voir et mettre dans le même « commit » tous les fichiers modifiés qui sont liés à une nouvelle fonctionnalité.
Avec SVN et Tortoise, on est souvent obligés de faire un gros « commit » sur un dossier avec plusieurs fonctionnalités ou corrections de bugs et souvent, on inclut des fichiers qu’on ne voulait pas nécessairement commiter.
L’avantage est gigantesque: un commit touche une et une seule fonctionnalité et il est donc facile de roll-backer seulement ce commit.
En ce qui a trait à Git, je lui trouve plusieurs avantages.
D’abord, pour les branches. Les développeurs peuvent avoir des branches locales, des branches publiques. Les branches locales sont utiles lorsqu’ils travaillent individuellement sur une nouvelle fonctionnalité compliquée qui implique plusieurs fichiers. Pendant leur travail, ils peuvent faire des « pull » et ainsi mettre à jour leur version de développement avec les modifications faites par les collègues. À mesure qu’ils atteignent des objectifs intermédiaires, ils peuvent faire des commit qui resteront locaux. Lorsque la fonctionnalité est terminé, ils peuvent faire un « merge » vers la branche commune de développement (nous on utilise Master), puis « push » et tout le monde aura accès à leur code.
Les branches publiques sont aussi très utiles lorsque plus d’un programmeur travaillent sur une même fonctionnalité et veulent partager leurs avancements. C’est aussi utile si on veut garde une sauvegarde distante du travail d’un programmeur qui aurait une branche locale.
L’avantage avec ces branches, c’est qu’un développeur peut avoir de multiples branches s’il est sur plusieurs projets en même temps. Et si on fait une mise en production et qu’on découvre un bug urgent, il n’a qu’à se mettre temporairement sur la branche Production, fixer le bug, et revenir sur une de ses branches de développement.
La fonction « git stash » est également utile pour mettre de côté temporairement des modifications à des fichiers sans faire un commit pendant qu’on fixe un bug ou autre chose.
Pour le « merging », on peut utiliser la fonction « cherry-pick » de SmartGit (ou y aller manuellement en ligne de commande avec Git). L’avantage, c’est si on veux fusionner une autre branche dans la branche courante, mais qu’on est seulement intéressé de fusionner un ou deux commit. Disons qu’on a fait une mise en production récemment. Et disons que depuis, on a ajouté sur la branche Développement 3-4 fonctionnalités/bugs. Et disons qu’on veuille seulement intégrer dans la branche Production le 2e bug corrigé. Éh bien on peut le faire !
J’aime aussi qu’avec Git, tous les commit restent en local sur l’ordinateur du développeur avant d’être « pushés ».
Finalement, avec Git, vous avez en local une et une seule version de développement. Si vous changez de branche, les fichiers de votre version locale se mettent à jour presque instantanément. Si vous faites un checkout avec SmartGit d’un certain commit, toute l’arborescence des fichiers de votre version locale se met à jour en même temps. (attention, checkout sur Git != checkout sur SVN. Checkout sur Git est pour mettre à jour l’ensemble des fichiers à un stade passé)
En résumé, donc:
- Facilité d’installation sur toutes les plateformes (sauf pour le serveur sur Windows)
- Avec SmartGit, il y a une vue pour voir les logs.
- Avec SmartGit, j’aime beaucoup la vue de « treeview » et le résumé des fichiers modifiés et la facilité de faire d’un fonctionnalité un et un seul commit, et vice-versa
- Branches locales et branches publiques
- Stash, pour mettre de côté temporairement des modifications sans les commiter
- Avec SmartGit, la fonction « cherry-pick » pour pouvoir fusionner certains commit seulement
- Les commits sont en local seulement jusqu’au moment où on les « push »
- Facile de revenir avec un checkout à un état passé de l’architecture.
- Utilisé par Facebook, LinkedIn, Microsoft, Twitter, etc… !
J’oubliais, vous pouvez même gratuitement faire héberger votre code sur github !
