Skip to main content

Git breaking? Get off the UI

Git is perhaps the best VCS I've used in my life. However, some of the things I always hear when people are trying to learn Git, or have used it for a while but never in larger teams are:
"something stuffed up my Git"
"my Git is broken"

In my experience, Git is probably the most predictable, deterministic tool I've ever used (thankfully, considering it does version your code!).

git logo. Source: Wikimedia Commons

About 9 times out of 10 the people saying things like the above are those who are relying on a GUI abstraction-tool of Git, whether they be GitExtentions, SourceTree, Visual Studio Team Explorer or others. Whilst I don't think these GUI abstractions are bad in and of themselves (in fact, I like using GitExtensions to visualise graphs and diffs). They don't allow you to understand the more intricate details of Git such as: branching, rebasing, cherry-picking, ref-logs, remotes, branch tracking, tagging, and squashing.

Going back to the breakages that are complained about above. These occur when: people pulling a main-line (master) branch into their feature branch, committing into the main-line (master) branch instead of a feature branch, or a bunch of merge conflicts because a sync hasn't been done for a while. These 'breakages' more often than not can be avoided if there is a more intimate understanding of Git.

Using the command line allows you to have this more intimate understanding of Git as no commands are abstracted away. Two more advantages to the command line are: Having a history of the operations that have been made on your repository. So if something has broken, you can have a rough idea of where it broken. And secondly, wider community support and reach when you do need to do a web search and get help.

In conclusion, if you find yourself struggling with your Git repository and fiddling too much. I suggest that you uninstall your GUI abstraction tool. Start using Git on the command line, then slowly introduce helper tools, if you don't know where to start simply try git --help. If I can learn the command-line. I'm more than confident you can too! The Git documentation is really easy to read and often a git status on your repository tells you exactly what you need to do to achieve what you want.

Thank you for reading


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?