Workflow de branche de fonctionnalité Git

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

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, la commande 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 Data Center. Ensuite, vous pouvez ajouter des réviseurs et vous assurer que tout est OK avant le merge.

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 main. Faites un merge à partir de la pull request dans Bitbucket.

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 main. 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 main. 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 main locale a été synchronisée avec la branche main en amont. Ensuite, faites un merge de la branche de fonctionnalité dans mainet pushez à nouveau la branche main mise à jour vers le dépôt centralisé.

Les pull requests peuvent être simplifiées par des solutions de gestion du code source comme Bitbucket Cloud.

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 :

Une branche nommée marys-feature et basée sur main 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 :

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.

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é.

Lorsque Marie sera de retour de sa pause déjeuner, elle pourra achever de développer sa fonctionnalité. Avant de la merger dans main, 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é :

Ensuite, elle enregistre la pull request dans l'interface graphique Git pour faire un merge de marys-feature dans la branche main, et les membres de son équipe 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 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.

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.

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) :

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 main 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 main.

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.

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.