Améliorer votre workflow avec git-flow

Je suis tombé sur cet article l’année dernière (2012), A successful Git branching model. C’est un article très intéressant, qui est pratiquement devenu un standard. L’auteur, Vincent Driessen, y explique comment avoir un repository git organisé et propre. Il est à l’origine du concept git flow mais il ne s’est pas arrété là, il a aussi a développé une extension pour git qui facilite la mise en place et l’utilisation de toutes ses recommandations. L’extension est disponible sur Github et l’installation est assez simple.

Présentation

Git-flow, repose sur le système de branches de git. Pour faire simple :

Si vous connaissez bien git, les branches master et develop devraient déjà vous dire quelque chose, car elles ont été adoptées par un grand nombre de développeurs. Les 3 dernières branches peuvent être placées dans une catégorie que git appelle les branches topic, car elles sont spécifiques à un sujet propre.

Ci dessous, un tableau récapitulatif, expliquant les branches topic, à partir d’où elles sont créées, où le merge s’effectuera et quelle est la convention de nommage pour chacun des types feature, release et hotfix.

Branches A partir de Merge dans Convention
Feature branch develop develop feature/*
Release branch develop develop & master release/*
Hotfix master develop & master hotfix/*

Le concept est assez facile à comprendre, et à utiliser. Personnellement, j’utilise l’extension git-flow qui me fait gagner du temps pour passer d’une branche à l’autre, pour les merge. Cela dit, je n’utilise pas les branches release. Scott Chacon explique dans son blog, pourquoi ils n’utilisent pas git-flow à Github :

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day – often several times a day.

Scott Chacon - Blog

Même si on n’utilise pas toutes les fonctionnalités de git-flow, il nous donne un façon de travailler qui est très robuste. Par exemple, si on n’a pas besoin des branches hotfix, ou release, on peut juste utiliser l’extension pour les branches feature, qui facilitera les merge, et la création / suppression de nouvelles branches .

Débuter avec git-flow

Si vous n’utilisez pas git en ligne de commande, ce qui suit ne va pas beaucoup vous parler. Les commandes git sont répétitives et faciles à retenir. Et pour être encore plus rapide en ligne de commande, vous pouvez même configurer des alias.

Je pars donc du principe que vous avez installé git-flow sans problème, et que vous êtes à l’aise en ligne de commande.

Initialiser git flow

Vous devriez obtenir une série de questions vous demandant les noms de branches, vous pouvez garder celles par défaut.

$  git flow init
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

La branche par défaut est maintenant develop qu’on peut utiliser pour développer ou corriger de petites fonctionnalités. Prenons un exemple, on veut intégrer la page d’accueil, on lancera alors cette commande :

Branche feature

$  git flow feature start homepage
Switched to a new branch 'feature/homepage'

Summary of actions:
- A new branch 'feature/homepage' was created, based on 'develop'
- You are now on branch 'feature/homepage'

Now, start committing on your feature. When done, use:
    git flow feature finish homepage

C’est tout ! Et en plus git-flow résume ce qu’il vient de faire dans ce qu’il appelle “summary of actions” : 1. Une nouvelle branche feature/homepage a été créée à partir de la branche develop 1. On est maintenant sur la branche feature/homepage

Pratique ce résumé, non ?

Si on travaille en équipe, on peut aussi git push cette branche, et les autres développeurs pourront donc également accéder à cette branche et y travailler.

Continuons avec notre exemple, on vient juste de finir la page d’accueil, on a déjà effectué nos git commit, on va donc lancer cette commande :

$  git flow feature finish homepage
Switched to branch 'develop'
Updating 4a6753e..76d351e
Fast-forward
 index.html      | 112 +++++++++++
 1 file changed, 112 insertions(+)
 create mode 100644 index.html
Deleted branch feature/homepage (was 76d351e).

Summary of actions:
- The feature branch 'feature/homepage' was merged into 'develop'
- Feature branch 'feature/homepage' has been removed
- You are now on branch 'develop'

Voici ce qu’a fait git-flow pour nous faciliter la tâche : 1. Un merge de la branche feature/homepage dans la branche develop 1. Suppression de la branche feature/homepage 1. On est maintenant dans la branche develop

Parfait, notre page d’accueil est dans la branche develop - qui, je rappelle, est censé refléter le code qui est prêt à être mis en production. Si on a des tests à effectuer je recommande donc qu’on les fassent avant de fermer feature/homepage. Ainsi, tout code qui n’a pas été testé ou qui a échoué aux tests, ne vit pas au même endroit que le code à mettre en production.

Branche release

Retour à notre exemple, aujourd’hui c’est la date à laquelle on doit mettre en ligne la page d’accueil, on va alors créer une branche release. Rappel : les branches release sont créées à partir de la branche develop. Nous allons utiliser un numéro de version pour nommer votre nouvelle branche release :

$ git flow release start 1.0.0
Switched to a new branch 'release/1.0.0'

Summary of actions:
- A new branch 'release/1.0.0' was created, based on 'develop'
- You are now on branch 'release/1.0.0'

Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:
     git flow release finish '1.0.0'

Résumé : 1. Une nouvelle branche release/1.0.0 a été créée 1. On est maintenant dans la branche release/1.0.0

Actions à effectuer par la suite : - Incrémenter le numéro de version - commit les améliorations / réglages de dernières minute - Quand on a fini, on peut lancer la commande git flow release finish '1.0.0'

Par exemple, on peut changer le numéro de version dans certain de nos fichiers. Une fois que le commit pour les fichiers modifiés a été effectué, on peut alors la terminer la release :

$ git flow release finish 1.0.0
Switched to branch 'master'
Deleted branch release/v1.0.0 (was 76d351e).

Summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master'
- The release was tagged '1.0.0'
- Release branch has been back-merged into 'develop'
- Release branch 'release/v1.0.0' has been deleted

Résumé : - Les fichiers les plus récents ont été récupérés à partir du serveur - Un merge de la branche release dans la branche master a été effectué - La release a été taggé ‘1.0.0’, pour accéder facilement à l’historique des versions - Un merge de la branche release dans la branche develop a été effectué, de cette manière la branche develop contiendra mainteant les corrections de bugs qui ont été effectués dans des branches hotfix ( voir plus bas ) - La branche release a été supprimée

Chose importante à noter, après avoir lancer cette commande, git-flow nous demandera alors d’éditer un fichier où l’on peut ajouter un message d’annotation au tag de cette release.

On peut ensuite accéder à l’historique des versions en utilisant les tags :

$ git show 1.0.0
tag 1.0.0
Tagger: Jerome <email@example.com>
Date:   Fri Mar 29 18:05:54 2013 +1100
- Homepage done

Branche hotfix

Les branches hotfix sont ce que je dirai hors flow, elles ne sont pas planifiées et n’existent pour une seule chose : corriger un bug en production et rien d’autre. Par conséquent, elles sont créées à partir de master. Rappel : master est une copie exacte du code en production.

$ git flow hotfix start 1.0.1
Switched to a new branch 'hotfix/1.0.1'

Summary of actions:
- A new branch 'hotfix/1.0.1' was created, based on 'master'
- You are now on branch 'hotfix/1.0.1'

Follow-up actions:
- Bump the version number now!
- Start committing your hot fixes
- When done, run:
     git flow hotfix finish '1.0.1'

Résumé : 1. Une nouvelle branche hotfix/1.0.1 a été créée à partir de master 1. On est dans la branche hotfix/1.0.1

Actions à effectuer par la suite : - Incrémenter le numéro de version - commit les corrections

Quand on a fini les corrections :

$ git flow hotfix finish '1.0.1'
Switched to branch 'develop'
Already up-to-date!
Merge made by the 'recursive' strategy.
Deleted branch hotfix/1.0.1 (was dd77b58).

Summary of actions:
- Latest objects have been fetched from 'origin'
- Hotfix branch has been merged into 'master'
- The hotfix was tagged '1.0.1'
- Hotfix branch has been back-merged into 'develop'
- Hotfix branch 'hotfix/1.0.1' has been deleted

Résumé : - Les fichiers les plus récents ont été récupérés à partir du serveur - Un merge de la branche hotfix dans la branche master a été effectué - Le tag ‘1.0.1’ a été ajouté au commit - Un merge de la branche hotfix dans la branche develop a été effectué - La branche release a été supprimée

Alors, convaincu ?

Cet exemple nous montre comment avoir un repo bien organisé avec des branches sémantiques. Sans l’extension git-flow on passerait beaucoup plus de temps dans le terminal pour effectué toutes ces actions. Créer une branche, merge une branche dans une autre, supprimer une branche, deviennent alors des actions faciles et automatisées.

comments powered by Disqus