Question Comment créer un tag avec certains commits et le pousser à l'origine?


Dites que le journal actuel dans mon fichier gerrit ressemble à ceci:

  • commit10 (master)
  • commettre9
  • commettre8
  • commettre7
  • commit6 v1.72.0
  • commettre5
  • commit4 v1.71.0
  • commettre3
  • commettre2
  • commettre1

Mon but est de créer un nouveau tag (v1.73.0) qui devrait contenir commit8 et commit9 et le pousser à l'origine. On m'a dit de créer une nouvelle branche locale basée sur la dernière balise stable et de sélectionner les commits nécessaires et de les étiqueter. Cependant, j'ai du mal à pousser l'étiquette à maitriser.

Voici ce que j'ai fait:

  • créer une branche locale basée sur la dernière balise: git checkout -b branchforv1.73.0 v1.72.0
  • cueillette de cerises commit8 et commit9
  • créer un nouveau tag: git tag v1.73.0

... alors, comment puis-je pousser la v1.73.0 à maîtriser?

Résultat:

  • commit10 (master)
  • commettre7
  • commit9 v1.73.0
  • commettre8
  • commit6 v1.72.0
  • commettre5
  • commit4 v1.71.0
  • commettre3
  • commettre2
  • commettre1

13
2017-09-09 23:26


origine


Réponses:


Comment les tags fonctionnent

Dans git, chaque balise est dite "pointer" sur un (un seul) commit. En fait, il en va de même pour une branche: un nom de branche aussi juste des points à un commit.

Ce qui fait que ce travail est deux choses:

  • chaque validation pointe également vers un autre commit (ou peut-être plusieurs), et
  • pour les branches (et seulement pour les branches), le commit auquel la branche pointe "avance" automatiquement. C'est-à-dire que lorsque vous ajoutez de nouveaux commits, à certains égards, c'est généralement le cas: ajouter de nouveaux commits à son collectif, un peu comme les Borgs de l'ancienne série Star Trek TNG - quelle que soit la branche est ré-ajusté pour pointer vers le nouvel commit.

Ainsi, la principale différence entre une branche et une étiquette est qu’une étiquette ne bouge pas.

Pour voir comment cela fonctionne, considérez un simple dépôt git avec seulement trois commits. Étiquetons ces commits A, B, et C. Le premier commit (A) pointe vers rien, car c'est le premier commit, et branche master pointe vers A:

A   <-- master

Lorsque vous faites le deuxième commit, git crée B ramenant à A, et avance le nom de la branche pour pointer vers B:

A <- B   <-- master

Ensuite, lorsque vous effectuez une troisième validation, git le fait à nouveau pointer vers son commit parent et avance la branche:

A <- B <- C   <-- master

Si vous créez une balise maintenant, cette balise indiquera, par défaut, à commettre C:

A <- B <- C   <-- master
               \- sometag

Si vous faites ensuite un nouvel engagement D, git avance le branche, mais pas le tag:

A <- B <- C <- D   <-- master
           \
            `--------- sometag

Vous pouvez, à tout moment, créer ou supprimer une balise pointant vers une validation particulière:

$ git tag -d sometag

va supprimer tag sometag, après quoi:

$ git tag sometag master~2

ajouterai sometag pointant pour commettre B.1

(Nous venons de prouver qu'une étiquette pouvez bouge toi. La vraie différence est que les tags ne sont pas attendu se déplacer, tandis que les branches sont; et git ne déplacera pas les balises automatiquement.2  Les succursales sont généralement censées évoluer dans une direction "avant", c’est-à-dire si master l'habitude de pointer pour commettre C et maintenant des points à commettre D, commettre C devrait normalement être trouvé en commençant à D et travailler en arrière. Chaque fois que vous déplacez une branche pour que cette règle soit violée, vous "réécrivez l'historique"; voir d'autres articles pour quand cela va bien, et quand ça cause des problèmes aux gens.)

Étiquettes de poussée

Lorsque vous utilisez git push, ce que vous faites vraiment, c’est demander à un autre dépôt git de prendre les nouveaux commits qu’ils n’ont pas, puis définir un ou plusieurs noms - généralement des branches et / ou des balises - pour désigner des commits (un par ) dans la collection résultante.3  Ces noms (branches, tags, etc.) sont appelés "références" en général, mais utilisons simplement "branch" et "tag" pour le moment.

L'argument après git push nomme le dépôt (généralement via un nom "distant", comme origin) à pousser. Si vous l'omettez, git essaiera d'en trouver un, mais si vous voulez ajouter un nom de branche ou de tag, vous devez l'inclure explicitement, car le premier mot ici est supposé être le nom distant. (C'est, git push master essaie d'utiliser master comme un nom distant plutôt qu'un nom de branche.)

Pousser tout vos tags, vous pouvez simplement ajouter --tags à ton git push commander:

git push --tags origin

Pour pousser un spécifique tag, vous pouvez le nommer:

git push origin sometag

tout comme vous pouvez pousser une branche spécifique:

git push origin master

(En fait, ce quatrième argument est un paire de noms, comme master:master ou sometag:sometag, mais il utilise par défaut le même nom des deux côtés dans la plupart des cas.4)

Vous pouvez laisser de côté le nom origin si vous n'en avez pas besoin pour faire tous les arguments, par exemple, git push --tags est le même que git push --tags origin (en supposant que toutes vos poussées vont à origin, en tous cas).

Mettre ensemble

Pour définir une balise dans la télécommande, commencez par la définir localement, avec git tag prénom identifiant de validation. Utilisez le visualiseur que vous souhaitez pour vous assurer qu'il est correctement défini. Puis poussez, avec soit git push origin prénom ou git push --tags.


1le master~2 la syntaxe demande à git de démarrer à la validation trouvée via master, puis sauvegardez deux étapes. Vous pouvez plutôt écrire le SHA-1 brut pour commit B ici.

2Les anciennes versions de git (antérieures à 1.8.4) appliquaient accidentellement des règles de branche à des balises lorsqu’elles poussaient (du côté distant, c’est-à-dire qu’elles laissaient une balise se déplacer s’il s’agissait d’une avance rapide).

3Dans certains cas, vous pouvez pointer un nom vers un "tag annoté", et rien n'empêche un nom de pointer sur un objet "tree" ou "blob" non plus, mais ce n'est pas une configuration normale.

4En fait, la valeur par défaut dst refspec pour une branche est compliqué: cela dépend de votre push.default configuration, et s'il y a un remote.dépôt.push paramètre, et s'il y a une configuration en amont, et ainsi de suite. Pour les tags, les règles sont plus simples puisqu'il n'y a pas de "amont".


37
2017-09-10 00:59



Voici un exemple concret:

git add .
git commit -m "some description"
git tag v0.1.9 # or any other text
git push origin master # push the commit
git push --tags origin # push the tags

7
2017-12-07 21:47



Une fois que vous avez créé le tag (dont vous avez l'air d'avoir terminé), lancez simplement

git push --tags origin

2
2017-09-10 00:57