Git tag · issue #31 · xgqfrms/git

Additional Commands

Listing tags —
Use the command whenever you want to list all the existing tags, or you could filter the list with , where acts as a wildcard. It will return a list of tags marked with .

You will notice that when you call you do not get to see the contents of your annotations. To preview them you must add to your command: .

The command lists all existing tags with maximum 3 lines of their tag message. By default only shows the first line.

Tag details —
This command presents you with tag details and information from the commit that was tagged.

It prints the author’s name, creation date, message, GnuPG signature if present and the information about the referenced commit. If the tag is lightweight, the output will be limited to the information about the referenced commit.

Editing tags —
If you try to create a tag with the same identifier as an existing tag, Git will throw an error: .

Instead of having to delete it and re-add the tag you can simply replace it while keeping the existing description. Choose the place in your commit history with where you want the tag moved to and add or to your command.

If you have already pushed the tag to the server and want to fix that, first make sure your local version of the tag is correct before you run the following command: .

Deleting tags —
Generally, there is no reason to delete the tags because they are inexpensive and don’t use any resources unless you have mistakenly created a tag pointing to the wrong commit.

In case the tag has been already pushed and you need to remove it from remote repository run: .

Publishing tags —
A tag is just a reference to your local repository and it is not automatically pushed to the remote repository with the rest of the code. Instead, you can the tag individually, or you can run which will push all tags at once. It can be done similarly to pushing the branches:

Sorting tags —
When looking at a project with lots of tags, using the can come in handy. Supported types are:

(sorts in a lexicographic order),
or (here tag names are treated as versions).

Here I am listing all tags which name starts with «v» by their versions.

Isn’t git tag the same as #tag in social media, but in its own way? It helps you return and list all your previous release!

While you are here, please note that Kolosek is always happy to help and bring your idea to life. If you need a hand, you can always reach out to Kolosek via social media. , perhaps?

git pr

Checks out a pull request from GitHub

$ git pr 226
From https://github.com/tj/git-extras
 *        refs/pulls/226/head -> pr/226
Switched to branch 'pr/226'

To use a remote other than , e.g. if you’re working in a fork, specify it as the second parameter:

$ git pr 226 upstream
From https://github.com/tj/git-extras
 *        refs/pulls/226/head -> pr/226
Switched to branch 'pr/226'

You can also checkout a pull request based on a GitHub url

$ git pr https://github.com/tj/git-extras/pull/453
From https://github.com/tj/git-extras
 *          refs/pull/453/head -> pr/453
Switched to branch 'pr/453'

To remove all local pull request branches, provide the magic parameter:

$ git pr clean
Deleted branch 'pr/226' (was 1234567).

DISCUSSION

On Re-tagging

What should you do when you tag a wrong commit and you would want to re-tag?

If you never pushed anything out, just re-tag it. Use «-f» to replace the old one. And you’re done.

But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:

The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have «version X», but they actually have
different
«X»‘s. So just call it «X.1» and be done with it.

The insane thing. You really want to call the new version «X» too,
even though
others have already seen the old one. So just use
git tag -f
again, as if you hadn’t already published the old one.

However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.

If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying:

Ok, I messed up, and I pushed out an earlier version tagged as X. I
then fixed something, and retagged the *fixed* tree as X again.

If you got the wrong tag, and want the new one, please delete
the old one and fetch the new one by doing:

        git tag -d X
        git fetch origin tag X

to get my updated tag.

You can test which tag you have by doing

        git rev-parse X

which should return 0123456789abcdef.. if you have the new version.

Sorry for the inconvenience.

Does this seem a bit complicated? It should be. There is no way that it would be correct to just «fix» it automatically. People need to know that their tags might have been changed.

On Automatic following

If you are following somebody else’s tree, you are most likely using remote-tracking branches (eg. refs/remotes/origin/master). You usually want the tags from the other end.

On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to get tags from there. This happens more often for people near the toplevel but not limited to them. Mere mortals when pulling from each other do not necessarily want to automatically get private anchor point tags from the other person.

Linus, please pull from

        git://git..../proj.git master

to get the following updates...

becomes:

$ git pull git://git..../proj.git master

In such a case, you do not want to automatically follow the other person’s tags.

One important aspect of Git is its distributed nature, which largely means there is no inherent «upstream» or «downstream» in the system. On the face of it, the above example might seem to indicate that the tag namespace is owned by the upper echelon of people and that tags only flow downwards, but that is not the case. It only shows that the usage pattern determines who are interested in whose tags.

A one-shot pull is a sign that a commit history is now crossing the boundary between one circle of people (e.g. «people who are primarily interested in the networking part of the kernel») who may have their own set of tags (e.g. «this is the third release candidate from the networking group to be proposed for general consumption with 2.6.21 release») to another circle of people (e.g. «people who integrate various subsystem improvements»). The latter are usually not interested in the detailed tags used internally in the former group (that is what «internal» means). That is why it is desirable not to follow tags automatically in this case.

It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking each other’s progress by having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.

On Backdating Tags

If you have imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able to specify the date to embed inside of the tag object; such data in the tag object affects, for example, the ordering of tags in the gitweb interface.

To set the date used in future tag objects, set the environment variable GIT_COMMITTER_DATE (see the later discussion of possible values; the most common form is «YYYY-MM-DD HH:MM»).

For example:

$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1

git fork

Fork the given github <repo>. Like clone but forks first.

$ git fork https://github.com/LearnBoost/expect.js

or just:

$ git fork LearnBoost/expect.js

Does the following:

forks the repo (prompts for github username and pass)
clones the repo into the current directory
adds the original repo as a remote so can track upstream changes
all remotes refs use git over ssh if configured, otherwise https will be used

$ cd expect.js && git remote -v
origin          git@github.com:<user>/expect.js (fetch)
origin          git@github.com:<user>/expect.js (push)
upstream        git@github.com:LearnBoost/expect.js (fetch)
upstream        git@github.com:LearnBoost/expect.js (push)

OPTIONS

-a, —annotate

Make an unsigned, annotated tag object

-s, —sign

Make a GPG-signed tag, using the default e-mail address’s key.

-u <keyid>, —local-user=<keyid>

Make a GPG-signed tag, using the given key.

-f, —force

Replace an existing tag with the given name (instead of failing)

-d, —delete

Delete existing tags with the given names.

-v, —verify

Verify the gpg signature of the given tag names.

-n<num>

<num> specifies how many lines from the annotation, if any, are printed when using -l. The default is not to print any annotation lines. If no number is given to
-n, only the first line is printed. If the tag is not annotated, the commit message is displayed instead.

-l <pattern>, —list <pattern>

List tags with names that match the given pattern (or all if no pattern is given). Running «git tag» without arguments also lists all tags. The pattern is a shell wildcard (i.e., matched using fnmatch(3)). Multiple patterns may be given; if any of them matches, the tag is shown.

—sort=<key>

Sort based on the key given. Prefix
—
to sort in descending order of the value. You may use the —sort=<key> option multiple times, in which case the last key becomes the primary key. Also supports «version:refname» or «v:refname» (tag names are treated as versions). The «version:refname» sort order can also be affected by the «versionsort.prereleaseSuffix» configuration variable. The keys supported are the same as those in
git for-each-ref. Sort order defaults to the value configured for the
tag.sort
variable if it exists, or lexicographic order otherwise. See
git-config(1).

—column, —no-column

Display tag listing in columns. See configuration variable column.tag for option syntax.—column
and
—no-column
without options are equivalent to
always
and
never
respectively.

This option is only applicable when listing tags without annotation lines.

—contains

Only list tags which contain the specified commit (HEAD if not specified).

—points-at <object>

Only list tags of the given object.

-m <msg>, —message=<msg>

Use the given tag message (instead of prompting). If multiple
-m
options are given, their values are concatenated as separate paragraphs. Implies
-a
if none of
-a,
-s, or
-u <keyid>
is given.

-F <file>, —file=<file>

Take the tag message from the given file. Use
—
to read the message from the standard input. Implies
-a
if none of
-a,
-s, or
-u <keyid>
is given.

—cleanup=<mode>

This option sets how the tag message is cleaned up. The
<mode>
can be one of
verbatim,
whitespace
and
strip. The
strip
mode is default. The
verbatim
mode does not change message at all,
whitespace
removes just leading/trailing whitespace lines and
strip
removes both whitespace and commentary.

—create-reflog

Create a reflog for the tag.

The name of the tag to create, delete, or describe. The new tag name must pass all checks defined by
git-check-ref-format(1). Some of these checks may restrict the characters allowed in a tag name.

The object that the new tag will refer to, usually a commit. Defaults to HEAD.

A string that interpolates
%(fieldname)
from the object pointed at by a ref being shown. The format is the same as that of
git-for-each-ref(1). When unspecified, defaults to
%(refname:strip=2).

—merged

Description

Add a tag reference in , unless is given to delete, list or verify tags.

Unless is given, the named tag must not yet exist.

If one of , , or is passed, the command creates a object, and requires a tag message. Unless or is given, an editor is started for the user to type in the tag message.

If or is given and , , and are absent, is implied.

Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.

A GnuPG signed tag object will be created when or is used. When is not used, the committer identity for the current user is used to find the GnuPG key for signing. The configuration variable is used to specify custom GnuPG binary.

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like ) will ignore lightweight tags by default.

git stamp

Stamp the last commit message

Commit message is

Fix timezone bug

Reference the issues numbers from your bug tracker

$ git stamp Issue FOO-123

commit 787590e42c9bacd249f3b79faee7aecdc9de28ec
Author: Jack <jack@work.com>
Commit: Jack <jack@work.com>

    Fix timezone bug

    Issue FOO-123

$ git stamp Issue FOO-456 \#close

commit f8d920511e052bea39ce2088d1d723b475aeff87
Author: Jack <jack@work.com>
Commit: Jack <jack@work.com>

    Fix timezone bug

    Issue FOO-123

    Issue FOO-456 #close

Link to its review page

$ git stamp Review https://reviews.foo.org/r/4567/

commit 6c6bcf43bd32a76e37b6fc9708d3ff0ae723c7da
Author: Jack <jack@work.com>
Commit: Jack <jack@work.com>

    Fix timezone bug

    Issue FOO-123

    Issue FOO-456 #close

    Review https://reviews.foo.org/r/4567/

Replace previous issues with a new one
(Note that the identifier is case insensitive)

$ git stamp --replace issue BAR-123

commit 2b93c56b2340578cc3478008e2cadb05a7bcccfa
Author: Jack <jack@work.com>
Commit: Jack <jack@work.com>

    Fix timezone bug

    Review https://reviews.foo.org/r/4567/

    issue BAR-123

Branch

JGit provides a series of commands that work with branches.

To get the name of the current checked out branch issue the following command:

You create a branch with the method. You have to specify the name of the branch with . updates the files in the working tree to match the branch in the repository.

You can create and checkout a branch with the method when you call . This option automatically creates the branch if it does not exist yet.

Usually, after you have finished working on a branch, you want to merge it with another branch.

First checkout the branch you want to merge into

Then get an ObjectId to the branch and call the method. As an argument, you specify the branch you want to merge with .

The merge command either does a fast-forward merge, by updating the branch pointer without creating a merge commit or incorporates the changes from the other branch into the current branch and creates a commit. If you always want to create a merge commit, disable fast-forward with . And if you don’t want to create a commit, disable it with .

The method lists all branches. By default, it only returns local branches. You can change that with . returns local and remote branches, returns only remote branches.

renames an existing branch.

The method deletes a branch. This command fails when the specified branch is checked out, so you have to check out another branch first.

By default, checks whether the branch you want to delete is already merged into the current branch. If the branch is not merged, deletion will be refused. You change this behavior by calling , in that case, no check will be performed, and the branch will be deleted regardless if he’s merged or not.

git reauthor

Rewrite history to change author’s identity.

$ git reauthor --old-email jack@perso.me --correct-email jack@work.com --correct-name 'Jack Foobar'

$ git reauthor --old-email jack@perso.me --use-config

$ git reauthor --old-email jack@perso --correct-email jack@perso.me

$ git reauthor --old-email jack@perso.me --correct-email jack@work.com --type committer

Set Jack’s identity as the only one of the whole repository

$ git reauthor --all --correct-email jack@perso.me --correct-name Jack

Set Jack as the only committer of the whole repository (keeps authors)

$ git reauthor --all --correct-email jack@perso.me --correct-name Jack --type committer

Init

The command creates an empty Git repository. This is the first command you run when you want to put a new project under Git control.

To initialize a new Git repository with JGit, you call the static method. The method returns an instance of . Make sure that you close a instance with the method. The Git class implements AutoCloseable so you can wrap the call in an automatic resource management block.

tells the method where to create the new Git repository. creates the directory if it does not exist yet. You may call on an existing Git repository, it does not delete the history.

As mentioned before, all methods from return a command class. In case of this is the class. Instead of method chaining, you assign the command class to a variable and then call methods one after the other.

It does not matter which style you use. There is no difference in functionality. Most examples in this blog post use the chained methods style.

пример

Удалите тег на любом пульте, прежде чем нажимать
Замените тег, чтобы он ссылался на самую последнюю фиксацию
Отправьте тег в удаленный источник

14 Это работает только в том случае, если вы не сбросили код со своей машины. Если да, лучший ответ — «в мире много цифр», потому что, вероятно, это не стоит хлопот. 41 Если вы уже отправили свой тег, вы все равно можете обновить удаленный тег с помощью принудительного нажатия 3 Вам не нужно использовать принудительную отправку, если ссылка на тег может быть быстро перенаправлена в новое место. 11 Здесь и в документации не упоминается, что это действительно перемещает сообщение тега, если новое сообщение не передается

9 Обратите внимание, что в # 3 собирается нажимать теги, и ветвь, если вы внесли какие-либо изменения в нее локально. Просто используйте если все, что вам нужно, это нажимать теги

Точнее, вы должны принудительно добавить тег, а затем нажать с опцией —tags и -f:

Подводя итог, если ваш пульт называется и ты работаешь над ветка:

Строка 1 удаляет тег в локальном env.
Строка 2 удаляет тег в удаленном env.
Строка 3 добавляет тег к другому коммиту
Строка 4 передает изменение на удаленный

Вы также можете поменять строку 4 на чтобы протолкнуть все изменения с тегами из ваших локальных изменений.

Основываясь на ответах @ stuart-golodetz, @ greg-hewgill, @eedeep, @ ben-hocking, комментариях под их ответами и комментариях NateS под моим ответом.

Удалить с помощью а затем воссоздайте его в правильном коммите.

3 @eedeep: Я думаю, что ответ Грега здесь лучше, если честно.
1 Будьте проще. Удалите его, сделайте то, что делали раньше, снова.
1 Это должен быть принятый ответ из-за его простоты. Также не использует чрезмерно -f force.

Я стараюсь избегать некоторых вещей при использовании Git.

Используя знания о внутреннем устройстве, например ссылки / теги. Я стараюсь использовать только задокументированные команды Git и избегаю использования вещей, требующих знания внутреннего содержимого каталога .git. (То есть я отношусь к Git как к пользователю Git, а не как к разработчику Git.)
Применение силы, когда она не требуется.
Переусердствовать. (Нажимая ветку и / или множество тегов, чтобы получить один тег там, где я хочу.)

Итак, вот мое ненасильственное решение для изменения тега, как локально, так и удаленно, без знания внутреннего устройства Git.

Я использую его, когда в исправлении программного обеспечения возникает проблема, и его необходимо обновить / переиздать.

это пример удаленного имени, это пример имени тега, и образец фиксации.

Я оставлю здесь еще одну форму этой команды, которая соответствует моим потребностям. Был тег что я хотел переехать.

А потом:

Другой способ:

Переместить тег в удаленное репо. (При необходимости замените HEAD любым другим.)

Получить изменения обратно.

Это более «транзакционный», чем другие ответы.

Псевдоним для перемещения одного тега в другой коммит.

В вашем примере, чтобы переместить фиксацию с хешем e2ea1639, выполните: .

Для вставленных тегов используйте .

Оба псевдонима сохраняют исходную дату и сообщение. Если вы используете вы потеряли исходное сообщение.

Сохраните их на своем файл

Если вы хотите переместить аннотированный тег, изменив только целевую фиксацию, но сохранив сообщение с аннотацией и другие метаданные, используйте:

использование: moveTag

Вышеупомянутая функция была разработана со ссылкой на teerapap / git-move-annotated-tag.sh.

1 Похоже, в этом больше нет необходимости: git tag -f -a my_tag уже сохраняет сообщение предыдущего сообщения (с git версии 2.11.0).

10 ответов

Лучший ответ

Используйте параметр , чтобы :

Вероятно, вы захотите использовать вместе с для принудительного создания аннотированного тега вместо неаннотированного.

Примере

Удалите тег на любом пульте, прежде чем нажимать
Замените тег, чтобы он ссылался на самую последнюю фиксацию
Отправьте тег в удаленный источник

1342

Greg Hewgill
5 Дек 2019 в 20:44

Если вы используете github и хотите, чтобы изменения были зафиксированы для выпуска (например, вы обнаружите, что не фиксируют что-либо после создания выпуска), вы можете использовать

После этой команды github удалите ваш тег, и ваш релиз станет черновиком. Это означает, что вы можете воссоздать выпуск и выбрать фиксацию. Ваши файлы и ваше сообщение будут сохранены.

Константин Золин
27 Апр 2021 в 03:37

Использование: moveTag

Вышеупомянутая функция была разработана со ссылкой на teerapap / git-move-annotated-tag.sh.

vossad01
8 Май 2018 в 13:18

Другой способ:

Переместить тег в удаленное репо. (При необходимости замените HEAD любым другим.)

Получить изменения обратно.

Алексей Югов
15 Мар 2018 в 09:51

Псевдоним для перемещения одного тега в другой коммит.

В вашем примере, чтобы переместить фиксацию с хешем e2ea1639, выполните: .

Для вставленных тегов используйте .

Оба псевдонима сохраняют исходную дату и сообщение. Если вы используете , вы потеряете исходное сообщение.

Сохраните их в своем файле

Juan Antonio Tubío
21 Май 2015 в 20:02

Я оставлю здесь еще одну форму этой команды, которая мне подходит. Был тег , который я хотел переместить.

А потом:

Nakilon
19 Сен 2017 в 00:14

Я стараюсь избегать некоторых вещей при использовании Git.

Используя знания о внутреннем устройстве, например ссылки / теги. Я стараюсь использовать только задокументированные команды Git и избегаю использования вещей, требующих знания внутреннего содержимого каталога .git. (То есть я отношусь к Git как к пользователю Git, а не как к разработчику Git.)
Применение силы, когда она не требуется.
Переусердствовать. (Нажимая ветку и / или множество тегов, чтобы получить один тег там, где я хочу.)

Итак, вот мое ненасильственное решение для изменения тега как локально, так и удаленно, без знания внутреннего устройства Git.

— это пример удаленного имени, — образец имени тега, а — образец фиксации.

Ivan
10 Июл 2019 в 11:34

Удалите его с помощью , а затем воссоздайте его с правильной фиксацией.

Stuart Golodetz
8 Ноя 2011 в 00:34

Подводя итог, если ваш пульт называется и вы работаете над веткой :

Строка 1 удаляет тег в локальном окружении.
Строка 2 удаляет тег в удаленном окружении.
Строка 3 добавляет тег к другому коммиту.
Строка 4 передает изменение на удаленный

Вы также можете заменить строку 4 на , чтобы передать все изменения с тегами из ваших локальных изменений.

На основе ответов @ stuart-golodetz, @ greg-hewgill, @eedeep, @ ben-hocking, комментариев под их ответами и комментариев NateS под моим ответом.

227

Nat
9 Дек 2016 в 09:53

Точнее, вы должны принудительно добавить тег, а затем нажать с опцией —tags и -f:

292

Daniel
15 Янв 2014 в 00:40

Build & release

Github Markdown rendering

Before pushing try to always verify that the modifications pushed in MD files will be correctly rendered by Github.
For that purpose you can use grip.

Normal build

mvn -Prun-its clean install

or using docker

Linux:
Windows:
Old linux command:

build and filter some IT tests

mvn -Prun-its clean install «-Dinvoker.test=issues/issue-36*»

If needed, one can also add in above docker command a volume sharing
with the maven local repository by adding something like for example .

Release

: this will simulate a full build for oss delivery (javadoc, source attachement, GPG signature, …)
: tag the current HEAD with the given tag name. The tag is signed by the author of the release. Adapt with gpg key of maintainer.
- Matthieu Brouillard command:

git repl

Git read-eval-print-loop. Lets you run commands without typing ‘git’.

Commands can be prefixed with an exclamation mark (!) to be interpreted as
a regular command.

Type or to end the repl session.

$ git repl
git version 2.9.2
git-extras version 3.0.0
type 'ls' to ls files below current directory,
'!command' to execute any command or just 'subcommand' to execute any git subcommand

git (master)> ls-files
History.md
Makefile
Readme.md
bin/git-changelog
bin/git-count
bin/git-delete-branch
bin/git-delete-tag
bin/git-ignore
bin/git-release

git (master)> !echo Straight from the shell!
Straight from the shell!

git (master)> quit