Historique de la page

...

Bonnes pratiques d'utilisation de ces logiciels

Git

• http://tech.libresoft.es/doku.php/git^{Image Removed} - un petit guide des meilleures pratiques pour git. Intéressant à suivre. Notamment :
  • garder des commits atomiques n'impliquant que des fonctionnalités descriptibles en une ligne. Pas de multiplicité dans les fonctionnalités ou les changements effectués.
  • Ne pas utiliser la branche maître (master) pour des développements.
  • Avant de peupler avec les nouvelles choses la branche maître, il faut que tout ait été testé et fonctionne.
• http://tbaggery.com/2008/04/13/best-practices-for-contributing-to-rails-with-git.html^{Image Removed} - Plus un guide de style pour les commentaires de commit. À suivre. Important.
• http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html^{Image Removed} - le man de git nous explique un workflow conseillé. Certains éléments sont certainement de trop si l'équipe est constituée de 4 personnes au max.
  • « As a general rule, you should try to split your changes into small logical steps, and commit each of them. They should be consistent, working independently of any later commits, pass the test suite, etc. »
  • Existance de plusieurs branches "officielle" (en plus de toutes celles créées par les utilisateurs) :
    • maint - la version qui maintient la version courante du code et sur laquelle on apporte des correctifs de bugs par exemple.
    • master - la version stable suivante du code sur laquelle se font les développements courants.
    • next - la version de test pour les choses devant aller dans le master.
    • pu - branche d'intégration pour des fonctionnalités nouvelles qui ne sont pas encore acceptée pour inclusion dans une version suivante.
  • Remarque : nom à franciser et ajouter des alias courts.
  • Utiliser les branches comme des sortes d'actions ou de (petites) tâches à faire. Un peu comme des "demandes" dans redmine. Ces branches d'une durée courte seront rapidement réintégrées dans les branches plus "officielles". Elles permettent aussi de préparer le terrain à un historique des modifications (commits) plus lisible (en « réécrivant l'histoire »).
  • fusionner des versions les plus expérimentales vers les plus établies (stables).
  • fusionner dans le sens contraire (stables -> expérimentales ou maint -> pu) rarement et pour des raisons précises (cf. doc git).
  • pour tester l'intégration d'une fonctionnalité (ou de plusieurs) ensemble avec une branche principale, utiliser une branche à mettre à la poubelle une fois les tests terminés. Ne pas se baser sur cette branche mais ne l'utiliser que pour faire des tests. Elle sera réceptrice des fusions des fonctionnalités devant être testées.
  • Une fois la nouvelle version prête pour devenir la nouvelle version maintenue, il faut la nommée avec un tag. Quelques autres manœuvres administratives juste avant (cf. man page de gitworkflow).
• http://lwn.net/Articles/328436/^{Image Removed} - Rebasing and merging: some git best practices - Quelques bonnes pratiques compilées par un publiciste des mailing lists du noyau Linux.
• http://lwn.net/Articles/328438/^{Image Removed} - Un mail de Linus sur la manière qu'il souhaite voir géré les sous-projets qu'il intègre dans son noyau Linux. En gros : historique à soi propre et ne pas écraser l'historique de ceux depuis lesquels on reprend du code.

Guides et tutoriaux

• http://www.sourcemage.org/Git_Guide^{Image Removed} - Bien : informé et assez complet.
• http://gitref.org/^{Image Removed} - la référence git.
• http://progit.org/book/^{Image Removed} - un livre sur git : Pro Git.
• http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html^{Image Removed} - un autre livre sur git - Git Magic.