Scribd
Upload
27 views17 pages

Tagging

Uploaded by

saurabhpandeychp1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
27 views17 pages

Tagging

Uploaded by

saurabhpandeychp1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 17

Tagging in

git
INT 331
• Tags are ref's that point to specific
points in Git history.
• Tagging is generally used to capture a
point in history that is used for a
marked version release (i.e. v1.0.1).

• A tag is like a branch that doesn’t


change.

• Unlike branches, tags, after being


created, have no further history of
commits.
Creating a
tag
• To create a new tag execute the
following command:

git tag <tagname>

• Replace < tagname > with a


semantic identifier to the state of
the repo at the time the tag is
being created.

• A common pattern is to use


version numbers like git tag
Two Types of TAG
Git supports two different types of
tags,

1.Annotated

2. lightweight tags
• Lightweight tags and Annotated tags differ in
the amount of accompanying meta data they
store.
• A best practice is to consider Annotated
tags as public, and Lightweight tags as
private.

• Annotated tags store extra meta data such as:


the tagger name, email, and date.

• This is important data for a public release.

• Lightweight tags are essentially


'bookmarks' to a commit, they are just a
name and a pointer to
a commit, useful for creating quick links to
relevant commits.
Annotated
tags
• Annotated tags are stored as full objects in
the Git database.
• To reiterate, They store extra meta data
such as: the tagger name, email, and
date.

• Similar to commits and commit


messages Annotated tags have a
tagging message.

• Additionally, for security, annotated


tags can
be signed and verified with GNU
Privacy Guard
(GPG). Suggested best practices for
git tagging
Command
is :

• git tag -a
v1.4
Annotated tag with
message

• git tag -a v1.4 -m "my version


1.4"
Lightweight tags

• Lightweight tags are created with


the absence of the -a, -s, or -m
options.

• Lightweight tags create a new tag


checksum and store it in the .git/
directory of the project's repo.

• git tag v1.4-lw


Listing
tags
• To list stored tags in a repo execute
the following:

• git
tag
Tagging old
commits
• The previous tagging examples have
demonstrated operations on implicit
commits.

• By default, git tag will create a tag on


the commit that HEAD is referencing.

• Alternatively git tag can be passed as a ref


to a specific commit. This will tag the
passed commit instead of defaulting to
HEAD. To gather a list of older commits
execute the git log command.
• git tag a v1.2
150279579
ReTagging/Replacing old
• tags
If you try to create a tag with the same identifier as
an existing tag, Git will throw an error like:

• fatal: tag 'v0.4' already exists

• Additionally if you try to tag an older commit


with an existing tag identifier Git will throw the
same error.

• In the event that you must update an existing tag,


the -f FORCE option must be used.

• git tag -a -f v1.4 15027957951


Sharing: Pushing tags to
remote
• Sharing tags is similar to pushing
branches.

• By default, git push will not push tags.

• Tags have to be explicitly passed to


git push.

• $ git push origin v1.4


• To push multiple tags simultaneously
pass the --tags option to git push
command.

• When another user clones or pulls a


repo they will receive the new tags
Checking out
tags
• You can view the state of a repo at a tag by using
the git checkout command.
• git checkout v1.4
• The above command will checkout the v1.4 tag.
This puts the repo in a detached HEAD state.

• This means any changes made will not update the


tag.

• They will create a new detached commit. This new


detached commit will not be part of any branch
and will only be reachable directly by the commits
SHA hash. T
• herefore it is a best practice to create a new branch
anytime you're making changes in a detached HEAD
state.
Deleting
tags
• Deleting tags is a
straightforward operation.

• Passing the -d option and a tag


identifier to git tag will delete the
identified tag.

• $ git tag -d v1

You might also like