What kind of GIT hub or laboratory is that

MINT green robotics project laboratory

In your projects you will have to work collaboratively on your program code. It will happen that two or more changes are made at the same time, or that people work with changing group members on different dates. Git is used to facilitate this type of collaboration. With Git you can keep your common program code up to date and edit it at the same time without running the risk of overwriting important work by others or losing previous (working) versions of your code. This makes Git a powerful tool that is widely used. This is often used to manage projects that are much more complex than what you do in the robotics laboratory. But if you already learn how to use Git using the example of a smaller project, it will hopefully make working with Git easier for you in the future. In this article we tried to introduce you to the basics of Git. You can find more information online, e.g .:

Detailed instructions for using Git are available here: https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository

A simple one in German e.g. here: https://rogerdudler.github.io/git-guide/index.de.html

You can find YouTube videos on the topic here: https://www.youtube.com/watch?v=Nkz7TnhFvWU&list=PL58qjcU5nk8s-UQHfzeVajBDwkbWqwSc6


GitLab is a web-based software for versioning and joint editing of program code with Git. The core component is a web portal to which users can log in and create their own projects. A Git repository is automatically created for each project, in which the program code can then be stored in a versioned manner. In addition, GitLab provides a wiki and an issue tracker for each project, which can then be used to offer documentation or to record and manage errors or requests for changes to the program code.

Other users can be added to a project for joint work, with differentiated authorization levels being possible. Projects can be accessible internally, only for project members, externally, for all registered users and publicly, i.e. worldwide.

Functionality and scope essentially correspond to the well-known web service "github.com", but all data is stored on servers of the tubIT data center.

The service is therefore ideal for managing program code, whether alone or in a team.

install a software

Command line version

Most people use a command line tool to manage their Git repositories, for which, in contrast to the graphical tools, there is also proper documentation. You can find the current Git version here:

If everything went well, you can, for example, look at the current version of the git installation in the command line:

git --version

You may have to specify your name and email:

git config --global user.name "d.golovko" git config --global user.email "[email protected]"

Graphic user interfaces

Lovers of graphical interfaces can use one of the following programs - unfortunately with them it is sometimes not really clear what is actually going on "under the hood".

If you are the first on your team: Create a group and project on the TU server

Register at the GitLab of the TU Berlin

Create a project repository

  • Press the "New Project" button
  • Enter a meaningful name for the project under “Project path” without any special characters or spaces
  • Press the "Create Project" button.
  • To add other team members, press Settings–> Members (bottom left). The other members should have the role of "Master" so that they have full write access.

0 .: basic concepts

Git consists of four different places where your files are kept. The workspace, index and local repository are stored on your computer, while the remote repository is located remotely on the Git server.


The workspace is your working copy. This contains your data with which you can work. Any file can be created, not just code. To edit you use the editors and IDE's of your choice.


The index is used for stage of your files. Here you specify which files will be added to the local repository with the next commit. This additional step may seem a bit cumbersome at first, but it is very useful for larger projects (why?). The addition is done with the "add" command.

local repository

Every commit (add) to your project is saved in the local repository, it also enables you to return to old versions of your project.

remote repository

As soon as you have brought your local repository up to date, you can push the new version to the “remote repository” with “push”. The “local repository” and “remote repository” contain all the intermediate statuses of your project that have been saved up to now. The “workspace”, on the other hand, is only the latest version available on your computer.

1 .: Transferring the repository from the TU server to your own computer ("clone")

After you have created a project in GitLab, you can create a local copy of it. Open your terminal / console / command prompt to enter commands via the command line. First the command to clone the repository:

git clone

Instead of you write the address of your remote repository, which can be found on GitLab on the page of your project. Switches to the HTTPS link:

And for you enter the directory in which your working copy should be. The entire command could then look like this:

git clone https://gitlab.tubit.tu-berlin.de/d.golovko/MyProject.git / Documents / Arduino /

You have now saved a copy of your project locally and can make changes to the workspace.

With the command you can switch to the corresponding folder in the command line:

cd / Documents / Arduino / MyProject /

2 .: Add new files to the copy on your own computer ("add", "commit")

The add command tells Git that you want to add changes to a file to the local repository with the next commit. As long as the commit has not yet been carried out, the changes have not been adopted.

To add a file to the index:

git add
You can only add folders to the Git repository if they contain files, this is because Git only records files and not folders.
Files that have been indexed can now be added to the local repository: git commit -m "This is where a description of what has been changed (the quotation marks belong!)"


We add the test.rtf file to our local repository. First you move with the command line in the folder of your project. The test.rtf was previously created in the project folder with a text editor. Add to index:

git add test.rtf

Then we commit the file to our local repository:

git commit -m "A hello world test file!"

The file is now in your local repository.

3 .: Transfer changes from the TU server to your own computer ("pull")

To get the current version of your remote repository you use the command:

git pull

This command is always recommended before transferring your own changes to the repository in order to incorporate any changes made by others before you push your code (see next point).

4 .: Transfer changes on your own computer to the repository on the TU server ("push")

To make the changes available on your remote repository, use the following command:

git push origin master
Before working on the code, the latest version is always "pulled", after the work is done, the new version is "pushed"!

5 .: Version conflicts

However, if the code is being worked on at the same time, version conflicts may arise; these must be resolved manually before a push / pull can be carried out.


In our “test.rtf” file we wrote “Hello Wörld!” And added it to the remote repository. But now someone third has noticed your mistake before you and is trying to correct it by improving it to "Hello Earth!" But since your intention was to write “Hello World!” You change the file accordingly and try to push it. You will then get an error message that looks like this:

User $ git push origin master To [email protected]: c.jaedicke / myTestProject.git! [rejected] master -> master (fetch first) error: failed to push some refs to '[email protected]ubit.tu-berlin.de: c.jaedicke / myTestProject.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

The solution to the problem is already mentioned. The changes to the remote repository must first be integrated into your local repository by pulling. If you now do a pull you will get the following message:

User $ git pull remote: Counting objects: 5, done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From gitlab.tubit.tu-berlin.de:c.jaedicke/myTestProject 2e6d627..a29e896 master -> origin / master Auto-merging test.rtf CONFLICT (content): Merge conflict in test.rtf Automatic merge failed; fix conflicts and then commit the result.

Git tried to automatically merge the changes to the remote repository with your workspace. As expected, a conflict has arisen because changes have been made at the same point. You can display the conflict with:

git diff

This gives you the following answer from Git:

User $ git diff diff --cc test.rtf index 30c8472,642e89a..0000000 --- a / test.rtf +++ b / test.rtf @@@ -4.4 -4.4 +4.8 @ @@ \ paperw11900 \ paperh16840 \ margl1440 \ margr1440 \ vieww10800 \ viewh8400 \ viewkind0 \ pard \ tx566 \ tx1133 \ tx1700 \ tx2267 \ tx2834 \ tx3401 \ tx3968 \ tx4535 \ tx5102 \ tx06236 \ firnatural \ part \ pighten \ pard \ pard fs24 \ cf0 Hello World!} - \ f0 \ fs24 \ cf0 Hello Earth!} ++ <<<<<<< HEAD ++ \ f0 \ fs24 \ cf0 Hello World!} ++ ======= + + \ f0 \ fs24 \ cf0 Hello Earth!} ++ >>>>>>> a29e8967e7015e58cd9af8489bec4d8288b84fe4

In order to resolve the conflict, “Hello World!” Must be changed to “Hello Earth!” In your local repository. As soon as you have made the changes, an add + commit must be carried out again. Now a pull can be carried out without conflict, so that your local repository is up to date. Based on the current status, “Hello Earth!” Can now be changed to “Hello World!” And pushed to the remote repository.

With SourceTree


In Git there is the possibility to create so-called branches. A branch is something like a copy of the previous program in a kind of sub-repository. When a new repository is created, the “master” branch is automatically created. In this you define the folder structure of the project. The entire team can then push all changes directly into the master branch. The problem here is that it can happen that someone uploads faulty code or that a change in another part of the program causes an error in ours. In order to avoid such conflicts, it makes sense to create different branches for different parts of the program in larger projects.
We are developing software that takes pictures of a webcam and runs 2 algorithms A and B on it. Our team consists of 5 people. We now decide to let 2 people work on algorithm A, 2 people on algorithm B and one person to read the image. We create a Git repository in which we define the structure of our project and create 3 branches: "Algo_A", "Algo_B" and "Read" (Fig. 3, arrow 1). Each team now has its own branch (copy of the project structure) in which it works. Well, for example. Team-B got their algorithm running and tested it well, in this case the branch "algo_B" is merged into the "master" branch (Fig. 3, arrow 2) (ie all changes made on the branch algo_B are made transferred to the master branch). The other teams continue to work on the copy of the original master branch for the time being. If now Team-A also provisionally finished their algorithm and tested it well! has, the master branch with the changes from Team-B is first merged into the algo_a branch (Fig. 3, arrow 3) and then the algo_a branch is merged into the master (Fig. 3, arrow 4). This step is important to prevent conflicts from occurring when merging algo_a into master and the program version in the master no longer working at the end of the merge. In this way everyone has access to the last working version of your program (i.e. the master branch) at all times.

Create a branch called algo_A. Attention, you always cut off from the branch in which you are currently located.

git branch algo_A

Change to the branch algo_A:

git checkout algo_A

Delete the branch algo_A:

git branch -d algo_A

To merge you first have to switch to the branch in which you want to merge. then you merged with the following command:

git merge algo_A


So if you for example. first

git checkout master

executes and afterwards

git merge algo_A

in this way the changes made in algo_A are adopted in the master.

Last modified: 2021/02/01 17:41 by