Git pain optimisation

Keywords: #git #code

I have been thinking a bit about git and the tools that help us with it.

Git is a super powerful tool, but with quite complicated ways of working.

And to most of the developers, the interface in the command line is hard.

That usually leads them to using some UI which claims to make things easier by abstracting details away (that is, the UI claims to do the magic).

All what I have seen so far tells me that this results in quite unexpected behaviour (well, funnily enough sometimes we don’t even know what is the expected behaviour). And every time this unexpected things come along, one has to spend a good amount of time to fix it (and that is possible only with the CLI)

To make it worse for me, in most of the projects I’m in, the person who bears this pain is yours truly.

This is mainly because the developers of the UI tool are probably confused too, and finds it hard to communicate with the users correctly - resulting in a tool which claims to do magic, but performs the wrong trick.

The one and only solution I have seen which works (not claiming it is easy), and completely avoids all or any kind of surprise is the git command line.

I use perhaps 2% of the power of git, but only from CLI and very very rarely do I end up in a soup.

My regular pain is probably ever so little more than the pain of the UI tool user. But that is my worst pain, but never do I have to suffer anything worse.

So, please go ahead and learn those 10 git cli commands and get out of the habit of using a fancy tool which merges in the wrong direction or rebases incorrectly to drive you mad. That’ll pay off and keep your pain minimal.