Ever felt confused when working with Git? Wish that it made more sense and you could leverage it more effectively?
For the longest time I didn’t really understand the fundamentals of how Git was storing and tracking changes to my projects. I had a set of commands I would strictly follow every time I wanted to push my changes up to the central repository: git add, git commit, git pull (possibly git mergetool), and git push. Sometimes I would run into issues and sometimes I wouldn’t. Whenever I did run into issues, it was a frustrating experience and took precious time away from the fun of coding. At first I thought this was just a by-product of using Git, but it turned out that it was because I didn’t understand how Git was storing and tracking my files.
Fixing merge issues, reverting changes, and understanding previous history all proved to be difficult. I just didn’t get Git! This was a real shame, because Git is an extremely powerful version control system. It’s by far the best version control system available (opinionated, I know)!
One of the reasons Git was so difficult for me to work with was that its architecture was completely different from any of the centralized version control systems I had worked with in the past. Previously I had used VSS, CVS, SVN, and even hg (arguably this is the same distributed model as git, but it tends to hide some of the complexities from you). I assumed that Git followed the same fundamental principles as all of the source control tools I had used in the past. However, this couldn’t have been further from the truth. There was a version control impedance mismatch in my brain (and I didn’t even know it)!
Daily use of Git (for a prolonged period) wasn’t sufficient for me to really learn how to use it. I became comfortable in my normal workflow and didn’t tend to venture far outside of this process. On the few occasions where I ran into trouble I would usually completely back out and start over (rm -rf and git clone the folder again). There is a great xkcd cartoon that sadly reveals that a lot of other developers do exactly the same thing!
The worst part about all of this is that Git is an AWESOME utility for developers. It’s extremely powerful and flexible. When you become familiar with using it effectively, not only are you able to use it with fewer issues, but you are able to leverage it to help you with your daily work. It provides great features for working on parallel development tasks (individually or with a team), experimenting without impacting your main branch, conducting peer reviews, searching your project history, compiling statistics, researching issues, merging two branches of work, and much more.
The way I was finally able to use Git effectively was to take the time to learn the fundamentals. It helped me to understand how it was different from the previous version controls systems I had used. I spent time reading, experimenting with the command base, and watching some great video tutorials. The fundamentals aren’t that difficult to understand. Once you learn them you will be able to use Git to its full potential (you probably use it everyday anyway, so why not let it help you)!
A few weeks ago, I put together a presentation for my local user group on the things I had learned about Git. The presentation consisted of some slides and a set of exercise I walked through. Hopefully this can help others to get the most out of Git!