Git, un modèle de branches efficace (2/2)

La gestion des branches dans Subversion ou CVS n’est pas suffisamment simple et rapide pour encourager les développeurs à s’y frotter, voire les en dissuade :

« Quoi ? Une branche ? Non, trop compliqué de gérer les conflits… on reste dans le trunk »

Partant de ce constat, tous les développeurs restent dans « le trunk », avec tous les inconvénients que cela peut avoir :

  • Mr X commit en deux parties son code, rendant l’espace de quelques instants l’intégralité du projet instable
  • Mr X commit une fonctionnalité en cours de développement, rendant le projet impossible à livrer tant qu’il n’aura pas terminé sa fonctionnalité
  • Mr Y commit lui aussi une fonctionnalité en cours de développement, rendant le projet encore moins possible à livrer tant qu’il n’aura pas terminé sa fonctionnalité.

Et nous nous retrouvons avec un trunk complètement instable ou un « hotfix » devient impossible à réaliser.

C’est là que Git intervient en proposant une gestion des branches simple et rapide.

Git, peux-tu faire quelque chose pour nous ?

Oui, il le peut, en nous permettant de respecter ce schéma facilement:

Modèle de branches avec Git
(Image et proposition de modèle issus de http://nvie.com/posts/a-successful-git-branching-model/) par Vincent Driessen sous license Creative Commons.

Le master

Master et Develop

Le master correspond à la version de production : Personne ne travaille directement sur la production mais il est possible, en permanence, de créer une branche à partir du master (pour des corrections de bug urgents par exemple).

La branche develop

La branche develop correspond à la dernière version de développement stable. Develop est la branche d’intégration, c’est à partir de cette dernière que la prochaine version de production sera créée.

Aucune fonctionnalité en cours de développement n’est envoyée directement à develop, seules les fonctionnalités terminées y sont envoyées.

Tout le monde devrait pouvoir, à moindre risque, se reposer sur la branche develop.


Branche de nouvelle fonctionnalité (feature)

Branche réalisée à partir de : develop
La branche sera réintroduite dans : develop

Lorsque nous voulons créer une nouvelle fonctionnalité dans notre projet, nous allons créer une branche portant le nom de cette fonctionnalité en partant de la branche develop (qui est la branche la plus récente).

Cette branche restera ouverte tant que la fonctionnalité ne sera pas terminée.

Création de la branche

$ git checkout -b nom_fonctionnalite develop
Switched to a new branch "nom_fonctionnalite"

Si l’on souhaite que la branche soit connue de tous (qu’elle soit présente sur le dépôt d’origine), il est possible de le faire.

Envoi de la branche sur l’origine

$ git push origin nom_fonctionnalite

Lorsque la fonctionnalité est terminée, nous pouvons l’inclure dans la branche develop.

Incorporation de la branche dans develop

#on va sur la branche develop pour y effectuer l'opération de merge
$ git checkout develop

#On demande le merge de la fonctionnalite dans develop
$ git merge nom_fonctionnalite

#On peut supprimer la branche nom_fonctionnalite devenue inutile
$ git branch -d nom_fonctionnalite

#On demande l'envois des modifications sur le dépôt d'origine
$ git push origin develop

Créer une nouvelle version (release)

Branche réalisée à partir de : develop
La branche sera réintroduite dans : master et develop

Lorsqu’un ensemble de fonctionnalité est terminé il est temps de livrer en production. La plus part du temps nous devons passer par une phase de recette (utilisateurs ou technique) : Cette recette sera réalisée sur cette branche.

Nous pourrons lors de cette recette corriger des bugs mineurs, peaufiner quelques détails d’interface ou simplement mettre à jour les informations de version (fichiers README, numéro de version, …).

Pendant cette recette, il sera possible aux autres développeurs de continuer de travailler sur les fonctionnalités pour les versions suivantes (dans les branches de fonctionnalités).

Créer la branche de nouvelle version

#creation avec la convention release-numversion
$ git checkout -b release-x.y develop

#mettez à jour votre README avec le numéro de version
$ git add README
$ git commit -m "Version x.y"

Une fois la recette validée par les utilisateurs et tous les correctifs mineurs intégrés, réintégrez la branche dans le master

Intégration de la version dans le master

#on se positionne sur le master pour y intégrer la branche
$ git checkout master

#Intégration de la branche avec l'option --no-ff pour tracer la fusion
$ git merge --no-ff release-x.y

#On tag la version
$ git tag -a x.y

# On envoie le contenu du master sur le dépôt d'origine
# L'option --tags indique à git que l'on souhaite 
# envoyer l'information de tag
$ git push --tags

Bien sûr, il ne faut pas oublier de réintégrer dans la version develop les changements intervenus lors de la recette.

Intégration de la version dans la branche develop

$ git checkout develop
$ git merge --no-ff release-x.y

La branche de version n’a plus lieu d’être

Supression de la branche de version

$ git branch -d release-x.y

Corrections de bugs en production

Branche de correctif en production
Branche réalisée à partir de : master
La branche sera réintroduite dans : master et develop

Lorsqu’un bug critique est détecté en production et que sa correction est urgente nous aurons recours à la branche de correction à chaud.

Cette branche est réalisée à partir du master, qui rappelons le est la copie conforme de la production.

Cette branche permet d’isoler le correctif de production du cycle de développement normal du produit (réalisé dans la branche develop).

Une fois le correctif appliqué, il sera intégré au master et à la branche develop.


Création de la branche correctif (hotfix)

#création de la branche hotfix à partir du master
$ git checkout -b hotfix-x.y.z master

#Mise à jour du numéro de version
# ... édition du readme & autres 
# ... (processus identique à celui de la release)

# Validation de la mise à jour de version
$ git commit -a -m "Correctif x.y.z"

Le travail de correction est effectué…

Envois des modifications

$ git commit -m "Correctif du problème blabla signalé par Bob"

Et le travail d’introduction classique aux branches commence :

Intégration du Hotfix en production

$ git checkout master
$ git merge --no-ff hotfix-x.y.z
$ git tag -a x.y.z
$ git push --tags

Intégration du Hotfix dans la branche develop

$ git checkout develop
$ git merge --no-ff hotfix-x.y.z

Supression de la branche hotfix devenue inutile

$ git branch -d hotfix-1.2.1

Conclusions

La puissance de Git réside dans les nouvelles possibilités qui nous sont offertes.
Migrer vers Git implique de changer ses méthodes de travail pour en bénéficier.

Vous souhaitez adopter ce modèle de branche et souhaitez placarder un résumé des commandes utiles sur votre mur ?

Téléchargez le résumé de l’article au format PDF !

  1. Personnellement j’ai adopté Git pour la plupart de mes projets depuis un bon moment, et je découvre encore des trucs…
    Genre y’a un mois, je découvre git bisect, un truc de tueur à gage pour débusquer un bug

    Et je parle pas de ce que propose les paquets sous Linux, comme gitk pour voir les branches, ou encore le fabuleux outil en console « tig »

    et j’en passe, git gc, git fsck … on sent bien que ce sont des geeks qui ont codé ce truc !

  2. Introduction à GIT (1/2) | Gerald's Blog - pingback on 3 août 2011 at 12 h 24 min
  3. Git est également très bon pour bosser sur des versions dérivées de projets : récupérer les dernières modifications de la version originale (upstream) et reverser des patchs, tout en conservant nos propres modifs dans un coin.

  4. pareil pour mes projets perso avec mercurial…
    Ne plus avoir de .svn qui se cachent partout, pouvoir commiter en mode « offline » avec en prime des sites genre bitbucket…

    Tout ça parait tellement naturel quand on y a gouté que revenir à svn pour certain projet est très douloureux.

    Ravi de voir que tu te remets à écrire.

  5. > Ravi de voir que tu te remets à écrire.
    @webozor Merci, j’avoue que j’écrit un peu par vagues… en fonction des envies et disponibilités.

    @tous merci pour les compléments d’informations et retours supplémentaires.

  6. merci pour cet article :smile:

  7. C’est le modèle Gitflow ça, il existe un paquet qui permet de travailler sur les branches en une seule commande ;)

  8. Merci pour cet article très instructif. Je suis passé sur Git pour tous mes projets perso depuis environ un an, mais comme Adirelle, j’en apprends encore régulièrement !

  9. Merci pour cet article complet, succinct et clair.

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackbacks and Pingbacks: