Tagging in Git

Git offers tagging capability, just like Subversion. Tagging is just like a checkpoint to denote a certain stage in the repository's version, perhaps to highlight some important event. Let's say you want to tag the repository as version 1.0, once some major changes were performed. Or perhaps tag the repository as v1.6.3 when a certain bug was fixed.

Let's see a quick illustration. Go to your repository and type the following :

git tag -a v1.0 -m "First version"

Now this has saved you tag as v1.0. You can see the tags by using the following command :

git describe --tags

v1.0

Also, you can see what changes were performed in the v1.0 by typing the foll. command :

git show v1.0

This will show all the committed changes included in the v1.0

Track file changes in Git

In Git, it is possible to find out which user did what changes in a specific file. The command to do so is git blame. Go to your git repository and type the following :

git blame <file-name>

Eg : git blame Test.sh

It will display the list of exact specific changes committed by all the users who made changes to the file Test.sh.

Note : It also shows the user's time zones. This can be helpful to track the times when the changes were performed, if the git repository is shared by multiple users across different geographies.

Stashing changes in Git

Guys, this is a post discussing the simple concept of "stashing" in Git. Let's say you are working on some changes in Git. However, before committing your changes, you are asked to work on something else urgently. Git gives you the ability to immediately shift your focus and keep your changes in a "stash", which can be committed later.

Let's try a simple example :

Assuming you have git installed and a repository to work on.

Go to the Git repository and create a new file : vi " Test.rtf"

Now, add the file to the staging list by using the command

git add "Test.rtf"

Note that now, the Test.rtf file is added to the staging list and is not yet committed. Lets say you don't want to commit your changes as yet. So you can stash your changes temporarily by using the following command.

git stash 

You will see a message like this :

Saved working directory and index state WIP on master: 4bed021 Added Test.rtf file
HEAD is now at 4bed021 Added Test.rtf file

You can view the stash list by using the following command :

git stash list

You'll see something like :

stash@{0}: WIP on master: 4bed021 Added Test.rtf file

Suppose you make multiple changes and stash un-committed changes, you can see the multiple changes when you run the command "git stash list"

Eg : 

stash@{0}: WIP on master: 385553f added 2 new files
stash@{1}: WIP on master: 4bed021 Added Test.rtf file

Sometime later when you are ready to commit your changes, all you have to do is pop the stash list

Type "git stash pop". This will pop the first element from the list i.e stash@{0} and make it ready to be committed.

In other words, stash is like an array stack with multiple elements (i.e changes) in it. When you pop the stash, the last element will be popped first (similar to LIFO - Last In First Out function).

You can then commit these changes using

git commit . -m "Adding pre-stashed changes"

So all your -ex stashed changes are now committed. Stashing can come in very handy if you have to work on something else before committing your changes. This is one of the strengths of Git versioning.