Japprends actuellement à utiliser Git en lisant Pro Git . En ce moment, japprends les branches et les balises. Ma question est quand dois-je utiliser une branche et quand dois-je utiliser une balise?
Par exemple, disons que je crée une branche pour la version 1.1 dun projet. Lorsque jai terminé et publié cette version, dois-je quitter la branche pour marquer la version publiée? Ou dois-je ajouter une balise? Si jajoute une balise, dois-je supprimer la branche de version (en supposant quelle est fusionnée dans master ou dans une autre branche )?
Réponse
En bref: La meilleure pratique consiste à se diversifier, fusionner souvent et rester toujours synchronisé .
Il existe des conventions assez claires pour conserver votre code dans une branche distincte de la branche master:
- Vous êtes sur le point de faire une implémentation de changement majeur ou perturbateur
- Vous êtes sur le point pour apporter des modifications qui pourraient ne pas être utilisées
- Vous souhaitez expérimenter quelque chose dont vous nêtes pas sûr quil fonctionnera
- Lorsquon vous demande de créer une branche, dautres peuvent avoir quelque chose à faire dans le maître
La règle de base est quaprès la branche, vous devez rester synchronisé avec le maître branche. Parce que finalement, vous devez le fusionner en maître. Afin déviter un énorme désordre compliqué de conflits lors de la fusion, vous devez vous engager souvent, fusionner souvent.
Bonnes pratiques à suivre
Un modèle de branchement Git réussi par Vincent Driessen a de bonnes suggestions. Si ce modèle de branchement vous plaît, considérez lextension de flux vers git . Dautres ont commenté le flux .
Pratiques de balisage
Comme vous le savez déjà, Git vous donne des identifiants de commit comme 1.0 -2-g1ab3183 mais ce ne sont pas des balises! Le balisage se fait avec la balise git, et les balises créées à laide de la balise git sont la base des identificateurs de validation créés par git describe. En dautres termes, dans Git, vous ne marquez pas de branches. Vous marquez des commits. Il est correct de dire que ce tag nest quun pointeur annoté vers un commit.
Regardons un exemple pratique qui la démontré,
/-- [v1.0] v ---.---.---.---S---.---A <-- master \ \-.---B <-- test
Soit « s commit » S « un commit pointé par la balise » v1.0 « . Ce commit est à la fois sur la branche « master » et sur la branche « test ». Si vous exécutez " git describe " au-dessus de la validation » A « (en haut de la branche » master « ), vous obtiendrez quelque chose comme v1.0-2-g9c116e9. Si vous exécutez " git describe " au-dessus du commit « B » (alias la branche « test »), vous obtiendrez quelque chose comme v1.0-2-g3f55e41, cest le cas avec la configuration par défaut de git-describe. Notez que ce résultat est légèrement différent. v1.0-2-g9c116e9 signifie que nous sommes en phase de validation avec lidentifiant SHA-1 trié de 9c116e9, 2 validations après la balise v1.0. Il ny a pas de balise v1.0-2!
Si vous voulez que votre balise apparaisse uniquement sur la branche « master », vous pouvez créer un nouveau commit (par exemple, uniquement mettre à jour default / fallback informations de version dans GIT-VERSION-FILE) après le point de branchement de la branche « test ». Si vous marquez les commits sur la branche « test » avec par exemple « v1.0.3` il ne serait visible que depuis » test « .
Références
Jai trouvé de très nombreux blogs et articles utiles pour apprendre. Cependant, ceux qui sont illustrées professionnellement sont rares. Par conséquent, je voudrais recommander un article – Un modèle de branchement Git réussi par @nvie. Jai emprunté son illustration:)
Commentaires
- 1.0-2-g1ab3183 est un identifiant construit par git describe à partir des informations disponibles à partir de git, mais lappeler un identifiant git est un peu trop. Git sidentifie par hachage SHA; les balises et les branches sont des constructions humaines dont git assure le suivi. En tant que tel, créez une balise quand vous pensez quun humain voudra un jour trouver un signet pratique pour un commit.
- une merveilleuse illustration de la multidimensionnalité dans lunivers git. magnifique. merci
- Cela vaut la peine notant que de nombreux projets nont pas besoin de certains des voies montrées dans ce diagramme. Certains projets nont besoin que de ce que ' appelle développer et présenter ici. Cest souvent le cas pour les applications Web qui peuvent être déployées à volonté.
- Même lauteur de git flow ne le recommande plus pour de nombreux types de projets, tels que le développement Web. Beaucoup de gens pensent quil est beaucoup plus complexe que ce dont la grande majorité des projets a besoin, ce qui le rend difficile à exécuter et facile à se tromper.À lautre extrémité du spectre, certaines équipes de praticiens avancés préconisent lutilisation de ' développement basé sur le tronc ', qui nutilise presque jamais de branches du tout, et livrer des projets réussis comme ça. Pour quelque chose dintermédiaire, considérez " anti-gitflow '
Réponse
Une branche est utilisée si vous avez 2 versions différentes de référentiel en même temps. Une balise est un moyen de marquer un point dans le temps dans votre référentiel.
Vous devez ajouter une balise pour marquer une version publiée. Si vous devez ensuite apporter des corrections de bogues à cette version, vous créez une branche au niveau de la balise.
Vous souhaitez uniquement supprimer les branches qui ont été fusionnées dans HEAD [ou une autre branche]. p>
Commentaires
- oh … et je suppose que vous voulez dire que la branche est fusionnée dans une autre branche, telle que master. HEAD bouge à chaque fois que je passe à la caisse, nest-ce pas?
- HEAD pointe généralement vers une branche (sauf si vous ' êtes en mode HEAD détaché), donc HEAD se déplace avec la branche vers laquelle il pointe