In this mini-series I will walk you through some habits I replaced in recent times, which have shown to pay off and make me a more productive programmer/power-user of my computer. All these changes should be easy to gradually adopt, so I would highly recommend checking them out. If you’ve any suggestions ☝️ or improvements ✍️, then email me at email@example.com or reach out using any of the social media listed here.
Yes, this assumes you’re using Git, which might be everyone’s version control system (VCS) of choice. However, this does not change any of the underlying reasons why you should spend time on becoming effective at using your VCS. So whenever I say Git, please replace it with whichever VCS you are using.
Many developers I get to work with are not too comfortable around Git. This is definitely more noticeable with more junior and less “hardskills” focused engineers. The latter referencing to for example UI or UX designers. This makes them more reluctant to using Git for their own personal projects and makes them less effective when needing to combine work.
Using Git for your own projects might seem like an unnecessary overhead to many. However once you get more proficient at it both reduces the time spend on setting everything up and at the same time better at leveraging its strengths. Some reasons on how you can benefit from using Git in your own projects:
console.logsyou added all over your code while trying to get this new feature to work? Well,
There are some great collections of Git aliases available to significantly shorten your commands and easy using back practices (e.g. making
git push --force-with-lease the default rather than
git push --force). I personally use the
git plugin from Oh My ZSH, although
gitalias/gitalias also offers a great collection. Don’t be afraid to look them regularly look them up, either online or using the
which command to expand the alias. Also, adding your own aliases is always an option if you still find that you’re repeating yourself.
As to give an example:
When starting with Git it can be tempting to just delete the entire repository when there didn’t seem to be an easy way out, for example when merge-conflicts arose or your have commits you want to get rid of. Short term this might very well be the quickest solution, however these issues often stem from a lack of understanding how Git works. Spending a bit of time researching to understand how you got into this situation is a great way of getting to know Git and the principles behind it. Without properly grasping the fundamentals of Git, it is impossible to ever reach a more advanced level.
Git can visualise history in a great way. This allows you to easily see what changed between versions, what commits are shared between your feature and master branch and which commits are not yet pushed to the remote. I will leave you with the following screenshot, there’s already a lot going on and it might take some time to get comfortable reading it. But it’s a great tool to have in your toolbox, as it allows you to quickly figure out what the current state of your repository is.
There are many ways on how to render the graph, for this I would refer back to the aliases mentioned earlier. Although you can quickly get started with a basic command such as
git log --graph --all.
Okay, this might sound very boring at start. Luckily Github has really nice way of covering Git’s changelog. As of writing, version 2.26 is the latest release. When I first ran into these posts, I found it easiest to read the log of the current version and navigate to the previous one by following the link at the top. What I especially like about Github’s changelog is that there’s a strong focus on how it benefits you, rather than merely covering what changed as the official Git changelog does.
Even small changes of for example new flags or under the hood performance improvements show you what is actively worked on, which parts are getting deprecated and how Git is being used. Slowly your Git knowledge will get stale, so keeping up with the changes allows you to stay ahead of the curve.
At first, rebasing, soft/hard resetting, amending and force-pushing might sound scary, because these tools are just a subsection of the tools available to rewrite or delete history. When getting started, be cautious and make sure that until you properly understand what you’re doing before you try it in an environment where you can cause serious harm. It’s not rocket science, but a mistake is easily made.
If you’re comfortable to remove, reorder and overwrite commits, you can more freely add commits when you’re working. Leaving cleaning up to something only done last before you push to master or you create a pull request. Frequently adding commits while you’re working allows you to understand what you tried and more easily revert part of your changes. But maybe the most important benefit is that it makes it significantly harder to lose progress once it’s committed.