SCM pour les nuls

Software Configuration Management, un terme anglais bien compliqué pour dire l'application qui va permettre d'assister le travail en équipe sur un même code source. Il en existe plusieurs dont les principaux sont :

• SVN (subversion)
  Très rependu avec sa simplicité d'utilisation. Une branche c'est un dossier et la notion de merge n'est pas réellement développé. Un commit se fait aussi toujours en ligne.
  
• Mercurial
  Moins rependu mais commence à s'implanter dans des grands projets (Firefox est sur un Mercurial par exemple), Mercurial permet des actions plus complexes, a un outil de merge et de résolution des conflits bien plus évolué que SVN.
  
• GIT
  Pour moi Git est le plus complet, notamment développé par Linus Torvards le fondateur du kernel Linux pour le développement de Linux. Git a toutefois été publié en open source. Le petit défaut de Git c'est que c'est une application à l'origine pour linux et que du coup l'utilisation sur Windows est assez compliqué.

Nous avons nos SCM, alors maintenant comment va-t-on les gérer ?

Tout d'abord, qu'est-ce qu'il ne faut pas faire : développer comme des bourrins exclusivement sur la même branche sans utiliser les tags. Si c'est pour faire ça, vous pouvez créer un dossier partagé sur un réseau vous aurez la même chose et les créateurs des SCM auront travaillé sur énormément d'options pour rien.

La branche 'trunk' ou la branche 'par défaut' doit contenir du code qui fonctionne ! Un visiteur qui viens voir votre projet et qui a envie de compiler lui-même le projet dois pouvoir le faire sans fouiller comment vous avez organisé votre SCM.

Quand vous publié une version, mettez un tag sur le commit que vous avez publié. Le tag vous permettra notamment de mieux aiguiller vos utilisateurs en étant sûr de savoir si un bug rencontré sur une version a été mal corrigé ou si la correction est apparu qu'après la publication de la version. Le fait de tager votre version vous permettra aussi de faire des fichiers diff entre deux version pour créer des patchs de mise à jour pour les utilisateurs ayant personnalisé votre application.

Au niveau des branches, faites une branche par état de votre logiciel. La branche 'trunk' ou 'default' pour votre version stable, une branche 'alpha' pour votre version alpha, etc. Une modification de dernière minute pourra toujours être effectué sur une branche. Quand vous changez une version d'état, vous n'aurez qu'un merge à faire (qui se fera sans votre intervention si vous n'avez pas trop modifié votre version à l'état plus stable). Le fait de travailler sur plusieurs versions en même temps permet notamment de pouvoir continuer à travailler sur la prochaine version le temps que vos utilisateurs testent la version instable actuelle.

Je vous conseille trois branches :

1. default : la branche de votre version stable pour que les utilisateurs tombent directement dessus.
2. unstable : la version dite "instable" que vous publié (pouvant être une release candidate ou une bêta).
3. alpha : la prochaine version en cours de développement. C'est sur cette branche que vous ferez le plus gros du développement.

Quand vous faites des projets de plus grande importance vous pourrez aussi être amené à faire des branches supplémentaires sur les différentes parties du projet afin que tous les développeurs ne se marchent pas sur les pieds.

En bonus les liens vers des SCM de grands projets :
Mozilla, Apache, OpenOffice, Linux.