Version Control Using Git

Git Foundations - Commit History and Ref Log

I stopped by a friend’s house and picked up the book ‘Pragmatic Version Control Using Git’ by Travis Swicegood. I use git everyday but do I really know what I am using and why I am using it? While the book is very basic and foundational knowledge that one could easily dismiss as being obvious, I decided to read through it because when it comes to programming, it is important to keep a strong foundation. Who knows, reading this book may save me a few hours to a few days in trying to sort out an easily-fixed issue.

It is important to know that through git, all of our local systems have a full copy of the commit history and that we can access this in two ways;

• Through the commit history • Through the ref log

###Commit History

The commit history shows all the commits made in the repository and can be accessed by entering $git log. The commits will appear in reverse chronological order, with the most recent commit coming first and can be accessed individually with $git log[1]. All commits will all show its SHA-1 checksum, the author’s name, the date it was committed, and the commit message. This is why commit messages are so important! They show tell you in laymen’s terms what happened and the reasonings for the commit.

When it comes to programming, you can easily rewrite…history through rebasing and fast forwarding. Like the Time Lords from Doctor Who, with the git log and the knowledge of rebasing, you have history at your fingertips and you can modify and change not only the git log, but the files and changes made within and how it is presented. So, as a friend pointed out, the purpose of the commit message is to narrate the history at that merging of the branch. You can grep through commit history and find the history in front of you. You can link to the issues, see the discussion, can see what happened, etc and then change it if needed.

Also, the commit message is an opportunity for the programmer to not take responsibility for the potential code failure by explaining the reason for the commit, the constraints one was working under, and what the proposed solution was. It is the tne chance to forever and ever commit to posterity why you are committing the code you are committing.

###Ref Log

The ref log, when compared to the commit history, is a much blunter instrument. Unlike the commit history, the ref log is local to the machine and stores every state that the machine has been in. However, the ref log has very limited space, and once the space is filled, new information will rewrite the old information – permanently.

If you’ve done something to break the entire repository and you are freaking out, the best course of action is to stop, take a deep breath, relax, and potentially open up your reflog. You can do this by entering $git reflog. The head and head number, the SHA-1 checksum, and event causing the change of state are recorded.

The ref log also shows in reverse chronological order, with the most recent change of state at the bottom of the list. It is considered a blunt tool because it can only really be used to roll back the entire state of the repository and without more information, it can be difficult to figure out which state you should roll back to.

Dialogue & Discussion