Week 3

Day 4 - "Finding a good reference point"

Tag you're it!

During software development, a project will generally get to a point where it is ready to be released to people outside of the development team. When this grand day occurs, it is crucial that both the developers and the users have a reference point with which to refer to the state of the code. Having a code name or a version number means that within a very short period of time, both parties can converse about a problem, safe in the knowledge that they are on the same page.

In most version control systems, the word tagging is used to describe a reference point in the code's history. A tag will usually refer to a single commit and labels that particular commit with a name that is easier to remember than a standard version number or SHA-1 hash. The tag name used can be a codename, or a version number. Often people will follow a simple numbering scheme, like v1.9.

In this example, the 1 may refer to the major version number, and will denote a family of versions, often only changing a few times in a projects lifetime. The 9 is a minor version number and can refer to a much more frequent release schedule. You may also see textual items being appended to this version string, like rc, b, and a, denoting Release Candidate, Beta and Alpha respectively.

Git implements tags in a very elegant way. A tag is simply a label in Git that points to a single commit object. The tag name can then be used in place of the SHA-1 to refer to a point in the repositories history. Due to the simplicity of tags, it is also possible and very simple to tag a commit that occurred way into the past. Let us take a look at a simple tag example. We will make the current point in the repository v1.0a.

john@satsuki:~/coderepo$ git tag v1.0a

john@satsuki:~/coderepo$

On its own, this output from git tag doesn't really tell us much, but running the following, shows us a little more information

john@satsuki:~/coderepo$ git rev-parse v1.0a

a022d4d1edc69970b4e8b3fe1da3dccd943a55e4

john@satsuki:~/coderepo$

By running the git rev-parse with the tag name v1.0a, Git has returned us the SHA-1 hash of the commit we were referring to. If we look back up at the earlier output, we can see that the most recent commit into the repository was indeed a022d4d1edc69970b4e8b3fe1da3dccd943a55e4. To give us something to work with, let's tag the commit 163f061 with the tag name v0.9.

john@satsuki:~/coderepo$ git tag v0.9 163f061

john@satsuki:~/coderepo$

Now, we can do the following;

john@satsuki:~/coderepo$ git diff v0.9..v1.0a

diff --git a/my_second_committed_file b/my_second_committed_file

index 3ad4cc3..c9887f8 100644

--- a/my_second_committed_file

+++ b/my_second_committed_file

@@ -1 +1 @@

-Change1

+Changed this file completely

diff --git a/my_third_committed_file b/my_third_committed_file

new file mode 100644

index 0000000..5d27866

--- /dev/null

+++ b/my_third_committed_file

@@ -0,0 +1 @@

+Addition to the line

john@satsuki:~/coderepo$

Notice that instead of using the dynamic reference HEAD, we have now used the tag names v0.9 and v1.0a to refer to our previous commits and have returned the combined diff output of all the changes which occurred between the two.

You can find out more about tags and how to specify more information in the After Hours section at the end of this Week.

Note - A little about tags

Tags are great and you should most definitely use them in your repositories to make good reference points, but there is one point that you should always remember. Though we have not yet delved into the realms of remote branches, it is important to note that once you have tagged a certain commit, and pushed that to the repository, you cannot then remove that tag if someone else clones, or pulls your tags from that remote branch. This will all become clearer during the next week, but fits in with the overall ethos of working with version control systems, if someone has seen the past, you should not EVER change it.