Chapter 6 Github forking

6.1 What is forking?

The Github forking option allows you to take one repository, and create a second repository which is an exact duplicate of it. This allows you to make copies of code for a range of purposes, while retaining links to (and most of the features of) the parent repo. Forking is different from branching because it creates a second, independent repository from the first, rather than a duplicate of a single set of code within the same project.

6.2 When is it sensible to use forking?

Forking is useful in a number of scenarios including:

  • Facilitating cross-team collaboration; other teams can propose fixes to your code without needing write access to the original repository

  • Easy duplication of coding features, either from your own repos or from other people’s

  • Tailoring of existing packages to meet your own team needs better

  • Opportunities to practice using other Github features without risking breaking your existing repositories

6.3 When might forking not be the best option?

Sometimes the features permitted by forking don’t make it the most sensible choice for creating a new repo:

  • If you want to use a standard repo to make all of your team repositories have the same structure: you should use a template repository instead

  • You want to make some changes to a parent repository you own: you should create branches within the repository instead

  • You want to take a fixed snapshot of your repository at a specific period in time: you should create a release instead

  • You may want to make your forked repository public in future: you should set up a new repository instead (as you can’t make a fork of an internal repository public)

  • You think you would want to create forks from your new repository in future: you should set up a new repository instead (as you can’t fork from a forked repository)

6.4 How is forking different to just making a new repository?

While forking does produce an entirely separate repository, there are a few key differences in comparison to creating a new repo from scratch.

  • Forking allows you to copy all of the branches from the parent repo in one go

  • Forked repositories remain dynamically linked to their parent repositories; you can synch new and updated features from one to the other using pull requests

  • Forked repositories retain links to the original repository, and will be deleted if it is deleted

  • Forked repositories have the same visibility as their parent repository

  • Forked repositories by default don’t have all features enabled (such as issues tabs)

6.5 How to fork a repo

  1. Navigate to the repository you want to fork from. This can be any repository within the DfT organisation.

  2. In the top right corner, click the “fork” button (not the drop-down menu next to it):

  3. On the next page, choose the correct repository owner; it should default to department-for-transport, but you may want this to be different if you are forking to a different organisation or owner.

  4. Choose whether you want to copy all branches or the main branch only (the default). If you are creating a fork which will eventually be merged back in to the parent repository, always choose to fork the main branch only.

  5. Click “create fork” to create your forked repository

6.6 How to turn off forking on your repositories

There may be situations where you don’t want anyone to be able to make forks from your repositories. This could include:

  • Repositories which are scheduled to be deleted in future

  • Code which no longer works, or is no longer in use, and is only kept for archive purposes

In these instances, you can turn off the ability for anyone to fork these repositories:

  1. In a repository where you have administrator permissions, click “settings”.

  2. Under the general tab, scroll down to the “features” section and untick the checkbox “Allow forking”