What is this post not for?
Since it was released, Git revolutionized the version control management. Nowadays it is an industry standard being used by a huge number of companies of all sizes.
In Digital Natives, we use Git in all our projects. It provides amazing features and great flexibility of use.
Well, you can find a lot of information about Git out there. Books, tutorials, technical documents, stack overflow questions, etc. So, this is not to teach you how to use it and some level of familiarity assumed with Git.
What is this post for?
Furthermore, it’s not the purpose to present eccentric commands that you will read, find awesome and forget in 10 minutes.The greatest motivation for this post is to improve your work with Git on a daily basis. For that, I’ll try to clarify some basic Git concepts and show why it’s important to have a good grasp on them.
The idea is to show concepts in a rather loose way. We are not interested in the most precise definitions, but in a simple and comprehensible way to see things.
Well, if you have ever used Git (or many other version control systems) you have created commits. What does Git store when you commit something?
If you said “the code I write”, you are in the right path! You might not know, but commits are just one of the objects Git works with. Let’s check what the official Git documentation says.
Git is a content-addressable filesystem. Great. What does that mean? It means that at the core of Git is a simple key-value data store.
That does not even cite code or commits! That’s because these are built on top of the key-value store. And for a key-value store, you need unique keys. Keep that in mind as we will come back to this soon.
So what does this mean? What happens when you create a new commit? What a commit is made of?
It has, for example, commit message, commiter reference, commit date, commit author, author date, the “code you wrote” and the commit parents.
I don’t want to go into details on the internals of how the commit is represented. However, when you create a new commit, you are just putting a commit object in Git’s key-value store. And it’s interesting to mention that by “changing” any part of the commit, you get a new commit object with a new key. So you never really change a commit, but you create a new commit based on an existing one.
One could have trouble choosing a standard or just want some guidance when writing a commit. If you face any of these, you can try installing the fit-commit gem. It will install a Git hook that will list where your messages don’t follow the widely accepted guidelines.
Some people see commit messages as something not so important in a commit. In fact, as it is not part of the code, it doesn’t affect if the implementation works or not. So why should you care about it?
Commit messages can present the context on which the code was written. For example, suppose a business rule of your system changed and you should give more permissions to guest users of a web application. On the commit you make this change, you can give the message. “Give more permissions to guest users”
Isn’t it obvious the change is about that? It can be now, but will it be in the future? Let’s say after 1 month, a strange behavior is found in this same web application. One page sometimes raises an error. If you check the commits on this page, you can see one with the previous message about the guest users. That gives you a very good tip that the bug might be related to the guest user’s interaction.
Let’s assume that normally to discover the cause of the bug, you use some of Git’s features. However, the commit you found had a message like “Update on business logic”. Would it worth anything to be a Git guru? Would you get any valuable information on the bug with this commit message?
Commit messages serve as basic documentation directly attached to a piece of code. Think of it this way, if you spend one extra minute writing a better commit message, you can save hours in a debugging process.
There are plenty of resources and standards on how good commit messages should be. If you or your team adopt one standard and stick to it, that’s more than enough.
I use Git, do I need anything else?
As you must have realized right now, Git is awesome. However, sometimes it may not be enough by its own. There are several projects that add specific functionality to Git. I’ll list here some that I consider essential and that you should be using. Before that, it’s important to remind you about Git hooks. It is a powerful feature of Git that lets you run small scripts before or after git commands.
The first is pre-commit. This is a very cool gem that gives you some passive magic skills to check your modifications before committing. It is a hook that runs before your commit action and looks for things that you might not want to commit. Who had never forgotten a debug command or a whitespace at the end of a line? By using pre-commit, you’ll never repeat that.
More specifically for Ruby on Rails, as we do use it a lot at Digital Natives, there is the hookup gem. You may think it is yet another gem which provides Git hooks. This gem, though, acts across git checkouts. It will make sure you have the right gems and the right database schema. It is very handy when you need to change branches frequently.
At last but not least is the git-extras project. Sometimes Git command line may seem very simplistic and dry. This project brings a lot of awesome commands to Git and at least one will make you wonder “Why Git doesn’t have this by default?”
That’s all folks
Writing software is not an easy task, but doing version control right was never so easy and cheap as nowadays. This doesn’t mean, though, that you don’t need discipline and organization around it. By following the tips mentioned above, you can care more about writing good software and using the time for what really matters.
I hope you enjoyed the post. And if you like it, I hope you’ll participate in our discussion and share it with anyone you think might find it useful
So do you have any tip of your own on Git? Share with us on twitter!