I was myself introduced to Git at a very late stage in my career as a Product Designer. And as far as I could recall, the introduction was not by choice. One day our team was notified that we would be moving design documentation to a new website and that we have to add an additional ritual of creating a PR(pull request) to our existing list of sprint tasks. The next few days were spent reading incessantly on the internet to understand the concept of Git and almost every website assumed that if you want to have anything to do with Git, you’re probably already a logical thinker and an expert command line user. And such has been the situation so far.

I started off with using a Git client(Sourcetree) that provided me a visualization for every action I performed in my Git workflow. The tool was coming across as very helpful until I realised I still very much relied on the visualization provided by the GUI to understand the resultant structure of my commit tree when it should actually be the other way around. I still lacked the ability to predict the outcomes of my actions.

In my new role at GitLab I was required to use Git more frequently in my everyday job, and to keep up with my tasks I eventually had to make a shift to the dreaded command-line. After over three months of using Git through command-line and successfully pushing a bunch of merge request, I could proudly say that I’m strangely comfortable with the tool and I wish I would have taken a completely different approach to learning Git since the beginning.

#tech #open-source #product-design #user-experience #git