Working with Remote Repositories

Motivation

When working on project files, it may be easier to manipulate the files locally, i.e. on your workstation. This is especially true for development projects (R, Python, Java) where you want to code/compile/run/debug your project on your workstation. Propagating your changes to the remote repository is a means to back up the most important files.

This is also handy when you work on several different machines (your personal laptop, and a remote server) and want to be able to easily synchronize your project files.

A more advanced usage is to work on several local copies of a remote repository simultaneously. Ex.: You are working on a new feature of your program (or a new chapter of your book), but you need to fix a bug in the current release of the same program (or you want to fix typos and other minor mistakes in another chapter). Git makes it easy to have two (or any number of) distinct copies of the same repository on your machine in completely separate folders, and allows you to make modifications in isolation before propagating your work back to the same remote repository.

Cloning a Repository

Copying a remote repository is called cloning. In order to be able to clone a repository, you need its address (URL). For non-public repositories you may also need credentials (login/password, SSH key or other).

The actual URL(s) for a GitLab hosted project can be found by clicking the Clone button, which provides two methods for cloning : HTTPS, and SSH

Cloning using HTTPS

The complete command to clone a repository from GitLab using HTTPS looks like:

git clone https://gitlab.com/<gitlab_username>/<gitlab_projectname>.git

where:

• gitlab_username is the user name of the GitLab project ownder.
• gitlab_projectname is the "computerish" name of the project (no spaces or special characters, all lowercase by default)

The command may ask you for your GitLab username and your password.

This video shows how a clone operation of the tutorial project is performed.

• The benefit of using HTTPS is that no further setup is needed on your workstation.
• The drawback is that unless you use advanced (and insecure) git commands to store your username and password, you will need to enter them every time you communicate with the remote repository.

Cloning using SSH

Using SSH to interact with the repository required you to copy an SSH key file to GitLab. If you have no such key, you will have to generate it.

The command to generate a key looks like:

ssh-keygen -t ed25519 -f ~/.ssh/ed25519_gitlab

And creates two files: a file with a secret key and a file with a public key.

To display the contents of the file with the public key, use:

cat ~/.ssh/ed25519_gitlab.pub

An example of how to generate a key pair and view the public key is given in the following screencast:

This contents has to be copied to the GitLab SSH Key management page, accessible in the left panel of the User Settings page which can be displayed using Edit profile in the menu below the user badge (upper left corner).

This screencast shows how to add an SSH key to GitLab

The SSH private key must be present in the correct location on each machine (laptop, workstation) that will be used to access the GitLab repository. It is recommended to generate a key pair on each machine and to add each public key to GitLab. It avoids having multiple copies of a private key, and also allows to track which machine was used to access the repository.