Cet article fait partie de notre série "Advanced Git". Suivez-nous sur Twitter ou abonnez-vous à notre newsletter pour des mises à jour sur les futurs articles!
La plupart des systèmes de contrôle de version (VCS) prennent en charge la ramification . Essentiellement, la branche crée un espace de travail distinct pour vos modifications, permettant l'expérimentation sans affecter la base de code principale. Le modèle de branchement de Git est exceptionnellement puissant, connu pour sa vitesse et son efficacité dans la création, la commutation et la suppression des branches. Git promeut activement les workflows lourds de ramification.
Alors que les développeurs individuels ont la liberté dans leurs pratiques de branchement, le travail d'équipe nécessite une stratégie partagée. Git fournit les outils; L'équipe définit l'utilisation optimale. Cet article explore diverses stratégies de ramification, types de branches et deux workflows populaires: le flux Git et le flux de github.
Une collaboration d'équipe efficace nécessite une stratégie de branchement documentée et un flux de travail. Cette documentation empêche les conflits, rationalise l'intégration et garantit que tout le monde comprend le processus.
Exemples de conventions:
master
(ou main
): Libération publique actuelle.next
: la version publique à venir (permet des hotfixes sur master
sans fusionner les modifications non liées).feature/
: branches de fonction (organisées sous ce préfixe).wip/
: Branches de travail en cours (pour les sauvegardes personnelles).Ces conventions sont illustratives; Les équipes peuvent les adapter à leurs besoins.
Les stratégies de ramification devraient considérer l'intégration des changements et la structuration de libération. Deux approches contrastées mettent en évidence le spectre des possibilités:
Développement de la ligne principale: une approche "toujours intégrée" en utilisant une seule branche. Toutes les contributions sont directement attachées à la ligne principale. Cela simplifie le suivi mais nécessite des tests rigoureux et de petits validations fréquentes.
État, libération et branches de fonctionnalités: utilise plusieurs types de succursales pour gérer les fonctionnalités, les versions et les états de développement. Cette approche est plus complexe mais offre une meilleure organisation et un meilleur contrôle pour les projets et les équipes plus importants. La plupart des équipes se situent quelque part entre ces extrêmes.
Examinons-les plus en détail.
Le principe central est l'intégration continue. Tous les développeurs s'engagent directement dans une seule branche. Cela simplifie le suivi mais exige des tests de haute qualité pour éviter les problèmes d'intégration. La simplicité le rend inapproprié pour les équipes dépourvues d'une infrastructure de test robuste.
Cette stratégie utilise différents types de branches à des fins distinctes: le développement des fonctionnalités, la gestion des versions et la représentation de diverses étapes de développement. Tout en semblant complexe, il devient gérable avec la pratique et est bien adapté aux projets avec des cycles de libération plus complexes.
Ensuite, nous nous plongeons dans les branches de longue durée et de courte durée.
Chaque référentiel en a au moins un, souvent nommé master
ou main
. D'autres branches de longue durée pourraient inclure develop
, production
ou staging
, représentant différentes étapes du processus de libération. Ces branches persistent tout au long du cycle de vie du projet.
Une règle commune consiste à éviter les engagements directs dans les branches de longue date. Au lieu de cela, les modifications sont intégrées en fusion ou en rebasition, en assurant la qualité du code et les versions contrôlées.
Ces branches servent des objectifs temporaires, créés pour des tâches spécifiques (nouvelles fonctionnalités, corrections de bogues, refactorisation) et supprimé après intégration dans une branche de longue date. Ils se ramifient généralement à partir d'une branche de longue date, permettant un développement isolé puis fusionnant les travaux terminés dans la ligne principale.
Deux stratégies largement utilisées offrent des approches différentes:
Cette stratégie utilise main
pour les versions de production et develop
pour le développement continu. Les branches de fonctionnalités de la branche develop
et les branches de libération sont créées à partir de develop
pour la préparation des versions. Une fois testés, les branches de libération sont fusionnées dans main
, marquées et supprimées. Bien que efficace pour les logiciels emballés, il pourrait être trop complexe pour les projets Web.
Convient à la livraison continue avec des versions fréquentes, Github Flow utilise une seule branche main
. Tous les fonctions, quel que soit le type (fonctionnalité, correction de bogues, refactoring), réside dans sa propre branche jusqu'à ce qu'elles soient main
. Sa simplicité le rend idéal pour une itération rapide.
La stratégie de ramification optimale est très dépendante du contexte. Les équipes devraient évaluer en collaboration les besoins de leur projet, la stratégie de libération et le processus de développement pour sélectionner l'approche la plus appropriée. Il n'y a pas de solution unique. Envisagez d'explorer des ressources supplémentaires comme le "Kit Git avancé" pour une compréhension plus approfondie des outils Git avancés.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!