: Article non finalisé.
Maintenant que GitHub (et donc git) est immensément populaire, l'article ci-dessous n'est plus très pertinent.
On a plus besoin d'expliquer l'intérêt d'un gestionnaire de contrôle de version (ou "contrôle de source") pour les projets impliquant de nombreux développeurs. C'est le seul moyen de pouvoir s'y retrouver sur un projet: Pour savoir qui a fait quoi, sur quels fichiers, quand, pour pouvoir avoir les sources du projet à une date X, faire un retour-arrière, fusionner des modifications, etc. Il existe de nombreux logiciels de ce genre: RCS, CVS, subversion, Git, Mercurial, SourceSafe, ClearCase…
Utiliser ce genre de logiciel pour un projet uni-personnel peut sembler complètement overkill, mais cela a pourtant de nombreux avantages. Personnellement, j'utilise FOSSIL qui est léger à mettre en place (encore merci à Benoit M. qui m'a fait découvrir ce logiciel !).
FOSSIL inclue un gestionnaire de contrôle de version, un wiki, un blog, un système de bug-tracking et un mini-serveur web intégré.
Les bénéfices sont:
La sauvegarde du code source: Le simple fait de mettre vos sources dans le gestionnaire de version constitue une sauvegarde de fait. Sans compter que la base de source FOSSIL elle-même est un unique fichier facile à sauvegarder. En prime, vous avez la possibilité d'utiliser la synchronisation distante de FOSSIL, ce qui fait instantanément un backup sur d'autres machines (Fini le risque de perdre le travail car le serveur de sources ou votre poste de travail est mort).
Avoir à tout moment un code qui fonctionne: Fini le syndrome du "ça marchait hier". Vous pouvez revenir à tout moment à une version que vous saviez fonctionnelle. Avouez que ça fait plus sérieux, non ?
Expérimenter sans peur: Vous pouvez bidouiller à mort, expérimenter sans risquer de tout casser: Il vous suffit de créer une branche et travailler dessus, sans perturber la branche principale (sur laquelle vous pouvez continuer à corriger des bugs, par exemple). Si votre modif vous convient, fusionnez avec la branche principale. Sinon, fermez votre branche.
Un meilleur passage de connaissance: La vie de votre projet et toutes les modifications sont archivées. C'est plus simple quand il faut passer le flambeau à quelqu'un d'autre: Il aura tout l'historique du projet, jusqu'à la date de modification de la moindre ligne de code.
Une meilleure traçabilité et une plus grande transparence: Une meilleure traçabilité vis-à-vis du client… mais aussi pour vous. Vous êtes capable de dire à quelle date a été livrée la fonctionnalité X ou à quelle date a été corrigé le bug Y. (En prime, vous avez la possibilité d'ouvrir le serveur web intégré à FOSSIL à d'autre pour qu'ils puissent le consulter).
Un meilleur suivi des incidents: Avec le bug-tracker intégré à FOSSIL, vous n'oublierez pas de corriger des bugs. Vous pouvez ou non l'ouvrir aux utilisateurs afin que quiconque puisse créer un ticket d'incident. Et on peut facilement faire un lien vers le commit quand le bug est réglé, ce qui améliore encore la traçabilité.
Travailler avec plus d'assurance: Si vous travaillez sur un serveur partagé avec d'autres, vous n'aurez plus à vous poser la question de savoir si un admin ou un autre développeur a touché par inadvertance à vos sources. Et ne rien perdre si l'admin fait une bourde (shit happens). Vous avez une copie locale de votre projet, et FOSSIL peut à tout moment vous montrer les différences avec ce qu'il y a sur le serveur.
Palier à votre mémoire défaillante: Vous avez sûrement déjà éprouvé ce sentiment de vide en reprenant un projet que vous n'avez pas touché depuis 2 ans: Oh mince, comment ça marchait, déjà ? Votre base de source est la mémoire de votre projet. Vous savez sur quoi vous avez travaillé et quand. Vous pouvez retrouver comment vous avez corrigé un bug précis. Le wiki intégré aide aussi, si vous avez documenté votre projet.
Capitaliser pour des projets futurs: Votre base de source est la mémoire de votre travail. Vous pourrez vous y référer plus tard. Comment aviez vous implémenté la fonctionnalité X ? Comment avez-vous corrigé ce fichu bug ?
Travailler offline: Pour peu que vous ayez le reste de l'environnement (environnement de développement, compilateur, base de données, serveur…), vous pouvez emporter votre base FOSSIL pour travailler sur le projet offline. Quand vous revenez, resynchronisez votre base et toutes vos modifs sont répercutées (commits, wiki, tickets…).
Étendre à d'autres développeurs: Il est facile d'ouvrir FOSSIL à d'autres développeurs (FOSSIL a une gestion des droits intégrée). Et oui - le travail offline est également possible pour de multiples utilisateurs. FOSSIL gère aussi les merge.
Les cadeaux bonus de FOSSIL:
Le wiki intégré est utile pour documenter le projet. On peut faire facilement des liens vers les tickets d'incident ou les commits.
Le blog est utile pour communiquer, soit avec le client ou les utilisateurs sur les nouvelles fonctionnalités, soit avec le reste de l'équipe du projet.
En tant que développeur, vous devriez vraiment vous y mettre, même pour un petit projet perso. Avec FOSSIL aucune excuse: Il est vraiment facile à mettre en place. (Dis Benoît, quand est-ce que tu fais ton tuto sur FOSSIL ?
)
Astuce: Mettez toute l'arborescence de votre site web sous FOSSIL. Vous pourrez traquer les modifications (même effectuées par l'admin du serveur). Et vous pourrez facilement faire un retour-arrière en cas de bourde.