Keep a github/gitlab fork up-to-date

Developers in the R-community are open to any kind of help in the development of their packages. You can open issues but also propose some pull/merge requests to improve code and/or documentation. But once you have forked the main repository, how can you be sure to work on the last version of the code ? Let’s see a few lines of code to keep your forks up-to-date.

Manage your forks

If you forked a github or gitlab repository to propose pull/merge requests, you may need to work on the last updated version of the original repository. The graphical interfaces do not allow you to stay up-to-date with the exact same commits. If you already tried graphically, you probably had to include different merge commits.
Hence, to be able to continue participate in the development, or get your own fork updated with the last modifications of the original repository, you will have to manage this locally with a few command lines. All command lines below are to be run in a Terminal. Remember that you have a “Terminal” interface in your Rstudio IDE to manage your system using command lines.


Figure 1: From

Add a fork in your local list of repository

upstream will be the name of the original distant repository on your computer, as opposed to origin for the distant repository of your own fork.

# List distant connections
git remote -v
# Add upstream
git remote add upstream
# List distant connections to verify upstream has been added
git remote -v
# Retrieve commits of the upstream
git fetch upstream

The code above allow to get a copy of the distant repository. Not a branch to work on.

Manage master branches

When working with a fork, I would recommend not to modify the master, in particular if you only forked to participate to the developement of the original repository. Hence, you only play with branches.
To stay up-to-date, what I do is to manage a local branch for the upstream master that I can compare to my own branches. You can manage your master to be the copy of the original repository, but I prefer to read the origin of branches in the name of the branches.

Create a local branch synced with the original repository

# Create a branch named upstream_master and open it
git checkout -b upstream_master upstream/master
# Update its content
git pull

If for any reason you created the branch without linking it to the distant repository, you can use the following command line:

# old git version
# git branch --set-upstream=upstream/master upstream_master
# new git version
git branch --set-upstream-to=upstream/master upstream_master

Update the branches of your fork

Only use rebase if you know what you are doing and if your modifications have not been sent to the distant repository. Otherwise, you will prefer using merge.

Retrieve modification from the upstream in your branch.
If you are sure you did not push any changes on the distant server

git checkout my-branch
git pull
git rebase upstream_master
# or directly from (local) distant
git rebase upstream/master

If you think you did push changes on the distant server

git checkout my-branch
git pull
git merge upstream_master

Manage your branches

With multiple developers working on the same project, you can adopt a similar behaviour with your main branch (being master or dev depending on your git architecture choices).

My personnal behaviour is:

  • Work locally

  • rebase each time the repository manager informs me that the main branch has been updated, in order to reduce conflicts resolutions

    # be sure to be on your branch
    git checkout my-branch
    # update the local-distant server part
    git fetch
    # Stash your current work
    git stash
    # Rebase if you know what your are doing
    git rebase origin/dev
    # Un-stash your current work and solve potential conflicts
    git stash apply
  • Send to the server only when I want my work to be merged to the main branch:

    # git add your-files
    # git commit your changes
    # Push to distant server
    git push
  • Open a pull/merge request to inform other developers and the manager of your modifications

I know that this behaviour is not viable for all git projects, but if it can give you ideas, it will already be that of shared. Then you can compare to other git projects management.

This short blog post is more a reminder to me, so that I know where to find the information quickly. If you want to know more on git, in particular when developing in R, I would recommend In fact, there is also a chapter on forking:


For attribution, please cite this work as:
Rochette Sébastien. (2019, May. 12). "Keep a github/gitlab fork up-to-date". Retrieved from

BibTex citation:
    author = {Rochette Sébastien},
    title = {Keep a github/gitlab fork up-to-date},
    url = {},
    year = {2019}