Skip to content

Remote repositories with GitLab

Now, we want to collaborate with others via GitLab.

  • So far we have only worked locally. Usually, however, you work with several Git repositories, between which you synchronize.
  • We are about to introduce another repository, which is managed by GitLab. This could also be managed by GitHub or another local Git repository.
  • Repositories that are not on your own hard drive are called remote repositories.
  • See also for different repository topologies: https://git-scm.com/about/distributed

Publish the local Git Repository in GitLab

Set up a personal access token

In the following, we will set up an access token that you can use to authenticate via your Git client.

  • Edit your profile (right upper corner) and switch to the section Access Tokens: https://codebase.helmholtz.cloud/-/profile/personal_access_tokens
  • Set the name to git-access
  • Leave the expiration date as defined. I.e., the access token can only be used until that date.
  • Select the scopes read_repository and write_repository. The scopes define what you can do with the access token. In our case, we only want to read/write the Git repository.
  • Generate your access token by clicking the Create personal access token button.
  • Copy the access token and put it aside in a text editor or similar. We need it for the next step!

Please note that you cannot retrieve the access token after you closed the Web page. But this is actually no problem as you can remove / add new access tokens at any time.

Create a new GitLab Project

  • Click the + => New project/repository (toolbar on the top) which opens the dialog for creating a new project:
    • Select Create blank project
    • Project name => planets
    • Pick a group or namespace => Select your User namespace (at the very end of the list)
    • Deselect Initialize repository with a README
    • Click Create project which creates a new GitLab project and redirects you to its overview page.

  • Further remarks:

    • The Project URL allows you to select different namespaces (groups, subgroups, your username namespace). We create a “personal” project in your user namespace. Later projects can also be moved to other namespaces.

    • Even if the Project description is optional, please use them because they make it easier to navigate in project lists later.

    • You can define different visibility levels:

      • private: Only explicitly added project members can see and do something with the GitLab project.
      • internal: Only authenticated users of the GitLab instance can see/clone/fork the GitLab project.
      • public: The GitLab project is visible/cloneable even for unauthenticated users.
      • Please note that depending on the GitLab instance configuration, not all visibility levels might be available.

    • We do not initialize the GitLab project with a README.md file. Otherwise we have problems pushing our local Git repository directly to our GitLab project.

    • When creating the GitLab project, GitLab runs a git init --bare in the background.
    • GitLab project = Git repository + a lot of further useful tools

  • On the GitLab project page:

    • On this page you can directly create files (e.g., README, LICENSE, CHANGELOG, …). We do not use this feature. Otherwise we have problems pushing our local Git repository directly to our GitLab project. But later we might use them :)
    • There are also references to steps that can be carried out (create new repository, link existing folder, push existing repository). automatically GitLab infers the right protocol (HTTPS, SSH) from your user account preferences. We will use the HTTPS protocol for transferring our repository.

Push the local Git Repository to your GitLab Project

  • Switch again to your Git shell.
  • git status - Please make sure that there are no uncommitted changes and that your on branch main.
  • git remote - Only shows the defined remote labels.
  • git remote add origin <copied URL> - Creates a link to the remote Git repository onHelmholtz GitLab Instance. URL should look similar to: https://codebase.helmholtz.cloud/<username>/planets.git
    • Click Clone => Clone with HTTPS and use the copy button on your GitLab project page.
  • git remote -v - Displays two entries for origin, one where we ‘push’ changes to and another from where we ‘fetch’ changes. These URLs are usually the same. Different URLs and thus repositories are possible, but are only used in special sync workflows. We do not explain them here.
  • So far we have only created the link, but not yet used it. For that we need network access and have to authenticate ourselves in GitLab.
  • Use git remote set-url <remote name> <new url> to rename a url
  • git push - pushes the content of our repository but shows an error message because we have not connected the branches. Luckily, Git tells us what to do.
  • git push --set-upstream origin main - Instructs Git to link the current branch the branch main in repository called origin (which is on GitLab). Link is created and data is transferred. Output shows that a new branch was created on the remote repository and that the files were transferred.
  • Reload the GitLab project page. Now you can see the files and their history on GitLab. Congrats :)

Hint: --set-upstream git push --set-upstream origin main Username for ‘https://codebase.helmholtz.cloud’: token Password for ‘https://token@codebase.helmholtz.cloud’: Now enter your access token as the password. This does not appear in the window, do not pay attention, simply press Enter.

Hint: Configure a credential manager

In general, on Windows and Linux (in a window manager) a credential manager ist used to cache your password. If it does not work, you can configure a credential manager.

https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage#_credential_caching

  • Click the History button in the GitLab file view. It shows the same entries that are shown by git log --oneline
  • git branch - Displays only local branches.
  • git branch --all - Displays remote branches as well.
  • git graph - Shows where the remote branches are.
  • Via Repository > Files > Edit Button you can change files with the web IDE, stage and commit changes. In addition, you will find typical Git functionalities in the Repository menu as well.

Synchronize the local Git Repository with changed Content

Adapt the mars.txt via the GitLab Web Interface

  • Open the GitLab Web IDE by clicking “Web IDE” (just above the file listing)
  • Similarly, we want to update the mars.txt.
    • Open it by selecting it on the left.
    • In the editor, add another fact: 
      We have to bring our own oxygen
    • Finish your commit analogue to the process above: Select “Create commit…”
    • Write a good commit message: Add notes about the Mars atmosphere
    • Select “Commit on main branch”
    • Finish your commit (“Commit” button)

Synchronize your local Git Repository

  • git graph - Only shows our local commits but not the changes we did in GitLab. These commits are so far only in the repository on GitLab.
  • git fetch origin main - Checks if there is anything new in the remote repository on branch main. The output shows that something was fetched.
  • git graph - Now we see the 1 new commit objects in the graph and our HEAD still points to the latest local commit.

  • git status - Tells us that we are with our local main branch 1 commits behind the main on the remote repository (origin/main). In addition, the output tells us that we can use git pull to retrieve them.

  • git pull - Now we retrieve the commits and apply them to our local main branch. You normally run git pull directly. But in this case everything is directly applied to your local branch.git fetch allows you to view the changes first and then to decide whether the changes are wanted. For example, you could display them via git diff main origin/main.

  • If you use git pull, it implicitly performs a git merge as well. The git status hint that it can be fast-forwarded tells us it will not create a merge commit and more or less treat the two branches as one.
  • git status - Indicates that everything is clean again
  • git graph - Now both main branches point to the latest commit.