Simplifying ‘Git’ For Designers✨

Breaking down the concept of Git for designers through easy to understand definitions and illustrations.

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.

👩🏻‍💻 Git for designers

The role of a product designer working for product based company is heavily multifaceted as is. Managing the design tasks in parallel with the research activities, debating the usability of patterns and components, aligning with the user psyche, and all while actively documenting solutions and performing other housekeeping duties could sometimes appear to be a lot to handle. So one would argue — why learn yet another skill that isn’t imperative to the day to day function for the role?

In very simple words, Git allows for a more controlled management for changes made to a file. Even though this system was inherently created to manage code, it could come extremely handy in enabling designers to systematically contribute to the design system documentation for the companies they work for.

Being comfortable with using Git also opens up immense opportunities for designers to participate in Open Source projects and conversations and therefore find pathways to be heard and be able to add their perspective to those areas. Adopting Git in everyday design practices could also help designers widen their reach across communities and accept contributions from them.

👩🏻‍🏫 Learning the basics

Definition of Git

While looking up for the definition and introductory content on git, I came across many verbose documentations. The dense vocabulary did very little to help me actually understand the concept so I had to rephrase a few of them myself. Here is one of the illustrated notes from my own learning process:

But this more or less covers just the theoretical side of Git.

A walkthrough

Before delving deeper into the area, let’s set-up a few things on your computer that would help you get a hands-on learning experience of the process.

• Create an account on www.gitlab.com and create a new project
• Open the terminal in your computer and follow the instructions for installing Git.
• Go to this sample repository: https://gitlab.com/v_mishra/git-for-designers and fork the project. When prompted to select a namespace to fork the project, select the newly created account

• Generate an SSH key and add it to your GitLab account. The SSH key allows you to have secure connection between the remote and the local system for safe exchange of information. Read more here
• After successfully forking the project, clone the project to your computer

• If opting for cloning with SSH, type:

$ git clone git@gitlab.com:v_mishra/git-for-designers.git

• Install a code editor to make changes to the files in the project. For this exercise I’d recommend installing Atom.

The illustration below outlines the mock tasks for the exercise:

Here, the project has been cloned from a remote origin so that rules out the need to initialize a new git repository(using git init). Just navigate to the newly cloned project folder and you are all set to start working on the project.

$ cd git-for-designers

In the beginning, the head(pointer) for your project is by default on the master branch of your project. To be able to work on multiple changes at the same time without any conflicts, it is advised to create a separate branch for each set of changes. To create a new branch, type:

$ git branch new-chapter-1

But even after creating the branch, the head still stays at the previous position — the master branch. To activate the newly created branch and start working on it, type:

$ git checkout new-chapter-1

Go to the code editor, navigate to the file in the cloned repository and make the desired modification. In the editor, make sure that the current branch is checked out. Once the changes are made to the file, it now needs to be staged to be able to be picked by the commit.

$ git status //to see the list of modified files
$ git add <file_path> //to stage the file to be committed
$ git commit -m "new chapter added" //commits the staged files 

When pushing changes from your local repository to the main(remote) repository for the very first time, you would need to set the upstream as well. Type:

$ git push -u origin new-chapter-1

This command would set ‘origin’ as the upstream(remote) tracking branch of the branch you are pushing. From the second time onwards typing the command mentioned below should do the job.

$ git push origin new-chapter-1

This would push the changes made in the local repository to the remote repository and generate a link to create a merge request(MR). Once an MR is created and the pipeline steps are passed, the changes from local branch could finally be merged to the main project by someone who has the write access to the remote project.

Once the commit has been merged, the new file will show up on the remote repository of the project:

The illustration below visually outlines the process for a better understanding.

While this blog covers a very small part of this extremely vast subject, it gives a nudge in the right direction to anyone who is keen on getting their feet wet when it comes to Git. There are endless complicated scenarios that one could very easily run into, but thankfully we have the internet to troubleshoot out way through them.If you are interested in learning and practicing more advanced commands https://learngitbranching.js.org/ is a great resource that would come in very handy.

✨ Have fun learning ✨