Last week, I gave a talk at FITC SCREENS discussing GitHub for Designers. You can find the slides here. I thought it would be useful to distill the fundamentals – the most important part of my talk – down to a blog post. So here we are.
Git is a tool for managing files – and changes to them. GitHub is a web service built on top of git. This article is going to introduce you to some fundamentals of git and GitHub and show you how you can use these tools to collaborate with other members of your team.
Git manages any type of file, but it’s typically used on text files and images. Typically, we do not store more complex file formats like PSDs in git.
We use git for two main reasons. It helps us manage the changes that multiple team members are making to the same files and it helps us keep track of who made what changes and when. The benefits to using git are concrete, but it’s known for having a steep learning curve. However, learning git is a great first step to learning to code changes to the projects you’ve designed. This article isn’t going to dive into the command line or a specific tool, but rather teach you some high-level concepts that will help you regardless of what tool you’re using.
Branches are used to isolate changes to files. Imagine copying all your files to a new folder. Any changes you make are only made to the copies. Eventually, you pull those copies back into the original folder.
A branch is like a making that copy of all your files.
The “master” branch is the canonical branch – all new branches are created off of master.
When you create a new branch from master, it’s like you’re creating a new copy of all of your files. Changes made to those copies won’t be reflected back in the original folder.
When you’re working on a branch, it’s like you’re making changes to the copies of those files. When you’re finished a change, like adding some new CSS, then you should commit your changes. This “saves” a snapshot of the new files in your new directory, allowing you to revert back to this point in time later on. Until you commit, nothing is permanent, so it’s easy to make whacky, experimental changes to see if something will work.
When you commit, you only commit to your branch. You branch represents the series of commits since it diverged from master.
Here we have a branch created from master with two commits.
Local & Remote
This is the part of git that gets a little complicated. The master branch and your branches exist locally, but there’s also a copy of master in GitHub, the remote. This would be like having a shared file server in an office with a folder you keep up to sync.
When you make a new branch, all your changes are made locally, on your computer’s folder.
Likewise, your branch only exists on your local computer until you push that branch to the remote, which we’ll talk about next.
Pushing & Pulling
When you’re ready to show others your changes, you should push your branch, which includes your changes, to GitHub. This is analogous to copying your copied folder back to the shared file server.
Now your branch exists on the local and the remote. Once you push your changes to GitHub, create a Pull Request. This is a request to have your branch’s changes pulled into the master branch.
Once those changes are pulled into the remote master, your version of master is out of date (remember, we isolated those changes in your branch). We need to pull down from the remote to update our local copy. This is like re-copying the original files from the server.
This gets confusing because we’re using the term “pull” in two contexts. First, we want to pull our branch’s changes into the master branch. Second, we want to pull the changes made to master on the server to our local copy.
Git is a great tool for managing files in a team, but it is complicated to learn. The best way to become more familiar with it is just to dive in and use it.