Working with Remotes

Working with Remotes#

Learning Objectives#

  • Learn what remote repositories are and how they interact with local repositories

  • Understand how to view, add, and modify remote repositories

  • Learn the process of sending local changes to a remote repository

  • Practice fetching updates from a remote repository and integrating them into the local repository

  • Understand how to work with multiple remote repositories and manage updates from them

At the start of the first session we created our remote repository on GitHub. We then linked our local repository with the remote repository. Git then tracks branches on the remote repository.

The information for the remote branches is stored in two places:

  • .git/config contains information on the URL for the remote

  • .git/refs/remotes contains a reference to the commit

Instead of rooting around in the .git directory (which should generally be avoided), we can find the details of the remote with

git remote show origin

GitHub is useful, since it has extensive tooling to allow collaboration (more on this in the next session). There are alternative which serve a similar purpose (such as Bitbucket and GitLab).

Aside: Anonymising Your E-Mail#

We are potentially going to be pushing changes to public repositories. If you would rather not have the commits associated with your e-mail address, we can use an anonymised GitHub one. This e-mail address has the form ########+USERNAME@users.noreply.github.com, with digits and your username, and can be found through your GitHub user settings under E-mail:

  • There is a tick-box for using this substitution e-mail address for actions on GitHub;

  • and this is where you can find the e-mail address to use with git config --global user.email.

Sending Changes to GitHub#

Since we are working with our own repository, we have the relevant permissions to upload our local changes to our remote repository.

git push origin

When uploading a new branch, we can specify that we want git to keep track of differences between the local and remote branches.

git push -u origin feature-branch

The flag -u is the short form of --set-upstream. If we use git checkout and supply a branch-name that only exists on a remote, git will automatically set up branch tracking for us.

Fetch From Remote#

To get any recent changes from a remote, we need to fetch. To demonstrate this, edit a file using GitHub, then

git fetch origin

To see this on our local copy, we’ll have to use the --all flag in log:

git log --oneline --graph --all --simplify-by-decoration

We can see the remote tracking branches either with remote show origin (seen above), or with a doubly-verbose form of branch:

git branch -vv

In order to get these changes onto our branch, we have to fast-forward with git merge. Since this is such a common action (fetch and merge), the two actions are combined into a single command,

git pull origin main

Multiple Remotes#

So far we have just seen the single remote origin. We can use multiple remotes to track other people’s versions of the code. In this way, we can mark multiple remote repositories from which we can pull changes.

To add a new remote, we use

git remote add <name> <url>

where <name> is our local title and <url> is the network path for the new remote.

By default we can’t push changes to someone else’s GitHub repository. Instead, we can Fork the repository, giving us our own version (associated with our GitHub user account). If we add the original repository as a second remote, we can still track and pull changes on the upstream repository. We can push those changes, along with our own additions, to our forked version.

We will see some typical workflows that use multiple remotes for collaboration in the next session.

Note on Forking#

If there are libraries on GitHub on which your code relies, it can be a good idea to create a fork. Even if you don’t intend on making any changes, you will have a copy which cannot be deleted by the original author.

Summary#

We have seen how to work with remote repositories, and how download and upload changes.

In the next remainder of this session we will look at typical workflows using GitHub. We’ll also see how we can rewrite our history, as well as the tools we have available to get unstuck when applying these more complicated changes.

Exercise#

We will go through an example of creating our own fork of a public repository, cloning our own version of it, then adding an upstream remote to the original repository.

Summary Quiz#