Ce document a été rédigé dans le but d'unifier les règles GitFlow internes à l'entreprise. Cette méthode n'introduit pas un GitFlow pur, car c'est un mélange de GitFlow et de GitLab Flow, avec les meilleures pratiques de l'entreprise mises en place depuis de nombreuses années. Elle permet de conserver un historique propre et lisible du dépôt et de mieux contrôler les changements et les modifications. projet les cycles de vie.

Initialisation du référentiel

Après avoir initialisé le référentiel, créez un fichier développer et maître si elle n'est pas incluse par défaut. La branche develop doit contenir une branche development code qui est un miroir de la branche master avec les nouvelles fonctionnalités incluses. La branche master contient une version stable du code, représentant l'état de production. Ces deux branches ont une durée de vie infinie et, en comparaison avec les autres branches de Git Flow, ne seront jamais supprimées. Mettre en place des règles de protection appropriées : exige que les demandes de pull soient examinées avant d'être fusionnées et exige que les contrôles d'état soient réussis avant la fusion. Vous pouvez également envisager de n'autoriser que les équipe pour fusionner les modifications avec le master.

$ git init
$ git commit --allow-empty -m "Initial commit" (livraison initiale)
$ git checkout -b develop master

NOTE : Il est parfois important pour le projet d'ajouter plus de branches infinies, par exemple pour représenter les environnements disponibles. Toutefois, il convient de respecter la "règle des deux" dans la mesure du possible.

Branches de fonctionnalités

Lorsque vous commencez à travailler avec une fonctionnalité donnée, assurez-vous d'abord que vous avez votre développer synchronisée.

 $ git checkout develop && git pull --rebase

Ensuite, faites un checkout vers votre branche de fonctionnalités. Nommez-la selon le schéma donné : caractéristique-JIRA-TASK-ID ou vous pouvez également enfreindre cette règle et le nommer différemment. Dans ce cas, assurez-vous qu'elle n'entre pas en conflit avec les modèles réservés à la version, au correctif, à la correction de bogue, au développement ou à la branche principale. Le fait de conserver les identifiants de tâches JIRA vous aidera à gérer plus efficacement vos branches de fonctionnalités.

$ git checkout -b feature-JIRA-TASK-ID develop

Cette branche doit exister aussi longtemps que la fonctionnalité donnée est développée et ensuite fusionnée dans la branche parente. Pour effectuer un commit dans votre branche locale, veuillez suivre cette commande :

 $ git add .
 $ git commit -m "JIRA-TASK-ID : Description de la tâche"

Il est recommandé d'ajouter d'autres commits à votre branche locale, en suivant la règle "Commit early and often". Cependant, à la fin, ils doivent être regroupés en un seul commit représentant une tâche JIRA. Le fait de commiter souvent vous aidera à gérer l'historique de votre développement. Lorsque la fonctionnalité est prête, il est temps d'ouvrir une Pull Request pour développer une branche. Tout d'abord, vous pouvez pousser votre branche locale si elle n'a pas été poussée trop loin :

 $ git push origin feature-JIRA-TASK-ID

Lorsque la branche est prête, ouvrez votre demande d'extraction sur GitHub, en suivant cet article : https://help.github.com/en/articles/creating-a-pull-request

Avant d'ouvrir une demande d'extraction, veuillez vous assurer des points suivants :

• a description appropriée a été donnée - en général, vous lier votre tâche JIRAmais vous pouvez également inclure des informations utiles relatives au code actuel
• CircleCI les étapes ont été franchies avec succès
• votre les membres de l'équipe ont été affectés - il est bon d'inclure tous les membres de l'équipe dans les assignations
• les les évaluateurs ont été sélectionnés - le nombre de réviseurs dépend de votre équipe
• votre code est prêt à être examiné - jeter un dernier coup d'œil à votre code, réfléchir à nouveau s'il reste quelque chose à remanier, le tester localement et s'assurer qu'il est prêt pour les étapes suivantes.
• il y a pas de conflit de fusion et une branche est à jour avec develop - s'il y en a, il faut d'abord les résoudre

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # utiliser le drapeau -i pour le squash
$ git push -f origin feature-JIRA-TASK-ID # utiliser avec précaution car le drapeau -f écrase le dépôt distant

• ne conserver que les commits importants - chaque livraison doit être représentée par une tâche JIRA, par exemple, JIRA-TASK-ID : Configuration d'une nouvelle fonctionnalité ; d'autres devraient l'être écrasé lors du rebasage votre branche avec la branche develop
• vous avez le la branche de destination appropriée est sélectionnée
• vous n'oubliez pas de changer le statut de votre tâche JIRA

Fusionner la branche des fonctionnalités

Il est temps de fusionner vos changements dans la branche de développement quand :

• la demande de retrait a été approuvée par des membres sélectionnés de l'équipe
• tous les tests se sont terminés avec succès
• il n'y a pas de conflit de fusion et l'historique des livraisons semble correct

Cette opération peut être effectuée par le chef de projet ou le développeur de fonctionnalités. Pour effectuer la fusion, suivez les étapes suivantes :

 $ git checkout develop
 $ git merge feature-JIRA-TASK-ID
 $ git push origin develop
 $ git branch -d feature-JIRA-TASK-ID
 $ git push origin :feature-JIRA-TASK-ID

Désormais, le statut de la tâche JIRA peut être modifié.

Communiqués

Les branches de version doivent être créées par une personne responsable de la version en cours. En général, les versions sont créées périodiquement, par exemple, en fonction de la date de début et de fin de la version. sprint cycle de vie.

Versionnement sémantique

Donner à une branche de version un nom approprié et une étiquette correspondante n'est pas une tâche facile au tout début. C'est une bonne pratique que de commencer à utiliser le versionnement sémantique (https://semver.org/), ce qui permet un meilleur contrôle et facilite la lecture de l'historique git. La chaîne de version est construite selon le schéma MAJOR.MINOR.PATCH :

• MAJOR - changement représentant des changements d'API incompatibles
• MINOR - ajout de nouvelles fonctionnalités dans le respect de la rétrocompatibilité
• PATCH - ajout de corrections de bogues rétrocompatibles

Vous pouvez également utiliser des suffixes spéciaux, tels que ceux représentant les branches beta ou legacy, ou créer des pré-versions. Dans ce cas, nommez-les correctement, par exemple 1.1.0-beta.4, 1.1.0-beta.5 ou 1.1.0-alpha.

Faire une mise en circulation

La branche "release" doit être un enfant de la branche "develop" et ne doit contenir que des modifications liées à des corrections de bogues.

Le nom de la branche doit être basé sur la version, avec le préfixe release : release-MAJOR.MINOR.PATCH. La branche "release" doit être entièrement testé à la fois automatiquement et manuellement sur le environnement de transit. Si des bogues surviennent, c'est la dernière occasion de pousser les correctifs appropriés et de réexécuter l'ensemble du processus, tant qu'il ne sera pas positivement vérifié et prêt pour un traitement ultérieur. Ensuite, le commit de version devrait être poussé, avec les changements de la chaîne de la version actuelle dans les fichiers, tels que package.json. Il devrait également avoir un impact sur le fichier CHANGELOG.md. Cela vous aidera à suivre toutes les modifications avant une version correcte et à préparer le contenu pour la publication sur GitHub lorsque le processus de fusion sera terminé. La mise à jour du fichier unique doit comprendre toutes les modifications de la version regroupées en trois catégories : fonctionnalités, corrections et maintenance.

Dans un premier temps, assurez-vous que vos branches develop et master sont à jour.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git merge master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Produit Nom M.M.P release"
 $ git push origin release-M.M.P

À ce stade, on peut décider de créer une autre demande d'extraction vers le master avec la branche release. Il peut être judicieux d'effectuer une vérification supplémentaire pour s'assurer que tous les tests se déroulent correctement sur la machine distante.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # le message d'ajout peut être défini via le drapeau -m
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Allez ensuite sur la page GitHub releases et appuyez sur le bouton "Draft new release". Dans le formulaire affiché, sélectionnez la balise current version, définissez le titre de la version similaire au commit de la version (Product Name M.M.P release) et une description appropriée, basée sur le fichier CHANGELOG.md. Pour les projets publics, la description doit contenir une liste de tous les PR inclus dans la version actuelle.

Dans le cas où des corrections de bogues ont été appliquées sur la branche release, assurez-vous que votre branche develop a été mise à jour :

$ git checkout develop && git merge master
$ git push origin develo

Hotfixes et Bugfixes

La principale différence entre un bogue et un correctif est la branche qu'ils visent.

Correction de bogues

Les corrections de bogues devraient patcher les branches de version comme seule forme de mise à jour du code avant de le fusionner avec le master. Tout d'abord, créez la branche à partir de la branche de fonctionnalités actuelle. Assurez-vous qu'elle est à jour localement.

 $ git checkout release-M.M.P && git pull --rebase
 $ git checkout -b bugfix-M.M.P

Ensuite, livrez les changements nécessaires. Une fois le processus terminé, créez une demande d'extraction (pull request) et ciblez-la sur la branche de publication (release branch). Suivez les conseils de la section sur la branche des fonctionnalités. Le titre de votre livraison finale doit correspondre au schéma donné : "Bugfix M.M.P : Problem essence fix". Lorsque la demande d'extraction est approuvée, il est temps de la fusionner avec la version actuelle.

<$ git checkout release-M.M.P
 $ git merge bugfix-M.M.P
 $ git push origin release-M.M.P

Correctif

Pour effectuer un correctif sur la branche master, il faut suivre des étapes très similaires à celles d'une correction de bogue, en gardant à l'esprit que la branche cible est désormais la branche master.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P représente la version actuelle

Ensuite, suivez les étapes de développement habituelles et lorsque le processus est terminé, créez une demande d'extraction avec la branche master comme cible. Gardez à l'esprit que le commit final doit correspondre au schéma donné "Hotfix X.Y.(Z + 1) : Correction de l'essence du problème". Lorsque tous les points de contrôle ont été passés avec succès, effectuez une fusion vers la branche master. Ces étapes diffèrent de celles présentées pour une correction de bogue, car nous devons remonter la version actuelle.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # le message d'ajout peut être défini via le drapeau -m
 $ git push origin X.Y.(Z+1)
 $ git push origin master
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origin :hotfix-X.Y.(Z+1)
 $ git checkout develop && git merge master
 $ git push origin develop

Aide-mémoire

Init repository

 $ git init
 $ git commit --allow-empty -m "Initial commit"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Caractéristiques

$ git checkout develop && git pull --rebase
$ git checkout -b feature-JIRA-TASK-ID develop

Démarrer le développement et les commits

$ git add .
$ git commit -m "IRA-TASK-ID : Description de la tâche" #initial commit
$ git push origin feature-JIRA-TASK-ID

Ouvrir une pull request

Rebase et préparation d'une pull request

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # utiliser le drapeau -i pour le squash
$ git push -f origin feature-JIRA-TASK-ID # utiliser avec précaution car le drapeau -f écrase le dépôt distant

Fusionner les modifications et supprimer la branche

$ git checkout develop # la branche doit être synchronisée avec la branche develop à ce stade
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Communiqués

$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P

Créer un engagement de publication

$ git add .
$ git commit -m "Nom du produit M.M.P release" #initial commit
$ git push origin release-M.M.P

Ouvrir une pull request

Fusionner les modifications, publier et supprimer la branche

$ git checkout master # la branche devrait être synchronisée avec la branche master à ce stade
$ git merge release-M.M.P
$ git tag -a M.M.P # le message d'ajout peut être défini via le drapeau -m
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Correction de bogues

$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P

$ Commencer les corrections
$ git add .
$ git commit -m "Bugfix M.M.P : Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Ouvrir une pull request

Fusionner les modifications et supprimer la branche

$ git checkout release-M.M.P # la branche devrait être synchronisée avec la branche release actuelle à ce stade
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d bugfix-M.M.P
$ git push origin :bugfix-M.M.P

Correctif

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P représente la version actuelle

$ Commencer les corrections
$ git add .
$ git commit -m "Hotfix M.M.P : Problem essence fix" #initial commit
$ git push origin bugfix-M.M.P

Ouvrir une pull request

Fusionner les modifications, publier et supprimer les branches

$ git checkout master # la branche doit être synchronisée avec le master actuel à ce stade
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # le message d'ajout peut être défini via l'option -m
$ git push origin X.Y.(Z+1)
$ git push origin master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origin :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin develop

En savoir plus :

• Les bonnes pratiques de Codest pour la création de logiciels : CircleCI
• Comment créer des extensions Google Chrome en utilisant le styleur de sous-titres Netflix ?
• React : le cadre JavaScript le plus populaire