Git-Tips & Tricks for Newbie

To mark release points and to enable triggering jobs

Listing Your Tags

$ git tag

Tags that match a particular pattern

$ git tag -l "v1.0.*"

Creating Tags

It supports two types of tags: lightweight and annotated.

Annotated Tags

$ git tag -a v1.0.1 -m "my version 0.1"

To see the tag data along with the commit

$ git show v1.0.1

Lightweight Tags

$ git tag v1.0.1

Note : To create a lightweight tag, don’t supply any of the -a, -s, or -m options, just provide a tag name

Tagging Later

Suppose your commit history looks like this:

$ git log --pretty=oneline
64783647951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'branch2'
7f74j3ksi8bd301d84096da251c98a07c7723e65 Update iqfile

you forgot to tag the second, which was at the “Update iqfile” commit.

To tag that commit

$ git tag -a v1.0.2 7f74j3k

You can see that you’ve tagged the commit:

$ git tag
v1.0.1
v1.0.2

Push tags

To explicitly push tags to a shared server after you did git add them.

$ git push origin v1.0.3

syntax: git push origin <tagname>

If you have a lot of tags that you want to push up at once, you can also use the --tags

$ git push origin --tags

Deleting Tags

To delete a tag on your local repository, you can use git tag -d <tagname>.

$ git tag -d v1.0.1

Note that this does not remove the tag from any remote servers. There are two common variations for deleting a tag from a remote server.

The first variation is git push <remote> :refs/tags/<tagname>:

And the second variation Intuitive way to delete directly remote tag is with

$ git push origin --delete <tagname>

To throws away all your uncommitted changes

$ git reset — hard

It is a potentially dangerous command since it throws away all your uncommitted changes. For safety, you should always check that the output of git status is clean (that is, empty) before using it.

When you do git reset --hard <SOME-COMMIT> then Git will:

• Make your current branch (typically master) back to point at <SOME-COMMIT>.
• Then make the files in your working tree and the index (“staging area”) the same as the versions committed to <SOME-COMMIT>.

Checking out Tags

git checkout of that tag, although this puts your repository in “detached HEAD” state, which has some ill side effects:

$ git checkout v1.0.2
Note: switching to 'v1.0.2'.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

git switch -c <new-branch-name>

Or undo this operation with:

git switch -

If you’re fixing a bug on an older version, for instance — you will generally want to create a branch:

$ git checkout -b branch2 v2.0.0

If you do this and make a commit, your version2 branch will be slightly different than your v2.0.0 tag since it will move forward with your new changes.

To checkout a new branch:

git checkout -b <branch>

Edit files, add and commit. Then push with the -u (short for --set-upstream) option:

git push -u origin <branch>

Merging changes from master into my branch

git checkout custom_branch && git rebase master

This will update custom_branch with changes from master branch.

Don’t forget to make sure master is up to date first. git pull

This is also possible with git checkout custom_branch && git merge master

Merge & Rebase

• Merge takes all the changes in one branch and merges them into another branch in one commit.
• Rebase says I want the point at which I branched to move to a new starting point

Merge

• Let’s say you have created a branch for the purpose of developing a single feature. When you want to bring those changes back to master, you probably want merge (you don’t care about maintaining all of the interim commits).

Rebase

• A second scenario would be if you started doing some development and then another developer made an unrelated change. You probably want to pull and then rebase to base your changes from the current version from the repository.

cheers!