Flux de travail des branches de fonctionnalités de Git

L’idée centrale derrière le flux de travail des branches de fonctionnalités est que tout développement de fonctionnalités doit avoir lieu dans une branche dédiée au lieu de la branche master. Cette encapsulation permet à plusieurs développeurs de travailler facilement sur une fonctionnalité particulière sans perturber la base de code principale. Cela signifie également que la master branche ne contiendra jamais de code cassé, ce qui constitue un avantage considérable pour les environnements d’intégration continue.

Encapsuler le développement de fonctionnalités permet également de tirer parti des pull requests, qui sont un moyen d’initier des discussions autour d’une branche. Elles donnent aux autres développeurs la possibilité de signer une fonctionnalité avant qu’elle ne soit intégrée au projet officiel. Ou, si vous êtes bloqué au milieu d’une fonctionnalité, vous pouvez ouvrir une demande de retrait et demander des suggestions à vos collègues. Le fait est que les pull requests rendent incroyablement facile pour votre équipe de commenter le travail des autres.

Le flux de travail Git Feature Branch est un flux de travail composable qui peut être exploité par d’autres flux de travail Git de haut niveau. Nous avons discuté des autres flux de travail Git sur la page de présentation des flux de travail Git. Le Git Feature Branch Workflow est axé sur le modèle de branchement, ce qui signifie qu’il s’agit d’un cadre d’orientation pour la gestion et la création de branches. D’autres workflows sont plus axés sur les repo. Le Git Feature Branch Workflow peut être intégré à d’autres workflows. Les flux de travail Gitflow, et Git Forking utilisent traditionnellement un flux de travail Git Feature Branch en ce qui concerne leurs modèles de branchement.

Comment cela fonctionne

Le flux de travail Feature Branch suppose un dépôt central, et master représente l’historique officiel du projet. Au lieu de commiter directement sur leur master branche locale, les développeurs créent une nouvelle branche chaque fois qu’ils commencent à travailler sur une nouvelle fonctionnalité. Les branches de fonctionnalités doivent avoir des noms descriptifs, comme animated-menu-items ou issue-#1061. L’idée est de donner un objectif clair et très ciblé à chaque branche. Git ne fait pas de distinction technique entre la master branche et les branches de fonctionnalité, de sorte que les développeurs peuvent éditer, mettre en scène et livrer des changements dans une branche de fonctionnalité.

En outre, les branches de fonctionnalité peuvent (et doivent) être poussées vers le dépôt central. Cela permet de partager une fonctionnalité avec d’autres développeurs sans toucher au code officiel. Puisque master est la seule branche « spéciale », le stockage de plusieurs branches de fonctionnalité sur le dépôt central ne pose aucun problème. Bien sûr, c’est aussi un moyen pratique de sauvegarder les commits locaux de chacun. Ce qui suit est un parcours du cycle de vie d’une branche de fonctionnalité.

Démarrer avec la branche master

Toutes les branches de fonctionnalité sont créées à partir du dernier état du code d’un projet. Ce guide suppose que celui-ci est maintenu et mis à jour dans la master branche.

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

Ceci bascule le repo vers la branche master, tire les derniers commits et réinitialise la copie locale du repo de master pour correspondre à la dernière version.

Créer une nouvelle branche

Utiliser une branche distincte pour chaque fonctionnalité ou problème sur lequel vous travaillez. Après avoir créé une branche, vérifiez-la localement afin que toutes les modifications que vous faites soient sur cette branche.

git checkout -b new-feature

Cette vérification d’une branche appelée new-feature basée sur master, et le drapeau -b indique à Git de créer la branche si elle n’existe pas déjà.

Mettre à jour, ajouter, commettre et pousser les changements

Sur cette branche, modifiez, mettez en scène et commettez les changements de la manière habituelle, en construisant la fonctionnalité avec autant de commits que nécessaire. Travaillez sur la fonctionnalité et faites des commits comme vous le feriez à chaque fois que vous utilisez Git. Lorsque vous êtes prêt, poussez vos commits, mettant à jour la branche de fonctionnalité sur Bitbucket.

git status
git add <some-file>
git commit

Pousser la branche de fonctionnalité vers le distant

C’est une bonne idée de pousser la branche de fonctionnalité jusqu’au dépôt central. Cela sert de sauvegarde pratique, lors de la collaboration avec d’autres développeurs, cela leur donnerait accès à la visualisation des commits de la nouvelle branche.

git push -u origin new-feature

Cette commande pousse new-feature vers le dépôt central (origin), et le drapeau -u l’ajoute comme branche de suivi distante. Après avoir configuré la branche de suivi, git push peut être invoquée sans aucun paramètre pour pousser automatiquement la branche new-feature vers le dépôt central. Pour obtenir des commentaires sur la branche de nouvelle fonctionnalité, créez une demande de retrait dans une solution de gestion de référentiel comme Bitbucket Cloud ou Bitbucket Server. De là, vous pouvez ajouter des réviseurs et vous assurer que tout est bon à prendre avant de fusionner.

Résoudre les commentaires

Maintenant, les coéquipiers commentent et approuvent les commits poussés. Résolvez leurs commentaires localement, commitez et poussez les modifications suggérées vers Bitbucket. Vos mises à jour apparaissent dans la pull request.

Fusionner votre pull request

Avant de fusionner, vous pouvez avoir à résoudre des conflits de fusion si d’autres ont apporté des modifications au repo. Lorsque votre pull request est approuvée et sans conflit, vous pouvez ajouter votre code à la branche master. Fusionnez à partir de la demande de tirage dans Bitbucket.

Demandes de tirage

En plus d’isoler le développement des fonctionnalités, les branches permettent de discuter des changements via les demandes de tirage. Une fois que quelqu’un a terminé une fonctionnalité, il ne la fusionne pas immédiatement dans master. Au lieu de cela, il pousse la branche de la fonctionnalité vers le serveur central et dépose une demande de pull demandant de fusionner ses ajouts dans master. Cela donne aux autres développeurs l’occasion de réviser les modifications avant qu’elles ne fassent partie de la base de code principale.

La révision du code est un avantage majeur des pull requests, mais elles sont en fait conçues pour être un moyen générique de parler du code. Vous pouvez considérer les pull requests comme une discussion dédiée à une branche particulière. Cela signifie qu’elles peuvent également être utilisées beaucoup plus tôt dans le processus de développement. Par exemple, si un développeur a besoin d’aide pour une fonctionnalité particulière, il lui suffit de déposer une demande de retrait. Les parties intéressées seront notifiées automatiquement, et elles pourront voir la question juste à côté des commits concernés.

Une fois qu’une pull request est acceptée, l’acte réel de publication d’une fonctionnalité est à peu près le même que dans le flux de travail centralisé. Tout d’abord, vous devez vous assurer que votre master locale est synchronisée avec la master amont. Ensuite, vous fusionnez la branche de fonctionnalité dans master et repoussez la master mise à jour vers le dépôt central.

Les demandes pull peuvent être facilitées par des solutions de gestion de dépôts de produits comme Bitbucket Cloud ou Bitbucket Server. Consultez la documentation sur les demandes de retrait de Bitbucket Server pour obtenir un exemple.

Exemple

Voici un exemple du type de scénario dans lequel un workflow de branchement de fonctionnalités est utilisé. Le scénario est celui d’une équipe qui effectue une revue de code autour d’une nouvelle demande de tirage de fonctionnalité. C’est un exemple des nombreux objectifs pour lesquels ce modèle peut être utilisé.

Marie commence une nouvelle fonctionnalité

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

Cette commande extrait une branche appelée marys-feature basée sur master, et le drapeau -b indique à Git de créer la branche si elle n’existe pas déjà. Sur cette branche, Mary édite, met en scène et commet les changements de la manière habituelle, en construisant sa fonctionnalité avec autant de commits que nécessaire :

git status
git add <some-file>
git commit

Mary va déjeuner

Mary ajoute quelques commits à sa fonctionnalité au cours de la matinée. Avant de partir déjeuner, c’est une bonne idée de pousser sa branche de fonctionnalité vers le dépôt central. Cela sert de sauvegarde pratique, mais si Mary collaborait avec d’autres développeurs, cela leur donnerait également accès à ses commits initiaux.

git push -u origin marys-feature

Cette commande pousse marys-feature vers le dépôt central (origin), et le drapeau -u l’ajoute comme branche de suivi distante. Après avoir configuré la branche de suivi, Mary peut appeler git push sans aucun paramètre pour pousser sa fonctionnalité.

Mary termine sa fonctionnalité

Quand Mary revient de son déjeuner, elle termine sa fonctionnalité. Avant de la fusionner dans master, elle doit déposer une demande de pull pour faire savoir au reste de l’équipe qu’elle a terminé. Mais d’abord, elle doit s’assurer que le dépôt central a ses commits les plus récents :

git push

Puis, elle dépose la pull request dans son GUI Git demandant de fusionner marys-feature dans master, et les membres de l’équipe seront notifiés automatiquement. Ce qui est génial avec les demandes de pull, c’est qu’elles affichent des commentaires juste à côté de leurs commits associés, ce qui permet de poser facilement des questions sur des changesets spécifiques.

Bill reçoit la demande de pull

Bill reçoit la demande de tirage et jette un coup d’œil à marys-feature. Il décide d’apporter quelques modifications avant de l’intégrer au projet officiel, et lui et Mary ont quelques échanges via la demande de tirage.

Mary apporte les modifications

Pour apporter les modifications, Mary utilise exactement le même processus que celui qu’elle a utilisé pour créer la première itération de sa fonctionnalité. Elle édite, met en scène, commite et pousse les mises à jour vers le dépôt central. Toute son activité apparaît dans la demande de retrait, et Bill peut toujours faire des commentaires en cours de route.

S’il le souhaitait, Bill pourrait retirer marys-feature dans son dépôt local et travailler dessus seul. Tous les commits qu’il a ajoutés apparaîtraient également dans la demande de pull.

Mary publie sa fonctionnalité

Une fois que Bill est prêt à accepter la pull request, quelqu’un doit fusionner la fonctionnalité dans le projet stable (cela peut être fait par Bill ou Mary):

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

Ce processus aboutit souvent à un commit de fusion. Certains développeurs aiment cela car c’est comme une jonction symbolique de la fonctionnalité avec le reste de la base de code. Mais, si vous êtes partisan d’une histoire linéaire, il est possible de rebaser la fonctionnalité sur la pointe de master avant d’exécuter la fusion, ce qui entraîne une fusion rapide.

Certaines interfaces graphiques automatiseront le processus d’acceptation de la pull request en exécutant toutes ces commandes juste en cliquant sur un bouton « Accepter ». Si la vôtre ne le fait pas, elle devrait au moins être capable de fermer automatiquement la pull request lorsque la branche de fonctionnalité est fusionnée dans master.

Pendant ce temps, John fait exactement la même chose

Pendant que Mary et Bill travaillent sur marys-feature et en discutent dans sa pull request, John fait exactement la même chose avec sa propre branche de fonctionnalité. En isolant les fonctionnalités dans des branches distinctes, tout le monde peut travailler indépendamment, tout en restant trivial pour partager les modifications avec d’autres développeurs lorsque cela est nécessaire.

Résumé

Dans ce document, nous avons abordé le workflow Git Feature Branch. Ce workflow permet d’organiser et de suivre les branches qui se concentrent sur les ensembles de fonctionnalités du domaine métier. D’autres flux de travail Git, comme le flux de bifurcation Git Forking et le flux de travail Gitflow, sont axés sur le repo et peuvent s’appuyer sur le flux de travail Git Feature Branch pour gérer leurs modèles de branchement. Ce document présente un exemple de code de haut niveau et un exemple fictif pour l’implémentation du Git Feature Branch Workflow. Certaines associations clés à faire avec le Feature Branch Workflow sont:

• focalisé sur les modèles de branchement
• peut être exploité par d’autres workflows orientés repo
• promouvoir la collaboration avec les membres de l’équipe par le biais de pull requests et de revues de fusion

Utiliser git rebase pendant les étapes de révision et de fusion d’une branche de fonctionnalité créera l’application d’un historique Git cohérent des fusions de fonctionnalités. Un modèle de branche de fonctionnalité est un excellent outil pour promouvoir la collaboration au sein d’un environnement d’équipe.

Allez un clic plus loin dans les workflows Git en lisant notre tutoriel complet du Workflow Gitflow.