IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Tutoriel pour écraser une branche par une autre avec GIT

Image non disponible

Cet article s'intéresse à expliquer comment écraser une branche par une autre avec l'outil de gestion de source GIT.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum. 2 commentaires Donner une note à l´article (5).

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Dans le cycle de vie d'une application, il arrive parfois qu'une branche prenne le pas sur une autre et qu'il soit nécessaire d'écraser la seconde par la première. Prenons l'exemple d'une application où, par convention, le master (ou le trunk sous SVN) est considéré comme la branche de développement (axée vers le futur) et que l'utilisation du système de branches soit habituellement consacrée aux branches de maintenance. Dans certaines circonstances (ex. : nouveaux développements à commencer pour la version N+2, migration technique à réaliser…), une branche peut prendre le dessus sur le master. Afin de retrouver la convention d'origine, une recopie de la branche sur le master va, à terme, être nécessaire. Que ce soit avec Git ou git-svn, nous allons voir comment Git peut nous y aider en quelques lignes de commande.

II. Mise en scène

L'historique de commits ci-dessous illustre les explications qui suivront :

Image non disponible

Cet historique des commits commence par la branche master sur laquelle les fonctionnalités A et B ont été commitées. La branche « maBranche » est alors créée à partir du commit de la fonctionnalité B. Un premier merge no fast-forward est créé pour récupérer la fonctionnalité E de master dans « maBranche » : le commit de merge « Merge branch ‘master' into maBranche » est créé.

À partir de là, les nouvelles fonctionnalités F, G et H sont développées sur « maBranche ». Ne pouvant attendre la fin des développements de la fonctionnalité G qui résoudrait proprement le problème rencontré par les utilisateurs, est créé sur le master un contournement permettant de pallier le problème temporairement. Ce Hotfix est déployé en production. N'ayant aucun intérêt dans les prochaines versions de l'application, ce Hotfix ne doit être en aucun cas mergé sur « maBranche ». Une fois les développements de la fonctionnalité H terminés et déployés en production, l'équipe décide de faire revenir sur le master les développements de « maBranche ».

Les deux derniers commits de l'historique mettent en œuvre cette opération.

III. Commandes

Voici les quatre lignes de commandes à exécuter pour réaliser cet écrasement de branche.

  1. Se placer sur la branche à conserver git checkout maBranche.
  2. Demander une fusion avec la stratégie ours (attention, cela est différent d'un merge avec stratégie récursive et l'option ours) qui va uniquement conserver le contenu de la branche actuelle. En effet, l'option -s ours indique à Git de fusionner la branche source dans la branche cible, mais sans aucunement modifier la branche cible. Cette stratégie est habituellement utilisée pour ne pas reporter un commit d'une branche de maintenance sur le master. git merge -s ours master -m "Merge avec stratégie ours".
  3. Repasser sur la branche master git checkout master.
  4. Demander une fusion de la branche « maBranche » vers le master tout en conservant deux branches distinctes (un fast-forward aurait été réalisé puisque le dernier commit n'est autre que notre fusion de la commande n° 2). git merge --no-ff maBranche.

Sortie console sur notre exemple de la commande Git n° 4 :

Image non disponible

Comme attendu, le fichier Hotfix.txt ayant été ajouté lors du commit Hotfix est supprimé du master. Si, dans un autre exemple, le commit Hotfix avait modifié une ligne du fichier FeatureE.txt, un revers de cette modification aurait alors été effectué.

IV. Conclusion

Cet article explique comment Git permet d'écraser le contenu de la branche A par une branche B lorsque la branche B a pris le pas sur la branche A et qu'aucune des modifications présentent dans la branche A n'a besoin d'être conservée (tout a été préalablement fusionné, reporté par cherry-pick, copié à la main ou volontairement ignoré, car à ne pas reporter).

Cerise sur le gâteau : ces opérations sont applicables entre deux branches SVN par le biais du bridge git-svn.

V. Remerciements

Cet article a été publié avec l'aimable autorisation d'Antoine Rey. L'article original (Ecrase une branche par une autre avec GIT) a été rédigé par Antoine Rey.

Nous tenons à remercier milkoseck pour sa relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2014 Antoine Rey. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.