Workflow de branche de fonctionnalité Git

 

Le principe de base du workflow de branche par fonctionnalité est que chaque fonctionnalité est développée dans une branche prévue à cet effet plutôt que dans la branche principale (master). Grâce à cette encapsulation, plusieurs développeurs peuvent travailler aisément sur une même fonctionnalité sans modifier la base de code principale. Cela signifie également que la branche principale (master) ne contiendra jamais de code bugué : un avantage non négligeable pour les environnements d'intégration continue.

L'intégration du développement de fonctionnalités permet également de tirer parti des pull requests, qui sont utilisées pour initier des discussions sur une branche. Les développeurs peuvent ainsi valider une fonctionnalité avant qu'elle ne soit intégrée au projet officiel. Si vous rencontrez un problème alors que vous développez une fonctionnalité, vous pouvez ouvrir une pull request pour demander des suggestions à vos collègues. Grâce aux pull requests, il est extrêmement facile pour votre équipe de donner du feedback sur le travail effectué.

Le workflow de branche de fonctionnalité Git est un workflow composable, qui peut être exploité par d'autres workflows Git de haut niveau. Nous avons discuté d'autres workflows Git sur la page d'aperçu du workflow Git. Le workflow de branche de fonctionnalité Git est axé sur le modèle de création de branche, autrement dit, il s'agit d'un framework pour la gestion et la création de branches. D'autres workflows sont davantage axés sur les dépôts. Le workflow de branche de fonctionnalité Git peut être intégré à d'autres workflows. Les workflows Gitflow et de fork Git utilisent généralement un workflow de branche de fonctionnalité pour leurs modèles de création de branche.

Fonctionnement


Le workflow de branche de fonctionnalité suppose l'existence d'un dépôt centralisé, et la branche principale (master) représente toujours l'historique officiel du projet. Au lieu de faire des commits directement sur leur branche principale (master) locale, les développeurs créent une branche dès qu'ils commencent à travailler sur une nouvelle fonctionnalité. Les branches de fonctionnalité doivent avoir des noms descriptifs, comme « animated-menu-items » ou « issue-#1061 ». L'idée est que chaque branche doit être associée à un objectif clair et précis. D'un point de vue technique, Git n'établit aucune distinction entre la branche principale (master) et les branches de fonctionnalité. Ainsi, les développeurs peuvent modifier les branches de fonctionnalité et les stager, puis commiter les changements.
 

De plus, les branches de fonctionnalité peuvent (et doivent) être pushées vers le dépôt centralisé. Cela permet à plusieurs développeurs de travailler sur une même fonctionnalité sans modifier le code officiel. Comme master constitue la seule branche « spéciale », il est tout à fait possible de stocker plusieurs branches de fonctionnalité dans le dépôt centralisé. Bien sûr, c'est aussi là un moyen simple et efficace de sauvegarder les commits locaux de tous les développeurs. Voici un aperçu du cycle de vie d'une branche de fonctionnalité.

Commencez par la branche master.

Toutes les branches de fonctionnalité sont créées à partir du code le plus récent d'un projet. Ce guide suppose la conservation et la mise à jour dans la branche principale (master).

git checkout master
git fetch origin
git reset --hard origin/master

Cela bascule le dépôt vers la branche principale (master), effectue un pull des derniers commits, puis réinitialise la copie locale de la branche principale (master) du dépôt pour qu'elle corresponde à la version la plus récente.

Créer une nouvelle branche

Utilisez une branche distincte pour les fonctionnalités ou tickets sur lesquels vous travaillez. Après sa création, extrayez une branche en local pour que tous vos changements soient réalisés sur celle-ci.

git checkout -b new-feature

Une branche nommée new-feature et basée sur master sera extraite, et le flag -b indiquera à Git de créer la branche si elle n'existe pas encore.

Mettez à jour, ajoutez, commitez et pushez des changements

Dans cette branche, vous pouvez modifier, stager et commiter des changements de la manière habituelle. Vous développerez ensuite la fonctionnalité en effectuant autant de commits que nécessaire. Travaillez sur une fonctionnalité et effectuez des commits quand vous le souhaitez grâce à Git. Lorsque vous êtes prêt, pushez vos commits en mettant à jour la branche de fonctionnalité sur Bitbucket.

git status
git add <some-file>
git commit

Pushez la branche de fonctionnalité vers le dépôt distant

Il est judicieux de pusher la branche de fonctionnalité vers le dépôt centralisé. Il s'agit d'une méthode de sauvegarde efficace qui, lorsque vous collaborez avec d'autres développeurs, leur permet de consulter les commits dans la nouvelle branche.

git push -u origin new-feature

Cette commande pushe new-feature vers le dépôt centralisé (origin), et le flag -u l'ajoute au même titre qu'une branche de suivi distante. Une fois la branche de suivi configurée, git push peut être appelée sans paramètre pour pusher automatiquement la nouvelle branche de fonctionnalité vers le dépôt centralisé. Pour obtenir du feedback sur la nouvelle branche de fonctionnalité, créez une pull request dans une solution de gestion de dépôt comme Bitbucket Cloud ou Bitbucket Server. Ensuite, vous pouvez ajouter des réviseurs et vous assurer que tout est bon avant le merge.

Résolvez du feedback

Désormais, les membres de l'équipe commentent et approuvent les commits pushés. Résolvez les commentaires en local, commitez, puis faites un push des changements suggérés vers Bitbucket. Vos mises à jour apparaissent dans la pull request.

Mergez votre pull request

Avant de faire un merge, vous devrez peut-être résoudre des conflits de merge si d'autres ont apporté des changements au dépôt. Une fois votre pull request approuvée et exempte de conflit, vous pouvez ajouter votre code à la branche principale (master). Faites un merge à partir de la pull request dans Bitbucket.

Pull requests

Les branches permettent non seulement de développer des fonctionnalités de manière isolée, mais aussi de discuter des changements grâce aux pull requests. Une fois qu'un développeur a terminé de travailler sur une fonctionnalité, il ne fait pas directement un merge dans master. Au lieu de cela, il « pushe » la branche de fonctionnalité vers le serveur central et fait une pull request pour demander de merger ses ajouts dans master. Les autres développeurs ont ainsi la possibilité d'examiner les changements avant que ceux-ci ne soient intégrés à la base de code principale.

La revue de code est un avantage majeur des pull requests. En réalité, celles-ci sont conçues pour offrir un moyen générique de parler du code. On peut considérer les pull requests comme un espace de discussion dédié à une branche particulière. Elles peuvent donc aussi être utilisées beaucoup plus tôt dans le process de développement. Par exemple, si un développeur a besoin d'aide pour une fonctionnalité spécifique, il lui suffit de faire une pull request. Les parties intéressées seront automatiquement informées et elles pourront voir la question en regard des commits en question.

Lorsqu'une pull request est acceptée, la publication d'une fonctionnalité s'effectue à peu près de la même manière que dans le workflow centralisé. Vous devez d'abord vous assurer que votre branche principale (master) locale a été synchronisée avec la branche principale (master) en amont. Ensuite, faites un merge de la branche de fonctionnalité dans master et pushez à nouveau la branche principale (master) mise à jour vers le dépôt centralisé.

Utilisez des solutions de gestion des dépôts de produit, comme Bitbucket Cloud ou Bitbucket Server, pour faciliter les pull requests. Consultez par exemple la documentation de Bitbucket Server sur les pull requests.

Exemple

Voici un exemple de type de scénario dans lequel un workflow de branche de fonctionnalité est utilisé. Le scénario est le suivant : une équipe effectue une revue du code relatif à la pull request d'une nouvelle fonctionnalité. Ce n'est qu'un exemple parmi tant d'autres de l'utilité de ce modèle.

Marie commence une nouvelle fonctionnalité

Workflow de branche de fonctionnalité : commiter les changements

Avant de commencer à développer une fonctionnalité, Marie a besoin d'une branche isolée sur laquelle travailler. Elle peut demander une nouvelle branche grâce à la commande suivante :

git checkout -b feature-marie master

Une branche nommée marys-feature et basée sur master sera extraite, et le flag -b indiquera à Git de créer la branche si elle n'existe pas encore. Dans cette branche, Marie pourra éditer, stager et commiter des changements de la manière habituelle. Elle développera ensuite sa fonctionnalité en effectuant autant de commits que nécessaire :

git status
git add <some-file>
git commit

Marie va déjeuner

Workflow de branche de fonctionnalité : git push

Marie ajoute des commits à sa fonctionnalité au cours de la matinée. Avant de partir en pause déjeuner, il est judicieux de pusher sa branche de fonctionnalité vers le dépôt centralisé. C'est un moyen pratique pour effectuer une sauvegarde, mais si Marie collaborait avec d'autres développeurs, ceux-ci pourraient également accéder à ses commits initiaux.

git push -u origin marys-feature

Cette commande pushe marys-feature vers le dépôt centralisé (origin), et le flag -u l'ajoute au même titre qu'une branche de suivi distante. Une fois que la branche de suivi sera créée, Marie pourra exécuter git push sans paramètres pour pusher sa fonctionnalité.

Marie termine sa fonctionnalité

Workflow de branche de fonctionnalité : git push

Lorsque Marie sera de retour de sa pause déjeuner, elle pourra achever de développer sa fonctionnalité. Avant de la merger dans master, elle devra faire une pull request pour prévenir le reste de son équipe qu'elle a terminé. Cependant, elle doit d'abord s'assurer que ses commits les plus récents ont été intégrés au dépôt centralisé :

git push

Ensuite, elle enregistre la pull request dans l'interface graphique Git pour faire un merge de marys-feature dans la branche principale (master), et ses collègues en seront automatiquement informés. L'un des grands avantages des pull requests est qu'elles affichent les commentaires en regard des commits qui leur sont associés. Il est donc plus facile de poser des questions concernant des ensembles de changements spécifiques.

Guillaume reçoit la pull request

Workflow de branche de fonctionnalité : Revue d'une pull request

Guillaume reçoit la pull request et examine marys-feature. Il décide d'y apporter quelques changements avant de l'intégrer au projet officiel. Marie et lui échangent alors via la pull request.

Marie apporte les changements

Workflow de branche de fonctionnalité : Révisions de pull requests

Pour apporter les changements, Marie utilise le même processus que celui utilisé pour créer la première itération de sa fonctionnalité. Elle édite, stage, commite et pushe les mises à jour vers le dépôt centralisé. Toutes ses activités apparaissent dans la pull request, et Guillaume peut ajouter des commentaires à tout moment.

S'il le souhaitait, Guillaume pourrait placer marys-feature dans son dépôt local et travailler sur cette fonctionnalité tout seul. Tous les commits qu'il ajouterait apparaîtraient également dans la pull request.

Marie publie sa fonctionnalité

Workflow de branche de fonctionnalité : Faire un merge d'une branche de fonctionnalité

Lorsque Guillaume est prêt à accepter la pull request, un utilisateur doit merger la fonctionnalité dans le projet stable (cette opération peut être exécutée par Marie ou Guillaume lui-même) :

git checkout master
git pull
git pull origin marys-feature
git push

Ce processus génère souvent un commit de merge. Certains développeurs en sont friands, car il permet d'établir un lien symbolique entre la fonctionnalité et le reste de la base de code. Cependant, si vous avez plutôt un faible pour les historiques linéaires, il est possible de faire un rebase de la fonctionnalité sur la pointe de la branche principale (master) avant de faire le merge, lequel se traduira par un fast-forward merge.

Certains outils de l'interface graphique automatisent le processus d'acceptation de la pull request en lançant toutes ces commandes au moment où vous appuyez sur le bouton « Accepter ». Si votre interface graphique ne le fait pas, elle doit au moins pouvoir fermer la pull request automatiquement lorsque la branche de fonctionnalité est mergée dans master.

Dans le même temps, Jean fait exactement la même chose.

Pendant que Marie et Guillaume travaillent sur marys-feature et en discutent via la pull request de Marie, Jean fait de même avec sa propre branche de fonctionnalité. En isolant les fonctionnalités dans des branches séparées, tous les développeurs peuvent travailler chacun de leur côté. Évidemment, ils s'informent toujours des changements si nécessaire.

Résumé


Dans ce document, nous avons discuté du workflow de branche de fonctionnalité Git. Ce workflow aide à organiser et à suivre les branches axées sur des ensembles de fonctionnalités de domaine d'activité. D'autres workflows Git, comme le workflow de fork Git et Gitflow sont axés sur le dépôt, et peuvent exploiter le workflow de branche de fonctionnalité Git pour gérer leurs modèles de branche. Ce document présente un exemple de code de haut niveau et un exemple fictif d'implémentation du workflow de branche de fonctionnalité Git. Voici quelques-unes des associations clés à faire avec le workflow de branche de fonctionnalité :

  • Zoom sur les modèles de création de branches
  • Exploitation possible par d'autres workflows axés sur le dépôt
  • Collaboration encouragée avec les membres de l'équipe par le biais de pull requests et de revues de merge

L'utilisation de git rebase pendant les étapes de revue et de merge d'une branche de fonctionnalité crée un historique Git cohérent des merges de fonctionnalités. Un modèle de branche de fonctionnalité est un excellent outil pour promouvoir la collaboration au sein d'un environnement collaboratif.

Allez plus loin dans les workflows Git en lisant notre tutoriel complet sur le workflow Gitflow.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrer maintenant