Comment pousser un correctif sur plusieurs branches

Vous êtes développeur dans une petite agence web et vous intervenez sur un projet déjà en production. Ce projet est versionné sous git et vous avez donc 2 branches principales :

• La branche master servant de recette pour le client
• La branche prod pour le site final

Et là vous prenez connaissance d'un bug qui s'est produit en prod. Misère, vite vite vite il faut résoudre ce bug sinon ce sera la foire à la saucisse chez le client et ça ferait mauvais genre. Ni une ni deux vous vous précipitez dans la branche et commencez à regarder le fichier fautif ... STOP ! On se calme, on reprend ses esprits et on lit la suite :)

Avant tout développement pour résoudre le bug, il faut nécessairement bien mettre à jour ses branches locales qui suivent le dépôt distant. C'est essentiel pour s'assurer un minimum de conflit lorsque notre correctif viendra se merger dans les branches. Cela consiste en ces quelques commandes git, (nb: master étant la branche dont vous souhaitez rappatrier les commits). Répéter l'opération autant de fois que nécessaire pour toutes les branches qui vont devoir accueillir le correctif.

La branche de production doit toujours être stable, toujours. C'est la raison pour laquelle on développera le correctif à partir du code de la production directement. C'est d'autant plus vrai si le bug a été constaté sur le site en production.

On peut alors passer à la résolution du bug. Donc pour commencer, on se place toujours dans la branche sur laquelle s'appuie la production et on crée une nouvelle branche locale, appelons-là hotfix. On se place alors dans cette nouvelle branche pour développer le correctif.

En terme d'arbre des commits, prod s'arrête sur le commit A1 donc la branche hotfix commence sur ce même commit.

Bon, notre bug est résolu, vous avez testé sur votre machine et tout fonctionne. On est bien content mais maintenant il faut déployer le correctif sur les différentes branches concernées !

Donc on commit nos modifications. On a donc un commit référencé en A2 et notre branche hotfix diverge d'avec la prod.

A1 <-- prod

    \_ A2 <- hotfix

On veut maintenant rappatrier ce commit dans la branche prod et la branche master.

Afin de préserver l'arbre des commits et sa lisibilité pour tous les intervenants ainsi que faire la distinction entre ce qui relève des nouveaux développements des résolutions de bugs, on utilisera l'option --no-ff pour désactiver l'auto fast-forward.

La plupart du temps lorsque vous aurez à merger votre correctif référencé par le commit A2, personne ne sera intervenu sur la branche prod donc en mergeant votre commit, git fera automatiquement un "fast-forward". Autrement dit, il ajoutera votre commit A2 à la suite du commit A1 et avance le pointeur sur ce commit A2. L'arbre des commits sera plat, comme ci-dessous.

A1 ___ A2 <-- prod

On ne voit donc pas bien qu'un nouveau commit sensé résoudre un bug a été poussé. Pour cette raison on utilisera l'option --no-ff qui obligera git à créer un commit de merge. Donnant un arbre de commit comme suit:

A1____________A3 <-- prod

    \____ A2____ / <-- hotfix 

• A1 est le dernier commit sur la branche prod
• A2 est votre commit de correctif
• A3 est le commit de merge produit par git avec l'option no-ff

Maintenant on voit très nettement qu'un nouveau commit a été mergé et qu'il s'agit d'un simple correctif. Donc si problème il y a sur la résolution du bug, on retrouve plus facilement le commit fautif et on sait donc sur qui taper ! mais en toute bienveillance évidemment, c'est important.

Une fois le commit mergé dans la branche prod, on peut répéter l'opération pour toutes les autres branches nécessaires, la branche de recette (master) par exemple.

Lors de cette opération, la recette étant bien souvent plus avancée dans le code que la production, on peut rencontrer des conflits de code. Lorsqu'on maîtrise bien la résolution des conflits et le code concerné par ces conflits, on peut s'aventurer à résoudre les conflits.

Dans la pratique, quand on a des conflits lors d'un merge d'un correctif en recette, cela concerne des fichiers qui n'ont aucun rapport avec les fichiers modifiés de votre commit de hotfix. Si c'est le cas, le plus simple reste de conserver la version de la branche où vous mergez votre commit. Vraisemblablement comme il s'agit d'une branche en avance de la production, le code s'y trouvant correspond à des nouveaux développements ou modifications fonctionnelles. Donc il ne faut surtout pas y toucher, au risque de tout perdre.

Si cela concerne des fichiers présents dans votre commit, c'est déjà un poil plus compliqué mais c'est gérable si l'on connait bien le code.

Dans tous les cas, si l'on est un peu frileux vis à vis de git, qu'on ne maîtrise pas encore bien toutes les commandes, je vous conseillerais toujours d'avorter votre merge et de résoudre le bug directement depuis le code de la branche en question. Cela évite d'amener des régressions dans le code et de faire hurler vos collègues parce que 2 semaines de boulot ont été perdu -même si ce n'est pas tout à fait vrai-

Pour revenir en arrière et s'éviter les foudres des copains :