If you've found yourself on this page, we're assuming you're brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way.

Contributing to a project

At some point you may find yourself wanting to contribute to someone else's project, or would like to use someone's project as the starting point for your own. This is known as "forking". For this tutorial, we'll be using the Spoon-Knife project, hosted on GitHub.com.

Step 1: Fork the "Spoon-Knife" repository

To fork this project, click the "Fork" button in the GitHub.com repository.

Click "Fork"

Step 2: Clone your fork

You've successfully forked the Spoon-Knife repository, but so far it only exists on GitHub. To be able to work on the project, you will need to clone it to your local machine.

Run the following code:

git clone https://github.com/username/Spoon-Knife.git
# Clones your fork of the repository into the current directory in terminal

Step 3: Configure remotes

When a repository is cloned, it has a default remote called origin that points to your fork on GitHub, not the original repository it was forked from. To keep track of the original repository, you need to add another remote named upstream:

More about remotes

A remote is a repository stored on another computer, in this case on GitHub's server. It is standard practice (and also the default when you clone a repository) to give the name origin to the remote that points to your main offsite repository (for example, your GitHub repository).

Git supports multiple remotes. This is commonly used when forking a repository.

cd Spoon-Knife
# Changes the active directory in the prompt to the newly cloned "Spoon-Knife" directory
git remote add upstream https://github.com/octocat/Spoon-Knife.git
# Assigns the original repository to a remote called "upstream"
git fetch upstream
# Pulls in changes not present in your local repository, without modifying your files

More Things You Can Do

You've successfully forked a repository, but get a load of these other cool things you can do:

Push commits

Once you've made some commits to a forked repository and want to push it to your forked project, you do it the same way you would with a regular repository:

More about commits

Think of a commit as a snapshot of your project — code, files, everything — at a particular point in time. After your first commit git will only save the files that have changed, thus saving space.

Warning: Git will do its best to compress your files, but large files and binaries can cause a repository to become bloated and unwieldy. Try to avoid committing things like compressed files (zips, rars, jars), compiled code (object files, libraries, executables), database backups, and media files (flv, psd, music, movies)
git push origin master
# Pushes commits to your remote repository stored on GitHub

Pull in upstream changes

If the original repository you forked your project from gets updated, you can add those updates to your fork by running the following code:

git fetch upstream
# Fetches any new changes from the original repository
git merge upstream/master
# Merges any changes fetched into your working files

What is the difference between fetch and pull?

There are two ways to get commits from a remote repository or branch: git fetch and git pull. While they might seem similar at first, there are distinct differences you should consider.

git pull upstream master
# Pulls commits from 'upstream' and stores them in the local repository

When you use git pull, git tries to automatically do your work for you. It is context sensitive, so git will merge any pulled commits into the branch you are currently working in. One thing to keep in mind is that git pull automatically merges the commits without letting you review them first. If you don't closely manage your branches you may run into frequent conflicts.

Fetch & Merge
git fetch upstream
# Fetches any new commits from the original repository
git merge upstream/master
# Merges any fetched commits into your working files

When you git fetch, git retrieves any commits from the target remote that you do not have and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date but are working on something that might break if you update your files. To integrate the commits into your local branch, you use git merge. This combines the specified branches and prompts you if there are any conflicts.

Create branches

Branching allows you to build new features or test out ideas without putting your main project at risk. In git, branch is a sort of bookmark that references the last commit made in the branch. This makes branches very small and easy to work with.

How do I use branches?

Branches are pretty easy to work with and will save you a lot of headaches, especially when working with multiple people. To create a branch and begin working in it, run these commands:

git branch mybranch
# Creates a new branch called "mybranch"
git checkout mybranch
# Makes "mybranch" the active branch

Alternatively, you can use the shortcut:

git checkout -b mybranch
# Creates a new branch called "mybranch" and makes it the active branch

To switch between branches, use git checkout.

git checkout master
# Makes "master" the active branch
git checkout mybranch
# Makes "mybranch" the active branch

Once you're finished working on your branch and are ready to combine it back into the master branch, use merge.

git checkout master
# Makes "master" the active branch
git merge mybranch
# Merges the commits from "mybranch" into "master"
git branch -d mybranch
# Deletes the "mybranch" branch
Tip: When you switch between branches, the files that you work on (the "working copy") are updated to reflect the changes in the new branch. If you have changes you have not committed, git will ensure you do not lose them. Git is also very careful during merges and pulls to ensure you don't lose any changes. When in doubt, commit early and commit often.

Pull requests

If you are hoping to contribute back to the original fork, you can send the original author a pull request.

Unwatch the main repository

When you fork a particularly popular repository, you may find yourself with a lot of unwanted updates about it. To unsubscribe from updates to the main repository, click the "Unwatch" button on the main repository and select "Not Watching".

Click "Unwatch"

Delete your fork

At some point you may decide that you want to delete your fork. To delete a fork, just follow the same steps as you would to delete a regular repository.


You have now forked a repository. What do you want to do next?