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.
Cloning a repository
- Click the
< > Code
button on the top right of the repository’s contents.

This copies the remote’s URL to your clipboard.
- Navigate to a suitable directory (not inside our
previous
gitgood
repository), such as the Desktop directory, and rungit 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:
- 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.
- 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:
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:
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.
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:
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:
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:
This will sync the remote with the local.
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.
-
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.