Améliorer notre workflow Git

Notre équipe utilise Git depuis le début du projet mais aucun workflow n’avait été explicitement mis en place. Nous avons rencontré les problèmes de merge qui sont inévitables sans une organisation claire des branches, et nous n’utilisions pas vraiment le plein potentiel de Git.

Après certains merges particulièrement douloureux (si vous avez déjà utilisé Git à l’intérieur d’une équipe, vous avez certainement déjà rencontré le problème), nous avons décidé d’étudier les solutions possibles pour améliorer notre workflow et utiliser Git de manière plus collaborative. Les aspects qui nous semblaient les plus importants à améliorer étaient :

  • la manière dont nous utilisions les branches pour le développement de nouvelles fonctionnalités
  • avoir un historique Git plus clair (par exemple pour les cas où nous avions besoin d’utiliser le cherry pick pour reporter des modifications d’une version à une autre)
  • utiliser plus de fonctionnalités offertes par Git et Bitbucket pour améliorer l’efficacité et la productivité de l’équipe

Gérer les branches

Nous créons généralement une branche pour chaque nouvelle fonctionnalité, ce qui nous permet entre autres de tester ces fonctionnalités en utilisant un conteneur docker pour builder la branche. Des tests sont executés par les développeurs sur le conteneur avant de merger la branche et de marquer l’US comme prête à être testée par notre product owner.

Pour gérer ces branches nous avons défini un ensemble de règles afin d’essayer de réduire nos problèmes de merge :

  • mettre à jour les branches en récupérant les changements présents sur master le plus souvent possibble: c’est, à mon avis, la règle la plus importante qu’une équipe doit suivre pour éviter des conflits interminables après avoir laissé la branche diverger trop longtemps
  • utiliser la commande rebase pour éviter d’encombrer notre historique avec des commits de merge inutiles
  • squasher les commits faits sur une branche avant de la merger : de cette manière un seul commit est mergé sur master. L’historique est plus clair et le cherry pick plus facile.

Pull requests et revues de code

Puisque nous créons des branches pour chaque fonctionnalité, nous avons décidé d’utiliser les pull requests afin de pouvoir effectuer des revues de code.

Le mécanisme de pull requests de Bitbucket nous permet de notifier l’équipe de développement à chaque nouvelle pull request et de commenter le code présent sur la branche. Chaque pull request doit être approuvée par un autre membre de l’équipe avant le merge sur master.

Effectuer des revues de code nous a aidé à améliorer la qualité du code de notre application ainsi que l’efficacité de l’équipe en nous permettant de détecter certaines erreurs plus tôt dans notre processus de développement et en nous forçant à respecter les règles définies par l’équipe concernant la qualité du code.

Résumé

Mettre en place ces règles nous a aidé à améliorer notre processus de développement en harmonisant la manière dont Git et les branches sont utilisées par l’équipe, en améliorant la clareté de notre historique et en nous forçant à prêter plus attention à la qualité du code mergé sur master. Pour moi, mettre en place certaines conventions sur la manière d’utiliser Git (ou autre outil de gestion de version) au sein d’une équipe est important pour éviter de perdre du temps avec d’importants conflits et gagner en productivité.

Lucie, Front End Developer.

Share on LinkedInTweet about this on Twitter