Tag: Git

Git: how to compare two branches

Sometimes it’s necessary to get the difference between two branches. Git already provides a really powerful diff command which does exactly this:

git diff

git diff is very powerful, as it not only compares two branches, it also allows multiple comparisons:

Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes resulting from a merge, changes between two blob objects, or changes between two files on disk.


To compare two commits, simply use the commit hashes:

git diff 27b00e..f553c6

To compare two branches, simply use the branch names:

git diff master..feature/myNewFeature

The output looks like this:

diff --git a/lib/components/list_view/list_checkbox.dart b/lib/components/list_view/list_checkbox.dart
index 4985774..b3f5957 100644
--- a/lib/components/list_view/list_checkbox.dart
+++ b/lib/components/list_view/list_checkbox.dart
@@ -23,7 +23,7 @@ class ListCheckbox extends StatelessWidget
         checkColor: (checked && inactive) ? Colors.grey : Colors.black,
         onChanged: onChanged,
         activeColor: Colors.transparent,
-        focusColor: Colors.red,
+        focusColor: Colors.green,

Photo by Yancy Min on Unsplash



Setup GitLab Runner for Docker containers on Synology NAS

The setup described in this post has been tested on the following system:

  • DS216+II with 8GB RAM
  • DSM 6.2.3-25426 Update 2

In addition, the following software packages have already been installed on the system using the Synology package manager:

  • Docker 18.09.0-0513

GitLab is installed via the Docker Registry:

  • gitlab/gitlab-ce:latest (in my case GitLab 13.5.1-ce.0)

Install GitLab

You can skip this part, if GitLab is already running on your Synology and continue with the step Install GitLab Runner.

To install GitLab, open the Docker Registry and search for “gitlab”. Double click the entry gitlab/gitlab-ce:latest and select the latest version:

After the image is loaded, it will be listed under image. Launch this image and set the folders to be mounted as shown in the following image. This will simplify the access to the docker files within your Synology.

Mounted folder / volumes
Port settings

The port settings depend on your system. Normally, HTTP is accessible at port 80 or HTTPS on port 443. If your system already uses other apps that are running on those port, you can adjust them in Port Settings.

After completing the setup, it might take some time until the GitLab web surface is available. When accessing GitLab for the first time, you can specify a password for the root environment. The default username for the admin area is root. Now you can create user accounts, projects and perform any adjustments that fit your needs.

Install GitLab Runner

As the Synology DSM uses Docker to run GitLab, we can use Docker as well to install GitLab Runner. For this, connect to the Synology using SSH:

ssh <admin-user>@<synology> -p <port>

Now we can install the Gitlab Runner Docker container that can run other Docker containers to perform the runner tasks:

docker run -d \
--name gitlab_runner_docker \
--restart always \<br>--network host \
-v /run/docker.sock:/var/run/docker.sock \

This will install a Docker container with the name gitlab_runner_docker which uses the same network as Docker (‘–network host‘).

As this container is the basis for our Docker-in-Docker setup, we connect the Docker socket of our main container to the new one by using -v /run/docker.sock:/var/run/docker.sock.

You might also use the Docker GUI of DSM to create the container. But the step above can only be done with the help of the console command!

To test the container, you can use the following command to connect to the console:

docker exec -it gitlab_runner_docker /bin/bash

Register the runner

Now it’s time to register the runner:

docker exec -it gitlab_runner_docker gitlab-runner register

This will ask for some input:

Runtime platform                                    arch=amd64 os=linux pid=16 revision=e95f89a0 version=13.4.1
Running in system-mode.                            
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
Please enter the gitlab-ci token for this runner:
Please enter the gitlab-ci description for this runner:
[synology]: docker_alpine
Please enter the gitlab-ci tags for this runner (comma separated):

Registering runner... succeeded                     runner=sA4DKorC
Please enter the executor: docker-ssh, parallels, docker+machine, kubernetes, docker, shell, ssh, virtualbox, docker-ssh+machine, custom:
Please enter the default Docker image (e.g. ruby:2.6):
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

In this case, the executor docker and the base image alpine:latest is used for this container.

If you use a self-signed certificate for GItLab, then you have to specify the certificate with the option --tls-ca-file during registration:

docker exec -it gitlab_runner_docker gitlab-runner register --tls-ca-file /path/to/fullchain.pem

Setup Docker-in-Docker

Let’s connect to the bash terminal of this container to change some settings:

docker exec -it gitlab_runner_docker /bin/bash

The created Docker container is an alpine base system without any packages installed. To perform the changes, we need a simple terminal text editor like nano or vim. The following commands will install nano for this task:

apt-get update
apt-get install nano

Now you can use nano to edit the GitLab Runner config file:

nano /etc/gitlab-runner/config.toml

And add the following lines as highlighted in the config file below:

clone_url = ""
privileged = true
pull_policy = "if-not-present"
concurrent = 1
check_interval = 0

  session_timeout = 1800

  name = "GitLab Runner Docker"
  url = ""
  clone_url = ""
  token = "Examp1eT0ken"
  executor = "docker"
    tls_verify = false
    image = "node:latest"
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    privileged = true
    pull_policy = "if-not-present"

That’s it. Now you can use this GitLab Runner for your repositories and run jobs by using other Docker containers.

Example usage in .gitlab-ci.yml

The following example uses a php container to run tests for a simple PHP application and deploy the code to a server. Some of the settings depend on the setup of your PHP application, so the example will not work out of the box. But it can give you a good idea of what is possible.

# https://hub.docker.com/_/php
image: php:7.4-fpm

  - mysql:5.7

  # Configure mysql environment variables (https://hub.docker.com/_/mysql/)

  # Initialize database, etc

  - test
  - deploy

  stage: test
    - composer install
    - composer phpunit

  stage: deploy
    name: production
    url: https://www.example.com
    # run on server 'git checkout master && git pull origin master && exit'
    - master

Photo by sergio souza on Unsplash

VI oder VIM beenden

Um den bei vielen Linux und Unix Installationen und Tools (wie bspw. git) standardmäßig genutzten VI Editor zu beenden muss man mit der “ESC”-Taste in den Kommandomodus wechseln (am besten mehrfach drücken um ggf. schon eingegeben Kommandos abzubrechen). Und dort dann

> :q

eingeben und Enter drücken.
Dies beendet VIM wenn vorher nichts geändert wurde.

Wurde etwas am Text der geöffneten Datei geändert und man will dies speichern so nutzt man den Befehl:

> :wq

Will man die Änderungen verwerfen und VI verlassen, so hilft:

> :q!

Ein sehr hilfreiches und detailliertes Cheat Sheet zum Nachschlagen selten benutzter Befehle findet sich unter: https://devhints.io/vim

Auszug eines Cheat Sheets für VI/VIM

Git: Unterschied zwischen ‘git pull’ und ‘git fetch’

Kurz gesagt: git pull führt ein git fetch und anschließend ein git merge aus.

Ein git fetch kann man zu jeder Zeit machen, um die lokalen Branches zu aktualisieren und mit den entfernten Branches (origin, remote) abzugleichen. Diese Operation ändert dabei keine lokalen Branches, sie zeigt lediglich an, wenn Änderungen verfügbar sind. Man kann git fetch also bedenkenlos ausführen, ohne die lokale Arbeitskopie zu ändern.

Ein git pull führt ein git fetch und anschließend ein git merge aus. git pull wird dabei immer in den aktuellen Branch der Arbeitskopie mergen. Man wählt sich also den Branch aus, von dem man pullen möchte und pullt diesen (überführt dessen Änderungen) in den aktuellen Branch.

Ein git pull ist das, was man tun muss, um einen lokalen Branch auf den Stand des dazugehörigen entfernten Branch zu bringen.

Git documentation: git pullfetchmerge