En quoi une étiquette est-elle différente d'une branche de Git? Qu'est-ce que je dois utiliser, ici?

du théorique point de vue:

• tags sont des noms symboliques pour un 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 le haut de la branche. Le pointeur de branche avance naturellement, pointant vers des propagations nouvelles et plus récentes.

du technique point de vue:

• tags résident dans refs/tags/ namespace, et peut pointer vers tag objects (tags annotés et éventuellement signés GPG) ou directement vers commit object (étiquette légère moins utilisée pour les noms locaux), ou dans de très rares cas même à tree object ou blob object (par exemple signature GPG).
• branches réside dans refs/heads/ espace de noms, et seulement pour les commits . Le pointeur HEAD doit faire référence à une branche (référence symbolique) ou directement à une commit (tête détachée ou branche sans nom).
• remote-tracking branches résident dans refs/remotes/<remote>/ namespace, et suivent branches ordinaires dans le dépôt à distance <remote> .

Voir aussi gitglossary manpage:

succursale

Une "branche" est une ligne active de développement. L'engagement le plus récent sur la branche est appelée la pointe de la direction. La pointe de la direction est indiquée par un chef de direction, qui va de l'avant au fur et à mesure que d'autres travaux de développement sont effectués sur la direction. Un seul dépôt git peut suivre un nombre arbitraire de branches, mais votre arbre de travail est associé à une seule d'entre elles (la branche "courant" ou "cochée"), et pointe vers cette branche.

tag

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

la balise object

Un objet contenant une référence pointant vers un autre objet, qui peut contenir un message comme un commit objet. Il peut aussi contenir une signature (PGP), auquel cas il est appelé "signed tag object".

si vous pensez à votre dépôt comme un livre qui fait la chronique de l'évolution de votre projet...

Branches

vous pouvez penser à une branche comme l'un de ces autocollants marque-page :

un dépôt tout neuf n'a qu'un seul de ceux (appelé master ), qui passe automatiquement à la dernière page (pensez commit ) vous avez écrire. Cependant, vous êtes libres de créer et d'utiliser plus de signets, afin de marquer d'autres points d'intérêt dans le livre, de sorte que vous pouvez revenir rapidement.

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

Tags

vous pouvez penser à des étiquettes comme les titres de chapitre .

il peut contenir un titre (pensez tags annotés ) ou non. Une étiquette est similaire mais différente d'une branche, en ce qu'elle marque un point de historique intérêt dans le livre. Pour maintenir son aspect historique, une fois que vous avez partagé une étiquette (i.e. poussé à une télécommande partagée), vous n'êtes pas censé le déplacer à un autre endroit dans le livre.

ce que vous devez réaliser, en venant de CVS, c'est que vous ne créez plus répertoires lors de la configuration d'une branche.

Plus de " sticky tag "(qui peut être appliqué à un seul fichier), ou"branch tag".

Les branches et les tags sont deux objets différents dans Git, et ils s'appliquent toujours au all repo.

vous n'auriez plus (avec SVN cette fois) à structurer explicitement votre dépôt avec:

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

cette structure vient du fait que CVS est un système de révision et non un système de version (voir Contrôle À La Source vs contrôle de révision? ).

Cela signifie que les branches sont émulées par des tags pour CVS, des copies de répertoire pour SVN.

votre question fait sens si vous êtes utilisé pour vérifier une étiquette, et commencer à travailler dans elle .

Ce que vous ne devriez pas;)

Une étiquette est censée représenter un contenu immuable , 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 graphe.

Une branche est un chemin de ce graphe

x--x--x--x--x # one branch
    \ 
     --y----y # another branch
       1.1
        ^
        |
        # a tag pointing to a commit

• si vous achetez une étiquette, vous aurez besoin de créer une branche pour commencer à travailler.
• si vous vérifiez une branche, vous verrez directement la dernière propagation('HEAD') de cette branche.

voir réponse de Jakub Narębski pour tous les détails techniques, mais franchement, à ce point, vous n'avez pas besoin (encore) tous les détails;)

le point principal est: une balise étant un simple pointeur vers un commit, vous ne pourrez jamais modifier son contenu. Vous besoin d'une direction générale.

dans votre cas, chaque développeur travaillant sur une caractéristique spécifique:

• devrait créer leur propre branche dans leur dépôt respectif
• piste branches de leur collègue référentiels (l'un travaillant sur la même fonctionnalité)
• tirant/poussant afin de partager votre travail avec vos pairs.

au lieu de en suivant directement les branches de vos collègues, vous pourriez suivre seulement la branche d'un dépôt central "officiel" vers lequel chacun pousse son travail afin d'intégrer et partager le travail de chacun pour cette caractéristique particulière.

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

Votre projet est l'arbre, et l'élément qui sera ajouté à le projet se développera sur une branche. La réponse est la branche.

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

la Git parabole explique comment un DVCS typique est créé et pourquoi leurs créateurs ont fait ce qu'ils ont fait. Aussi, vous pourriez vouloir jeter un oeil à Git for Computer Scientist ; il explique ce que chaque type d'objet dans Git fait, y compris les branches et les étiquettes.

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

Signé balises ne peuvent jamais se déplacer parce qu'ils sont cryptographiquement lié (avec signature) à un particulier de s'engager. 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 normale).

Branches peuvent non seulement passer à une commit différente, mais sont prévu de le faire. Vous devez utiliser un branche pour votre projet de développement local. Il n'est pas tout à fait logique de confier du travail à un dépôt Git "sur une étiquette".

Une balise est utilisée pour marquer une version, plus précisément, elle fait référence à un point dans le temps sur une branche. Une branche est généralement utilisé pour ajouter des fonctionnalités à un projet.

simple:

On s'attend à ce que les étiquettes

pointent toujours vers la même version d'un projet, tandis que les têtes devraient avancer au fur et à mesure que le développement progresse.

Git Manuel De L'Utilisateur

Tronc : le corps principal de développement, en provenance du début du projet jusqu'à présent.

Branch " sera une copie du code dérivé d'un certain point dans le tronc qui est utilisé pour appliquer des changements majeurs au code tandis que préserver l'intégrité du code dans le coffre. Si les grands les changements fonctionnent selon le plan, ils sont généralement fusionnés de nouveau dans le tronc.

Tag : sera un point dans le temps sur le tronc ou une branche que vous souhaitez conserver. Les deux principales raisons de la préservation seraient les suivantes: soit il s'agit d'une version majeure du logiciel, si alpha, bêta, RC ou RTM, ou c'est le point le plus stable du logiciel avant des révisions importantes ont été apportées au tronc.