Git: Always Be Committing (ABC)

Wikipedia describes a junior as a "third year high school student". Urban Dictionary describes it the same way and raises it a status of "still have another year to take orders from older douchebags." However, for a junior in the working world, that word takes on a whole new meaning if you are looking at it from the perspective of professional growth. Being a junior in any field can consist of some pretty broad results depending on a number of factors. One of the most influential factors that I found, is in the choice of the company in which you choose to hang your hat. A good company will support you in your learning and see value in your growth. The knowledge that empowers you will, in return, empower the team as a whole in the long run.

This is especially true when a company commits to cultivating its juniors potential and it goes a long way in molding the web developers of the future. Like our VP Tony mentioned in a conversation we had the other day "It takes 40-50 years for someone to be a master of their craft and web development is most definitely a craft...there are no masters yet." Encouraging best practices and empowering new employees to grow is the cornerstone for building a strong future.

All that being said, having a junior status in the web developer world comes with a host of experiences unique to the computer science field that can be both challenging and rewarding. So whether you are a fellow junior, a spectator looking for insight, or a senior comparing your own experience with those good old junior days, the aim of this blog is to be a crossroads where developers of all stages can discuss and share their experiences. This blog series will be retrospective of my thoughts on being a junior including my victories and failures as I progress in my craft. It is my hope that you can laugh, learn, discuss, and somewhere along the way, maybe even relate from time to time.

Lesson 1 - "ABC - always be committing"

One of the most important aspects of a healthy workflow is working with version control. The most widely used system for this is what I will touch on today. It is what we use here at Metal Toad, I am referring Git (specifically with Github as the backend service provider). Git is a really powerful tool but can also be a source of chaos if not handled carefully. For those of you that don't know, Git is a revision control system that allows you to safely iterate through the different stages of project development in a way that is both safe and collaborative. The risk involved with not being thorough applies to juniors and seniors alike. At any stage however, you should always be committing your work to some system of revision control whether it be Git or Stash or anything you choose to use. This is one of the strongest indicators of progress in the development community and you should keep ABC in the forefront of your mind moving through your career.

My first few weeks working with real projects have shown me first hand what can happen when you are not using best practices. Being a junior is the best time to make a habit of these practices so they can become second nature moving forward before personal shortcut/improper habits get in the way. I have had my share of practice with it but no matter how much practice you get, people at all skill levels make mistakes with Git, it is inevitable. Also, every shop is different so chances are, whatever you learned about Git during your personal research likely won't exactly apply to your company's workflow wherever you end up working.

Sound scary? No? Well, it should at least be a point of concern because you can set your team back some serious time with a single misdirected commit and in a time sensitive situation, can have the potential to bork an entire sprint. Git has revert options and other rad tools to mitigate risk but depending on the circumstances, those options may not help much so best to be safe! Here to help are two great commands that have your back when it comes to Git. The first command is "git status". This handy little command allows you to do just that! Check the status of your code and see what exactly has changed and what hasn't with this easily executed terminal entry. Simply entering "git status" shows you all the files that have been modified/removed/added. New files are not tracked until they are committed so they will be marked as untracked until that happens.

The second command is implemented by entering "git diff" and it works hand in hand with the first command. It should be used right after the first. What it does is shows what files have been modified in detail, line by line, so that you can be sure that there isn't anything changed that shouldn't have been, and can also show if you are missing any changes. "git diff" can be targeted to specific files too. New changes can show up as colors such as green for any new changes by either adding "--color" to the end of your command or by configuring your ~/.gitconfig file.



Adding these tools to your workflow is essential to avoiding potential mistakes before they happen and can save your team hours of error correction. For these reasons I consider them best practices and implore you to do the same. As any junior can attest, hours are more like minutes when you are learning and should be coveted whenever possible. There are many other useful git commands that I will be covering in subsequent blog entries such as "git log", "git rebase" and "git revert" but for now, those of you just starting out should implement these two commands before every single commit as a form of sanity check. They will take you really far in forming best practices and ensuring that you are committing the quality code that you intended to commit.

So, before I go I would like to direct this question to you senior devs out there:
What is your best git practice and why?

For the juniors:
What aspect of development fascinates you the most and why?

Well, that wraps this weeks entry but check in next Friday when we will be getting into configuration, more best practices, my "AHA!" moment of the week, and of course, my "FAIL" moment of the week. Thanks for stopping by and happy coding!