Git propose des stratégies de branchement flexibles, mais qu'est-ce que cela signifie ? En termes simples, une stratégie de création de branches est un ensemble de règles, une convention qui aide les équipes et les développeurs - ils peuvent suivre ces règles et conventions pour créer une nouvelle branche, son flux, etc.
Ne pas utiliser les conventions de nommage appropriées est source de confusion et complique l'équipe de maintenance du code. Nous ne pouvons pas ignorer les bonnes pratiques de Git en matière de conventions de nommage de branches.
Les stratégies de branchement Git permettent de séparer le travail. En gros, nous pouvons diviser les branches Git en deux catégories :les branches régulières et temporaires.
Branches Git régulières
Ces branches seront disponibles dans votre référentiel sur des bases permanentes. Leur convention de nommage est simple et directe.
- Développement (dev ) est la principale branche de développement. L'idée de la branche dev est d'y apporter des modifications et d'empêcher les développeurs d'apporter directement des modifications à la branche master. Les modifications apportées à la branche dev font l'objet d'examens et, après les tests, sont fusionnées avec la branche master.
- Maître (maître ) est la branche par défaut disponible dans le référentiel Git. Il doit être stable tout le temps et ne permettre aucun enregistrement direct. Vous ne pouvez le fusionner qu'après la révision du code. Tous les membres de l'équipe sont responsables de la stabilité et de la mise à jour du master.
- AQ (AQ ), ou branche de test, contient tout le code pour les tests d'assurance qualité et les tests d'automatisation de toutes les modifications mises en œuvre. Avant que toute modification ne soit transmise à l'environnement de production, elle doit subir les tests d'assurance qualité pour obtenir une base de code stable.
Branches Git temporaires
Comme leur nom l'indique, ce sont les branches qui peuvent être créées et supprimées en cas de besoin. Ils peuvent être les suivants :
- Correction de bogues
- Correctif
- Branches de fonctionnalités
- Branches expérimentales
- Succursales WIP
Il existe de nombreux formats et conventions de dénomination recommandés par les experts pour les succursales temporaires.
Voici un workflow simple de branches Git.
Convention de nommage des branches Git
Dans cet article, je vais passer en revue et partager les sept meilleures conventions de dénomination que j'ai utilisées personnellement dans le passé pour garantir leur efficacité.
1. Commencez le nom de la branche par un mot de groupe
C'est l'une des meilleures pratiques. Le mot de groupe peut être n'importe quoi pour correspondre à votre flux de travail.
J'aime les mots courts comme ceux-ci :
Bogue – Le bogue qui doit être corrigé bientôt
TEC – Le travail est en cours, et je suis conscient qu'il ne se terminera pas de sitôt
En regardant le nom de la branche, vous pouvez comprendre en quoi consiste cette branche Git et son objectif.
Jetez un œil aux exemples ci-dessous :
- bug-logo-alignment-issue – le développeur essaie de résoudre le problème d'alignement du logo ;
- wip-ioc-container-added – la branche se rapporte à la tâche d'ajout d'un conteneur IoC en cours.
2. Utiliser un identifiant unique dans les noms de succursale
Vous pouvez utiliser l'identifiant de suivi des problèmes dans le nom de votre succursale. Je préfère cette méthode lorsque je travaille sur la correction de certains bugs. Par exemple :
wip-8712-add-testing-module
Le nom indique que la branche s'applique à la tâche d'ajout d'un module de test, l'ID de suivi du problème est 8712 et le travail est en cours.
Un autre avantage de l'utilisation d'un identifiant de suivi externe dans le nom de la succursale est la possibilité de suivre la progression à partir d'un système externe.
3. Utilisez un trait d'union ou une barre oblique comme séparateurs
De nombreux développeurs utilisent une barre oblique comme séparateur et beaucoup utilisent des traits d'union. Lequel utiliser – dépend de vous et des préférences de votre équipe.
Mon opinion est que les traits d'union rendent le nom plus confortable à lire, c'est donc un séparateur approprié dans les noms de branche. Vous pouvez utiliser des barres obliques, des tirets et des traits de soulignement. Le but est d'être cohérent.
L'utilisation d'un séparateur dans le nom de la branche présente deux avantages principaux :
- Cela améliore la lisibilité et aide à éviter toute confusion ;
- Cela facilite la gestion, surtout si vous traitez avec de nombreuses succursales.
Exemple 1. Nom de la branche Git sans aucun séparateur :
featureupgradejqueryversionloginmodule
Exemple 2. En ajoutant un séparateur (dans ce cas, il s'agit d'un trait de soulignement), vous rendez lisible le nom de la branche Git :
feature_upgrade_jquery_version_login_module
4. Branche Git avec le nom de l'auteur
De nombreuses entreprises préfèrent ajouter les noms des auteurs dans les noms de branche selon le format ci-dessous :
<author>_<branch-type>_<branch-name>Par exemple, rajeev.bera_feature_new-experimental-changes
Cette méthode permet de suivre facilement le travail et les progrès des différents développeurs avec des systèmes supplémentaires.
5. Évitez d'utiliser uniquement des chiffres
Certains développeurs n'utilisent que l'Id du problème dans le nom de la branche, ce qui n'est pas utile dans la progression du travail.
Par exemple, il y a un nom de branche 9912 - que devrait nous dire ce nombre magique ? Cela signifie seulement plus de confusion et de risque d'erreurs, en particulier lors de la fusion avec d'autres branches git.
6. Évitez d'utiliser toutes les conventions de nommage simultanément
Mélanger et faire correspondre toutes les conventions de nommage des branches Git n'est pas la meilleure pratique. Cela ne fait qu'ajouter de la confusion et complique l'ensemble des processus.
Une équipe doit décider une seule fois des conventions de nommage à utiliser dans le travail et s'y tenir. La cohérence est la chose la plus critique.
7. Évitez les longs noms descriptifs pour les branches à longue durée de vie
La qualité essentielle d'un nom de succursale est qu'il doit être précis et informatif. Reprenons quelques exemples :
wip_login_module_which_will_used_in_the_public_website
wip_login_module_which_will_used_in_the_internal_website
Là, les noms des branches sont longs et détaillés. Ce n'est pas nécessaire. À la place, vous pouvez utiliser la variante suivante :
wip_feature_login_module
Ce nom est court, mais il explique le but de cette branche.
Conclusion
Le modèle de branchement Git est puissant, mais vous devez gérer les branches correctement et efficacement. L'un des facteurs nécessaires est de suivre les mêmes conventions par toutes les équipes, en particulier - les conventions de nommage pour le référentiel local.
Pour vous assurer que votre équipe utilise les conventions convenues, appliquez les normes. L'un des moyens les plus simples consiste à utiliser des crochets Git, comme le crochet de pré-commit. J'espère que cela vous donnera une idée des modèles de branchement Git et de leur convention de dénomination.
