Teaching: 20 min
Exercises: 40 min
  • How can I make a contribution to other people’s repositories?

  • How do I know what changes other people are making in my repo?

  • Explain what forks and pull requests (PR) are.

  • Open a PR to make a contribution to someone else’s repository.

  • Review a PR to check what changes have been made.

  • (Bonus) Update your fork to keep it up to date with the original repository.

Now that you have your repositories in GitHub, you will learn how to start collaborating with other people, contributing with content to their repositories and accepting other’s contributions to your own.

Forking someone else’s repository

The image below shows that this repository has been forked 6 times already. To fork it yourself, click on fork and choose your personal account.

Git collaborative

Playing with a fork

Visit this repository and fork it. Explore the options in the repo. What’s different from a repository you created? And from the original one?


  • The only visual difference with one of your repos is that there is a note just below the name indicating where this repo was forked from.
  • You can also open a pull request (see below) across forks.
  • In the original repo, you don’t have write access, i.e. you cannot modify any file or change any setting.

Pull requests

To open a PR, just click on the corrsponding button next to the branch selector, as shown in the next figure.

Git collaborative

In the next screen, you can select the target branch (where things will be merged, if the PR is accepted) and the branch that you want to merge. You can open PR involving branches within the same repo or between a repo and any other fork of it. Once the branches are selected, a comparison between the files that are different will appear below.

Git collaborative

Requesting reviewers

Reviewing a PR


Mentioning other issues and PR

All issues and PR receive a tag number starting at 1 and preceded by #, like #40 or #110. If you want to refer to an issue or PR in any comment anywhere in GitHub, just use its tag number and these will be automatically linked from the comment.

Claim issues

There are some restrictions on who can be assigned to an issue. If you do not have write access to the repository (which is often the case) and you are not part of the same organisation of the repository, the only way of being assigned to an Issue is by making a comment on the Issue. This also serves to warn others that you are volunteering to work on that. A “Hey, I can tackle this.” is often enough.

Closing issues

If a PR tackles a particular issue, you can automatically close that issue when the PR is merged by indicating Close #ISSUE_NUMBER in any commit message of the PR or in a comment within the PR.

The following figure shows some of the issues open in a certain repository. The labels tell us there are a couple of bug reports, a couple of issues related to the performance of the software and several ones that are simple enough to be tackled by novice people. Most of them have some discussion going on.

To open a new issue, simply click on the New Issue green button on the right.

Git collaborative

An example workflow

We now have all of the components needed to start working collaboratively through GitHub. A typical workflow might look like this:

If there is a group of you that will be working together on a project you can avoid needing to have individual forks by setting up collaborators. This allows you to grant write access to other users to a public or private repository. In this case we still strongly recommend working in separate branches and communicating through issues and pull requests.

Making a book of recipes

Together with some colleagues, you are writing a book of recipes for sauces and you are using git for version control and GitHub to collaborate in the writing of the book.

Form groups of 3-4 people and choose one to act as administrator. This person should:

Enabling issues in forks

By default, when you fork a repository, Issues are disabled. To enable them go to Settings in the upper right corner, then to Options in the left panel and, finally, scroll down to the Features section. There click the Issues tickbox to enable them.

Now, start collaborating!

  • All, including the administrator, open new issues with recipes for sauces you will like to have in the book.
  • Administrator, add some tags, prioritising some of the recipes, and assign yourself or one of your colleagues as responsible for each of them. Remember you will need to “Claim the Issue” first in order to be assigned to it, as discussed above.
  • Fork the administrator’s repository. Administrator, did you notice how the number of forks increases? Which GitHub users forked it from you? And from the original repo?
  • Work on the recipes you have been assigned. Practice the concepts learnt in previous episodes about cloning a repository, making the changes locally and pushing those changes back to the remote repository. You can even try a gitflow aproach if you feel ambitious!
  • When ready, open a PR to the administrator’s repo and request his/her review.
  • Administrator, review the PR, request some changes and accept others. When ready, merge the PR.

These exercises can be repeated with the other members of the group acting now as administrators and choosing a different topic for the recipes (eg . pasta, roasts, cocktails, etc.).

Bonus: Keeping your fork sync with the original repo

In the previous exercise, the individual forks will be outdated as you contribute with content to the administrator’s repo. Follow these instructions to make sure that your own forks are kept up to date.

Key Points

  • Forks and pull requests are GitHub concepts, not git.

  • Pull request can be opened to branches on your own repository or any other fork.

  • Some branches are restricted, meaning that PR cannot be open against them.

  • Merging a PR does not delete the original branch, just modifies the target one.

  • PR are often created to solve specific issues.