Cloning a repository

Last updated on 2025-08-13 | Edit this page

Overview

Questions

  • How do we collaborate with Git?
  • How do we get code from GitHub into our computer?
  • How do we revert changes that we do not want?

Objectives

  • Clone a repository and the git clone command.
  • Pull changes and the git pull command.
  • Revert a change that was made and broke the code.

To start, we have two repositories to choose from, one in Python and one in R. Both repositories contain the same thing: a script that calculates the GC content of the sequences in a given FASTA file. Pick the language that you’re most comfortable with to proceed:

Take a note of the contents of each repository: - A README file - The script with the code - An example data file - A LICENSE file

Clone your chosen repository locally using the git clone command.

Checklist

Cloning a repository

  1. Click the < > Code button on the top right of the repository’s contents.

This copies the remote’s URL to your clipboard.

  1. Navigate to a suitable directory (not inside our previous gitgood repository), such as the Desktop directory, and run git clone <URL>

Well done! You now have a local copy of the code. Cloning is a powerful feature that allows us to effortlessly create a copy of an existing repository. If you make your code available on GitHub, people can clone it and customise it.

Undoing changes

Now, let’s try running the code in the repository:

You most likely got an error message like this one:

Let’s explore the log on the repository. Run git log:

Apparently, the last commit purposefully breaks the code so that we can fix it ourselves! We wouldn’t know that if it weren’t for a descriptive commit message.

Now, there are two things we could do:

  1. Revert back to the previous commit. After all, version control would not be useful if we could not go back to a previous, working version of our code.
  2. Fix the code ourselves and commit the changes.

There are multiple ways to revert changes in Git. Here, we will use the git reset command:

BASH

git reset --soft HEAD~1

There’s a lot to unpack here. First is the git reset command itself. What it does is that it resets the current state of the repository, also called HEAD, to a specified state. In this case, we are resetting to one commit before the current state, hence HEAD~1. The --soft flag tells the command to undo the commit, but keep the changes in the staged area. Let’s run git status to see what it shows:

BASH

git status
On branch main
Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   python_gc_content.py

The changes from the commit that we reset are staged, but the commit itself was undone (you can see with git log). We can see exactly what that change was by running git diff --staged, which is just like git diff that we learned before, but highlights only the changes that are already staged.

BASH

git diff --staged

We can see that the code broke because, in the previous commit, a parenthesis was removed from a line. However, because that change is staged, the code remains broken. We can undo the staged change by running:

BASH

git restore --staged <file>

This removes the file from the staging area, but the change is still there (you can check it using git status).

To fully restore the file to its previous state, you can run:

BASH

git restore <file>

Now that we have fully restored the breaking changes, let’s try running the code again:

The result should be:

OUTPUT

Overall GC Content: 57.98%

This was the first way that we could fix what wrong with the code, by reverting to a previous version that we know that worked. Let’s try the second approach, of fixing the change ourselves in a new commit. First, let’s undo what we did by running git reset. By doing that, we moved to a previous commit in time. That means that our local copy is one commit behind the remote. So, we can go back to the broken version simply by running:

BASH

git pull

This will sync the remote with the local.

Challenge

Challenge

Now, try perfoming the fix yourself. Once you make sure that the new code works, run git add, git commit. Raise your hand or put up a green post-it when you are done.

Well done! You fixed a broken a script and committed the result using Git. That is no easy feat! It will pave your way to making more contributions in the future.

After making sure that the code works, push your changes using git push. What happens then?

Because the repository that we cloned is under Melbourne Bioinformatics, we don’t have write access to it. In order to push the code to GitHub, we need our own copy of the code, so we must fork the repository. Let’s see how to do that.

Key Points
  • git clone copies a remote repository to our local repository.
  • There are multiple ways to revert to previous changes, one of them is git reset.
  • HEAD indicates the current state of the repository.
  • We cannot push to a remote repository if we do not have access to it.