Git Branching et bonnes pratiques de marquage


141

J'apprends actuellement à utiliser Git en lisant Pro Git . En ce moment, j'apprends à propos des branches et des tags. Ma question est la suivante: quand dois-je utiliser une branche et quand dois-je utiliser une balise?

Par exemple, supposons que je crée une branche pour la version 1.1 d'un projet. Lorsque je termine et publie cette version, dois-je quitter la succursale pour marquer la version? Ou devrais-je ajouter un tag? Si j'ajoute une balise, dois-je supprimer la branche de version (en supposant qu'elle soit fusionnée dans la branche principale ou dans une autre branche)?

Réponses:


162

En bref: la meilleure pratique consiste à créer des branches, à fusionner souvent et à rester synchronisées .

Il existe des conventions assez claires sur la conservation de votre code dans des branches distinctes de la branche principale:

  1. Vous êtes sur le point de mettre en œuvre des changements majeurs ou perturbateurs
  2. Vous êtes sur le point d'effectuer des modifications qui pourraient ne pas être utilisées
  3. Vous voulez expérimenter quelque chose que vous n'êtes pas sûr que cela fonctionnera
  4. Quand on vous dit de vous diversifier, les autres peuvent avoir quelque chose à faire en mode maître

En règle générale, après la création d'une branche, vous devez rester synchronisé avec la branche principale. Parce que finalement vous devez le fusionner pour le maîtriser. Afin d'éviter un désordre compliqué de conflits lors de la fusion, vous devez commettre 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 intéresse, envisagez l' extension de flux à git . D'autres ont commenté sur le flux .

Pratiques de marquage

Comme vous le savez déjà, Git vous donne des identifiants de commit tels que 1.0-2-g1ab3183 mais ce ne sont pas des tags! Le balisage est effectué avec la balise git, et les balises créées à l'aide de la balise git constituent la base des identificateurs de validation créés par git describe. En d'autres termes, dans Git, vous ne marquez pas les branches. Vous étiquetez les commits. Il est correct de dire que la balise est juste un pointeur annoté sur un commit.

Regardons un exemple pratique qui l’a démontré,

                        / - [v1.0]
                       v
---. ---. --- .--- S ---.--- Un <- maître
                         \ 
                           \ -.--- B <- test

Commençons par «S» avec la balise 'v1.0'. Ce commit est à la fois sur le "maître" de la branche et sur le "test" de la branche. Si vous exécutez " git decrire " en plus du commit 'A' (en haut de la branche 'master'), vous obtiendrez quelque chose comme v1.0-2-g9c116e9. Si vous exécutez "git describe" en plus du commit 'A' (c'est-à-dire la branche 'test'), vous obtiendrez quelque chose du genre v1.0-2-g3f55e41, c'est le cas de la configuration par défaut de git-describe. Notez que ce résultat est légèrement différent. v1.0-2-g9c116e9signifie que nous sommes au commit avec SHA-1 trié id de 9c116e9, 2 commits après tag v1.0. Il n'y a pas de tag v1.0-2!

Si vous souhaitez que votre balise n'apparaisse que sur la branche 'maître', vous pouvez créer un nouveau commit (par exemple, ne mettre à jour que les informations de version par défaut / de secours dans GIT-VERSION-FILE) après le point de branchement de la branche 'test'. Si vous marquez les commits sur une branche 'test' avec par exemple 'v1.0.3`, cela ne sera visible que depuis' test '.

Références

J'ai trouvé beaucoup, beaucoup de blogs et de messages utiles pour apprendre. Cependant, ceux qui sont illustrés professionnellement sont rares. Ainsi, je voudrais recommander un post - Un modèle de branchement Git réussi par @nvie. J'ai emprunté son illustration :)

entrez la description de l'image ici


4
1.0-2-g1ab3183 est un identifiant construit par git et décrit à partir des informations disponibles à partir de git, mais l'appeler un identifiant git est un peu trop. Git identifie par le hash SHA; les balises et les branches sont des constructions humaines que git garde la trace de manière utile. En tant que tel, créez une étiquette lorsque vous pensez qu'un être humain voudra un jour trouver un signet pratique pour un commit.
Mabraham

2
une magnifique illustration de la multi-dimensionnalité dans l'univers git. magnifique. merci
Tope

Il convient de noter que de nombreux projets n’ont pas besoin de certaines des voies présentées dans ce diagramme. Certains projets n'ont besoin que de ce que l'on appelle développer et figurer ici. Cela est souvent vrai pour les applications Web pouvant être déployées à volonté.
USR

37

Une branche est utilisée si vous avez 2 versions différentes du 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 corriger le bogue de cette version, vous créerez une branche au niveau de la balise.

Vous souhaitez uniquement supprimer les branches qui ont été fusionnées dans HEAD [ou dans une autre branche].


3
oh ... et je suppose que vous voulez dire que la branche est fusionnée dans une autre branche, telle que master. HEAD se déplace à chaque fois que je fais une commande, non?
Code-Guru

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 elle pointe
LoicAG
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.