DEV Community: Héctor Pascual

Git merge, merge-squash and rebase simplified

Héctor Pascual — Fri, 09 Aug 2019 10:17:46 +0000

Git merge, merge-squash and rebase simplified

Starting the repository with basic files

Lets create an empty repository and commit a file to the master branch:

$ git init 
$ touch m1
$ git add m1
$ git commit -m "m1"

Now we switch to a new branch named feature:

$ git checkout -b feature

Is time to create a file in the feature branch and commit it:

$ touch f1 
$ git add f1 
$ git commit -m "f1"

Now let's go back to the master and create another file :

$ git checkout master
$ touch m2 
$ git add m2
$ git commit -m "m2"

If we type $ git log we will see this :

* 60c3a2b - (1 second ago) m2 - Hector (HEAD -> master)
| * 7832858 - (87 seconds ago) f1 - Hector (feature)
|/  
* 0a950f5 - (5 minutes ago) m1 - Hector

Integrating changes from master to feature branch

Up to now we have one simple feature branch with a commit and two commits in the master branch, it is a common practice to integrate the commits from the master branch to our feature in order to avoid losing track of master changes, but there are a few ways to do it :

Git merge

$ git checkout feature 
$ git merge master

This is a non-destructive way, branches keep preserved its history and only a merge commit appears :

*   fad9250 - (11 seconds ago) Merge branch 'master' into feature - Hector (HEAD -> feature)
|\  
| * 60c3a2b - (5 minutes ago) m2 - Hector (master)
* | 7832858 - (7 minutes ago) f1 - Hector
|/  
* 0a950f5 - (11 minutes ago) m1 - Hector

Git merge --squash

$ git checkout feature 
$ git merge --squash master
$ git commit -m "Squash"

This is a non-destructive way as well, branches keep preserved its history but now no merge commit appears, all the changes in master are grouped into 1 commit named Squash in my case and appears as as a single commit in the feature branch, as you can see :

* dc4e5b7 - (10 seconds ago) Squash - Hector (HEAD -> feature)
* 7832858 - (19 minutes ago) f1 - Hector
| * 60c3a2b - (18 minutes ago) m2 - Hector (master)
|/  
* 0a950f5 - (23 minutes ago) m1 - Hector

Git rebase

$ git checkout feature 
$ git rebase master

With rebase instead, the history will be simpler, what it does in high-level words is to search for the last common commit and add master commits upon it but below our branch commits.

As you can see m2 commit is upon m1 (last common commit in both branches) and below f1 (our feature branch commit)

* 6074794 - (11 minutes ago) f1 - Hector (HEAD -> feature)
* 60c3a2b - (10 minutes ago) m2 - Hector (master)
* 0a950f5 - (15 minutes ago) m1 - Hector

Integrating changes from feature branch to master

Let's suppose we integrate master changes to feature branch with merge and we add some few changes to both branches, m3 and f2 resulting to this log :

* 83c98e1 - (1 second ago) m3 - Hector (HEAD -> master)
| * 0a3663c - (2 minutes ago) f2 - Hector (feature)
| *   edfda02 - (2 minutes ago) Merge branch 'master' into feature - Hector
| |\  
| |/  
|/|   
* | 60c3a2b - (29 minutes ago) m2 - Hector
| * 490a167 - (3 minutes ago) f1 - Hector
|/  
* 0a950f5 - (35 minutes ago) m1 - Hector

As before, we have the same 3 options :

Git merge

If we do a $ git merge feature it will result as it follows :

*   d6b643b - (4 seconds ago) Merge branch 'feature' - Hector (HEAD -> master)
|\  
| * 0a3663c - (4 minutes ago) f2 - Hector (feature)
| *   edfda02 - (4 minutes ago) Merge branch 'master' into feature - Hector
| |\  
| * | 490a167 - (4 minutes ago) f1 - Hector
* | | 83c98e1 - (2 minutes ago) m3 - Hector
| |/  
|/|   
* | 60c3a2b - (31 minutes ago) m2 - Hector
|/  
* 0a950f5 - (36 minutes ago) m1 - Hector

Git merge --squash

If we do a squash :

$ git merge --squash feature
$ git commit -m "Squash"

With the behaviour expected, not a merge commit and non-destructive history we get :

* 63f7387 - (10 seconds ago) Squash - Hector (HEAD -> master)
* 83c98e1 - (3 minutes ago) m3 - Hector
| * 0a3663c - (5 minutes ago) f2 - Hector (feature)
| *   edfda02 - (5 minutes ago) Merge branch 'master' into feature - Hector
| |\  
| |/  
|/|   
* | 60c3a2b - (32 minutes ago) m2 - Hector
| * 490a167 - (5 minutes ago) f1 - Hector
|/  
* 0a950f5 - (37 minutes ago) m1 - Hector

Git rebase

Finally, let's test what would happen with $ git rebase feature we obtain the following log :

* 6c6ba0e - (5 minutes ago) m3 - Hector (HEAD -> master)
* 0a3663c - (7 minutes ago) f2 - Hector (feature)
*   edfda02 - (7 minutes ago) Merge branch 'master' into feature - Hector
|\  
| * 60c3a2b - (35 minutes ago) m2 - Hector
* | 490a167 - (8 minutes ago) f1 - Hector
|/  
* 0a950f5 - (40 minutes ago) m1 - Hector

Rebase takes the last common commit, which is the merge commit and add places the f2 commit upon it, but below the m3 commit from master.

Docker in Docker, managing existant volumes

Héctor Pascual — Thu, 11 Jul 2019 08:11:25 +0000

Introducing the context, I am working with a docker container that runs jenkins, inside it there are some other docker services running aswell, brought up during some jenkins job execution.

As an existant volume I refer to a folder containing data that I will mount to the container, for instance :

$ docker run ... -v /folder/with/data:/var/data ...

The command I use to run jenkins is the following one :

$ docker run \                                        
  -d \               
  -u  \
  -p 8080:8080 \
  -v /data/jenkins_test:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  shimmi/jenkins

As you can see the docker socket, which is the main entry point for docker API is mapped as a volume into the container, that means, that the docker engine will be "shared" (it will be the same docker socket) and volumes, images and containers will be shared inside and outside the container.

This is a relevant point that caused me a lot of headache trying to figure why once I run a container inside jenkins, the path specified as existant volumes when creating containers were not found or empty.

The problem was that the path I was specifying was the correct for the jenkins container but Docker was trying to search for it in the host that runs the jenkins container (my machine filesystem) not in the jenkins container itself.

About volumes and docker-compose

Specifically the services I bring up are specified in a docker-compose file, in order to use existant volumes from the host you have to declare a top level volumes option and set the external property as true :

volumes:
  <myVolume>:
    external: true

And now, if this is an existant volume in your docker host you should be able to use it.

Creating volumes from existing data folders

In my case I wanted to create a volume and "link" it to some folder with data, not an empty volume, in order to do that I followed these steps :

$ docker volume create <myVolume>
$ docker volume inspect <myVolume> 
[
    {
        "CreatedAt": "0001-01-01T00:00:00Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/<myVolume>/_data",
        "Name": "<myVolume>",
        "Options": {},
        "Scope": "local"
    }
]
# See the mountpoint is the path we will link
$ sudo rm -rf /var/lib/docker/volumes/<myVolume>/_data
$ sudo ln -s <MY_FOLDER_WITH_DATA> /var/lib/docker/volumes/<myVolume>/_data

That way, you can bring up containers inside another containers (docker in docker) managing volumes with data in an easy way.

Bash script

In order to automate the task of creating a volume and the symlink I wrote a bash script :

#!/bin/bash

# This script creates a docker volume and links it to a existing folder that contains data.

# Arg1 : volume name
# Arg2 : existant folder with data to create the volume

ARG1=$1
ARG2=$2

function create_volume {
    echo '$1 = ' $ARG1
    echo '$2 = ' $ARG2
    docker volume create $ARG1
    if [ $? -ne 0 ]
      then
        echo "Script failed"
        exit 1
    fi
    echo "Volume created!"
    sudo rm -rf /var/lib/docker/volumes/$ARG1/_data
    sudo ln -s $ARG2 /var/lib/docker/volumes/$ARG1/_data
    if [ $? -ne 0 ]
      then
        echo "Script failed"
        exit 1
    fi
    echo "Folder linked"
    echo "Script executed succesfully"
}

if [ $# -eq 0 ]
  then
    echo "No arguments supplied, specify the volume name and the path of the folder"
    exit 1
fi

if [ $# -eq 1 ]
  then
    echo "Not enough arguments supplied, specify the volume name and the path of the folder"
    exit 1
fi

EXISTS="$(docker volume ls -f name=$ARG1 | grep -w ARG1)"
if [ -z "$EXISTS" ]; then 
    read -p "A volume with this name already exists. `echo $'\n> '`Do you want to delete it and create it again linked to the specified path (y/n) ?" -n 1 -r
    echo
    if [[ $REPLY =~ ^[Yy]$ ]]
    then
        if [ -d "/var/lib/docker/volumes/$ARG1/_data" ]; then
            unlink /var/lib/docker/volumes/$ARG1/_data
            echo "_data folder unlinked!"
        fi
        docker volume rm $ARG1
        if [ $? -ne 0 ]
          then
            echo "Please stop the containers using this volume before launching the script"
            exit 1
        fi
        create_volume
    fi
else 
    create_volume
fi