Question Comment est une étiquette différente d'une branche dans Git? Lequel dois-je utiliser, ici?


J'ai de la difficulté à comprendre comment utiliser Mots clés contre branches à Git.

Je viens de déplacer la version actuelle de notre code de CVS à Git, et maintenant je vais travailler sur un sous-ensemble de ce code pour une fonctionnalité particulière. Quelques autres développeurs travailleront également sur ce sujet, mais tous les développeurs de notre groupe ne se soucient pas de cette fonctionnalité. Devrais-je créer une branche ou un tag? Dans quelles situations devrais-je utiliser l'un par rapport à l'autre?


496
2017-09-21 21:55


origine


Réponses:


Une balise représente une version d'une branche particulière à un moment donné. Une branche représente un fil de développement distinct qui peut s'exécuter simultanément avec d'autres efforts de développement sur la même base de code. Les modifications apportées à une branche peuvent éventuellement être fusionnées dans une autre branche pour les unifier.

Habituellement, vous taguez une version particulière afin de pouvoir la recréer, par exemple, c'est la version que nous avons envoyée à XYZ Corp. Une branche est plus une stratégie pour fournir des mises à jour continues sur une version particulière du code tout en continuant à faire du développement dessus. Vous allez créer une branche de la version livrée, poursuivre le développement sur la ligne principale, mais apporter des corrections de bogues à la branche qui représente la version livrée. Finalement, vous allez fusionner ces corrections de bogues dans la ligne principale. Souvent, vous utiliserez à la fois le branchement et le marquage. Vous aurez différents tags qui peuvent s'appliquer à la ligne principale et à ses branches en marquant des versions particulières (celles livrées aux clients, par exemple) le long de chaque branche que vous voudrez peut-être recréer - pour la livraison, le diagnostic de bogue, etc.

C'est en fait plus compliqué que cela - ou aussi compliqué que vous voulez le faire - mais ces exemples devraient vous donner une idée des différences.


419
2017-09-21 22:03



Du théorique point de vue:

  • Mots clés sont des noms symboliques pour une donnée révision. Ils pointent toujours vers le même objet (généralement: à la même révision); ils ne changent pas.
  • branches sont des noms symboliques pour ligne de développement. Les nouveaux commits sont créés en haut de la branche. Le pointeur de branche avance naturellement, pointant vers des commits plus récents et plus récents.

Du technique point de vue:

  • Mots clés résider dans refs/tags/ espace de noms, et peut pointer vers objets tag (annotés et facultativement les balises signées GPG) ou directement à commit objet (étiquette légère moins utilisée pour les noms locaux) ou, dans de objet d'arbre ou objet blob (par exemple, signature GPG).
  • branches résider dans refs/heads/ namespace, et ne peut pointer que vers commettre des objets. le HEAD pointeur doit se référer à une branche (référence symbolique) ou directement à un commit (détaché HEAD ou branche non nommée).
  • branches de suivi à distance résider dans refs/remotes/<remote>/ namespace, et suivez les branches ordinaires dans le référentiel distant <remote>.

Voir également gitglossaire manpage:

branche 

Une "branche" est une ligne de développement active. La validation la plus récente sur une branche est appelée la pointe de cette branche. La pointe de la branche est référencée par une tête de branche, qui avance au fur et à mesure que le développement se fait sur la branche. Un référentiel git unique peut suivre un nombre arbitraire de branches, mais votre arbre de travail est associé à une seule d'entre elles (la branche "current" ou "checked out"), et HEAD pointe sur cette branche.

marque

Une référence pointant vers une balise ou un objet commit. Contrairement à une tête, une étiquette n'est pas modifiée par un commit. Les tags (pas les objets tag) sont stockés dans $GIT_DIR/refs/tags/. [...] Une balise est généralement utilisée pour marquer un point particulier dans la chaîne d'ascendance de validation.

tag objet

Un objet contenant une référence pointant vers un autre objet, qui peut contenir un message comme un objet commit. Il peut également contenir une signature (PGP), auquel cas il s’appelle un "objet de balise signé".


424
2017-09-22 00:12



Si vous considérez votre référentiel comme un livre qui relate les progrès de votre projet ...

Branches

Vous pouvez penser à une branche comme l'une de ces collantes signets:

enter image description here

Un référentiel flambant neuf n'en a qu'un (appelé master), qui passe automatiquement à la dernière page (pensez commettre) vous avez écrit. Cependant, vous êtes libre de créer et d'utiliser davantage de signets afin de marquer d'autres points d'intérêt dans le livre, afin de pouvoir y revenir rapidement.

En outre, vous pouvez toujours déplacer un signet particulier vers une autre page du livre (en utilisant git-reset, par exemple); les points d'intérêt varient généralement au fil du temps.

Mots clés

Vous pouvez penser aux tags comme en-têtes de chapitres.

bookmarks

Il peut contenir un titre (penser balises annotées) ou pas. Une étiquette est similaire mais différente d'une branche, en ce sens qu'elle marque un point de historique intérêt dans le livre. Pour conserver son aspect historique, une fois que vous avez partagé une balise (c’est-à-dire l’a poussée sur une télécommande partagée), tu n'es pas censé déplacez-le à un autre endroit du livre.


110
2017-09-16 17:05



Ce que vous devez réaliser, venant de CVS, c'est que vous ne créez plus répertoires lors de la mise en place d'une succursale.
Plus de "sticky tag" (qui peut être appliqué à un seul fichier), ou "branch tag".
Branche et les tags sont deux objets différents dans Git, et ils s'appliquent toujours à la tout repo.

Vous ne devriez plus (avec SVN cette fois) structurer explicitement votre dépôt avec:

branches
   myFirstBranch
     myProject
       mySubDirs
   mySecondBranch
     ...
tags
   myFirstTag
     myProject
       mySubDirs
   mySecondTag
   ...

Cette structure provient du fait que CVS est un système de révision et pas un système de version (voir Contrôle de la source vs. Contrôle de la révision?).
Cela signifie que les branches sont émulées via des balises pour CVS, des copies de répertoire pour SVN.

Votre question fait sens si vous avez l'habitude de commander une étiquette, et commencer à y travailler.
Ce que vous ne devriez pas;)
Une étiquette est censée représenter un immuable contenu, utilisé uniquement pour y accéder avec la garantie d'obtenir le même contenu à chaque fois.

Dans Git, l'histoire des révisions est une série de commits, formant un graphique.
Une branche est un chemin de ce graphique

x--x--x--x--x # one branch
    \ 
     --y----y # another branch
       1.1
        ^
        |
        # a tag pointing to a commit
  • Si vous extrayez une balise, vous devrez créer une branche pour commencer à l'utiliser.
  • Si vous extrayez une branche, vous verrez directement le dernier commit ('HEAD') de cette branche.

Voir La réponse de Jakub Narębski pour toutes les technicalités, mais franchement, à ce stade, vous n'avez pas (encore) besoin de tous les détails;)

Le point principal est: une balise étant un simple pointeur vers un commit, vous ne pourrez jamais en modifier le contenu. Vous avez besoin d'une branche.


Dans votre cas, chaque développeur travaillant sur une fonctionnalité spécifique:

  • devrait créer leur propre branche dans leur référentiel respectif
  • suivre les branches à partir des référentiels de leurs collègues (celui qui travaille sur la même fonctionnalité)
  • tirer / pousser afin de partager votre travail avec vos pairs.

Au lieu de suivre directement les branches de vos collègues, vous ne pouvez suivre que la branche d'un référentiel central "officiel" vers lequel chacun travaille pour intégrer et partager le travail de chacun pour cette fonctionnalité particulière.


39
2017-09-22 07:10



Les branches sont faites de bois et poussent dans le tronc de l'arbre. Les étiquettes sont faites de papier (dérivé du bois) et accrochées comme des ornements de Noël à divers endroits de l'arbre.

Votre projet est l'arborescence et votre fonctionnalité qui sera ajoutée au projet se développera sur une branche. La réponse est branche.


26
2017-10-16 20:50



Il semble que la meilleure façon d'expliquer est que les balises agissent comme des branches en lecture seule. Vous pouvez utiliser une branche comme une balise, mais vous pouvez la mettre à jour par inadvertance avec de nouveaux commits. Les tags sont garantis pour pointer vers le même commit tant qu'ils existent.


15
2017-08-28 23:32



Les tags peuvent être soit signé ou non signé; les branches ne sont jamais signées.

Les balises signées ne peuvent jamais bouger car elles sont liées de manière cryptographique (avec une signature) à un commit particulier. Les étiquettes non signées ne sont pas liées et il est possible de les déplacer (mais les étiquettes mobiles ne sont pas un cas d'utilisation normal).

Les branches peuvent non seulement passer à un commit différent mais attendu faire cela. Vous devriez utiliser une succursale pour votre projet de développement local. Cela n'a pas de sens de confier un travail à un dépôt Git "sur un tag".


10
2017-09-21 22:03