Tout d'abord, un peu de contexte, nous sommes en train de déplacer toutes nos équipes de projet vers l'utilisation de git et nous sommes en train de définir les directives sur la façon dont les référentiels doivent être organisés afin que certaines succursales puissent également être surveillées pour une intégration continue et déploiement automatique sur les serveurs de test. Actuellement, deux modèles se développent:
Fortement influencé par article nvie.com sur les branchements réussis avec la branche principale représentant le code le plus stable, une branche de développement pour le code Edge qui saigne et une branche d'intégration pour le code qui est prêt pour les tests d'assurance qualité.
Un modèle alternatif dans lequel la branche principale représente le code de développement Edge saignant, une branche d'intégration pour le code qui est prêt pour les tests d'assurance qualité et une branche de production pour le code stable qui est prêt pour le déploiement.
À ce stade, il s'agit en partie d'une question de sémantique quant à ce que représente la branche principale, mais est-ce que le développement actif sur la branche principale est une bonne pratique ou n'est-ce pas vraiment pertinent?
La seule véritable caractéristique qui définit la branche master
est qu'elle est la valeur par défaut pour certaines opérations. De plus, les noms de branche n'ont de signification que dans un référentiel spécifique. Mon master
peut pointer vers votre development
, par exemple. De plus, une branche master
n'est même pas requise, donc s'il y a une confusion quant à la branche qu'elle devrait être, mon conseil est généralement de la laisser de côté.
Cependant, à mon avis, la meilleure façon d'y penser est comme valeur par défaut pour pousser. La plupart des didacticiels en ligne que vos développeurs lisent supposeront cela. Il est donc très logique que master
soit la branche sur laquelle on pousse le plus souvent. Certaines personnes le considèrent comme la copie vierge qui est intouchable pour les développeurs, sauf après un examen minutieux, mais l'utiliser de cette façon supprime une grande partie des valeurs par défaut utiles fournies par git. Si vous voulez ce genre de branche vierge, je le mettrais dans un référentiel complètement séparé que seules certaines personnes peuvent écrire.
Non, ce n'est pas conseillé, même au début avant de passer au contrôle qualité. En tant que meilleure pratique, le modèle de développement doit être cohérent du début à la fin. Votre branche maître doit commencer vide, vous devez débrancher votre branche de développement et commencer à ajouter des fichiers, fusionner dans votre branche d'intégration, puis par la suite à votre maître.
Bien que personne ne se soucie du développement que la branche principale ne construit pas, elle se prête très tôt aux mauvaises habitudes. Le maître doit toujours construire, et pour les versions majeures des fonctionnalités, ce ne serait pas une mauvaise idée d'avoir des branches archivées des versions majeures afin que les points de version stables puissent être retournés si nécessaire.