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 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 master ne contiendra jamais de code bogué : 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 signer 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 branching, 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 Git Forking utilisent généralement un workflow de branche de fonctionnalité pour leurs modèles de branching.

Fonctionnement


Le workflow de branche de fonctionnalité suppose l'existence d'un dépôt centralisé, et la branche master représente toujours l'historique officiel du projet. Au lieu de faire des commits directement sur leur branche master locale, les développeurs créent une nouvelle 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 master et les branches de fonctionnalité. Ainsi, les développeurs peuvent éditer 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 de l'état du code d'un projet le plus récent. Ce guide suppose la conservation et la mise à jour dans la branche master.

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

Cela bascule le dépôt vers la branche master, effectue un pull des derniers commits, puis réinitialise la copie locale de la branche 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 la création d'une branche, extrayez-la en local pour que tous vos changements soient réalisés sur cette branche.

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 éditer, 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 avec Git. Lorsque vous êtes prêt, pushez vos commits en mettant à jour la branche de fonctionnalité sur Bitbucket.

git status
git add <fichier>
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é 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 master. Faites un merge à partir de la pull request dans Bitbucket.

Demandes d'extraction

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 du 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 master locale a été synchronisée avec la branche master en amont. Ensuite, faites un merge de la branche de fonctionnalité dans master et pushez à nouveau la branche 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 avec la commande suivante :

git checkout -b marys-feature 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 <fichier>
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é (d'origine), 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 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 process 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 faire un merge de 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 rebaser la fonctionnalité sur la pointe de la branche 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.

Summary


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 Git Forking 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 certaines des principales associations à effectuer avec le workflow de branche de fonctionnalité :

  • zoom sur les modèles de création de branches
  • peut être exploité par d'autres workflows axés sur le dépôt ;
  • encourage la collaboration 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émarrez maintenant