The Designers Guide to Git

Posted 11 months ago by Daniel Fosco

Or anyone who really wants to use it but has no idea how

Writing code is hard. For every 1 minute of bliss typing characters in the computer and seeing it render things that didn’t exist before, there are 10 minutes of frustration with unreadable code and bugs that didn’t exist the night before.

“Writing code with Git is hard. Writing code without it is unthinkable.”

Whether you’re senior developer on a huge team or a designer who just started dabbling with front-end for personal projects, using Git will change the way you code for the best and make group collaboration enjoyable.

This guide will walk you through basic concepts in Git with some hands-on action at the end. It won’t make you a Git master, but you will be able to use Git by yourself with Github and it’s desktop app.

PSA: This is a guide for absolute beginners… if you already have Git chops feel free to skim through or jump to the references in the end of the article.

What is Git?

Git is a distributed version-control system for code.

Descriptive but not very helpful, right? Let me tell you a true story then:

You’re working on a small website. You’ve been trying to get that sticky footer right for a whole hour and somehow only managed to make it worse in the process. It’s 2AM. You hate CSS and are currently in the process of re-thinking your life choices. Screw this, let’s go back to the previous version from 3 hours ago and watch some Netflix.

Oh wait.

The previous version. You don’t have it anymore, do you?

What if every change in your project was tracked — every character and line of code you added or deleted. What if you could save all of your code at every stage of your work?

That way, once you started working on the feature/sticky-footer, you were sure nothing would be lost if you decided to roll back — and you could even go back to work on this feature later if you wanted to.

That’s what Git does. It tracks and saves snapshots of your entire codebase and allows you to easily distribute it to other developers (either teammates or people on the internet). In practice, Git will allow you to:

But what about… Github?

This can be confusing for beginners, so let’s clear it up.

Git is an open-source system. You use it by running it on your machine to save your code and then upload it to a server where other people can see it. The thing is, for this to work you have to install Git on this server and manage it yourself. Which, as you probably guessed, is a major pain in the ass.

Github was created to address this problem. It’s a platform that hosts your code on a remote Git server with a nice web interface and allows you to collaborate with other project members on the same server. Conversely, the Github app can be used instead of the default Git command-line application on your desktop.

There are others similar platforms like Gitlab and Bitbucket — they are great products as well. Github became huge for its interface focused on team collaboration and massive adoption by the open-source community.

For the sake of convention we’re going to use Github for this guide, but the same could be achieved using other hosted platforms.

How it works

When you use Git, your project lives in a repository. Every project is a repository, and every repository has a different history — basically, a timeline of every change you saved in it.

However, Git doesn’t save changes to the history automatically. To save a change to your history, you need to commit your changes.

The commit is the most important thing about Git. Committing is the way to add a file or save changed files to your repository history.

A commit represents a snapshot of your repository in the moment that commit was saved — all of your repository, with every file, all of it.

You can type a message for each of your commits, describing which changes it’s saving to the project’s history. It’s important to keep your commit messages descriptive and short. Never commit without writing a commit message.

Committing is a powerful tool. It allows you to think about your code in chunks and organizes your work — each small part of your work is done and checked in a commit before moving to the next.

There are other important things to know, but let’s do this right now.

Getting our hands dirty

Let’s create a repository and do a test commit. Start by creating a Github account (http://github.com/join) if you don’t have one already.

Once you do, create a new repository. You can name it however you want, this is just a test. Leave other configurations untouched for now.

Create a new repository

Pretty straightforward

You’ve probably seen people using Git with the command-line. It’s easy to do it, but don’t worry, we’ll skip the command-line for now. We will use Github’s desktop app that achieves the same purpose with a helpful UI for Windows or Mac.

Once your repository was created at Github and you have the Desktop app up and running, you’ll see it listed in the app. Now you need to copy it to your machine.

That is, you need to clone it. The app will give you the option to select a folder where the repository will live in your computer: that’s where your code should go.

Quick setup

Repository folders

Saving your changes

Once you have your repo (short for repository) cloned, add any file and you’ll see all changes listed in the Github App:

See all changes

All changes

See the change? Now let’s commit it:

commit

Pro-tip: To make your commits consistent, start them with a verb in present tense, as if you were saying before the message “If you use this commit it wil…”

commit-history

Your commit history!

One important caveat

It’s important to notice that your file changes will only be tracked after the file is committed for the first time. Here’s a visual explanation:

New file commit

When a new file is added, Git still doesn’t know about it. If you don’t commit it…

Changes to new files

…any change you make will be lost! The previous line is gone and Git has no history saved.

That’s one of the reasons it’s important to constantly commit you work, in small chunks — specially when you’re adding a new file. This way you make sure you can roll-back small changes if necessary and no work is lost.

Sharing your code

Once you’re done working, make sure you push your changes to Github using the Publish button on the top, so other collaborators can see them (and you have a backup in case something bad happens to your computer)! Conversely, to get the changes added by other collaborators from Github, just press Sync.

Want to see a previous state of your project? Just select a previous commit on your history.

It’s great to see your repository history growing, being sure that you can roll-back your changes anytime. It can (and probably will) get messy after a while, but knowing it’s really hard to screw things up is a reassuring way to work.

descriptive-commit-messages

Again: make sure your commit messages are as descriptive as possible

What’s Next

You may have realized the Github app shows an option called branches. Branches are a good way to modularize your project and make sure your code changes don’t conflict with other collaborators— but let’s leave this for another day ✨.

Using Git by yourself is already a great way to organize the way you code and make sure you can roll-back any unwanted changes. However, this is really just the beginning about Git. If you want further reference, here are some useful links:

CodeSchool has a crash-course on Git

Another beginner guide for those that want to use Git in the command line

A cheatsheet of Git commands (you may want to see the previous guides first to make sense of this)

Official Git reference (for the brave-hearted!)

This post was originally published on Daniel’s Medium Profile.

Prototype with Sketch!

Prototype with Sketch!

Send artboards straight from Sketch into your Marvel projects.

Download Plugin

Digital designer at VTEX. I make sites and apps to improve the way people live and work. Also: eating tacos like there's no tomorrow. Follow me on Twitter.

Related Posts

Collaboration between designers and developers is essential for creating great products. Every company has different organizational structures for designers and developers. Some companies have designers and developers on two separate teams. Those development teams may also break up developers in sub-teams as well. For example, they may separate by front-end developers and back-end developers. In other companies, designers and developers… Read More →

A good product is a lot about the problem that you pick & the ideas that you implement. But a well-sorted & deliberate design-development process can play more than a handy role; ironing out quite a few wrinkles that can cause unnecessary escalations and ad-hoc duct-taping later during the execution phase. “As designers, we are the guardians of execution and… Read More →

A mechanical engineer by training, I’ve always chaffed at using the word process to describe something as messy and nonlinear as design. At MIT, I learned about processes for solving problems like how quickly heat moves through a block of metal, or how to calculate the impedance in an electrical circuit. To me, a process is something with a set… Read More →