Git: Putting the Knowledge into Practice
Tags: git, cherrypicking
Published: 2019-07-05 14:36:54

---
title: Git: Putting the Knowledge into Practice
published: true
tags: GIT, cherry picking 
canonical_url: http://www.theguild.nl/git-putting-the-knowledge-into-practice
---

In the first two parts of this series, we learned a lot about how Git stores your data. I believe that just knowing this information makes Git a lot less magic and easier to understand.

In this final part, we'll discuss some more practical examples of what happens when use certain Git features. Without knowledge on how Git works, understanding these tasks seems daunting, but with our new knowledge this should be no issue at all!

## Cherry-picking

Cherry-picking is one of those things that feels a bit magic, but is quite simple once you understand what it does. First, let's start with when you would want to do cherry-picking. Say we have the following commit graph:

![](https://i.imgur.com/jjzGi15.png)

When we were developing a new feature on `feature-branch`, we found out there was a high priority bug. We fixed it in the second commit on that branch, `ed50b5c5`, but later we found out it also needs to be fixed in master as soon as possible. We could apply the fix by hand in master, but cherry-pick allows us to copy over the changes in this commit to master.

```shell
$ git cherry-pick ed50b5c5
git cherry-pick ed50b5c5
[master 27d63a1] Crucial bug fix
 Date: Mon May 6 14:50:24 2019 +0200
```

It has created a new commit with the sha `27d63a1`. The parent of this commit is the original head of master and the master branch has moved to this new commit. Visually, it looks like this:

![](https://i.imgur.com/VibI8FA.png)

Note that while `ed50b5c5` and `27d63a1d` contain the same changes, but they are not the same commit. That would not be possible, since they represent a different state of the repository with a different tree. In `27d63a1d`, the parent of `ed50b5c5` is not present and vice versa. Also, they were committed at different time, with a different message, and possibly by a different person.

Later on, we decide that the new feature looks good and we want to merge it into master. Merging means that both the commits from `feature-branch` and the current `master` need to be present in the new `master` branch. This can be done with a merge commit:

![](https://i.imgur.com/quw8T34.png)

Since `ed50b5c5` and `27d63a1d` are different commits, both will be part of this updated `master` branch, even though they do contain the same changes.

## Fast forwards

Have you noticed when merging, sometimes Git will tell you it has done a fast forward? What is a fast forward exactly?

Luckily, the end state of the previous example is a perfect example of when a fast forward might happen. Merging two branches means that all commits present in both branches have to be reachable from the end result (the merge commit), via their parents. Normally, this is done by creating merge commit that has the heads[^1] of both branches as parents.

But sometimes this is not necessary. There might be a commit that satisfies this requirement already. Say we are happy with the feature developed on `feature-branch`, but there are some minor improvements we want to add. We want to continue on `feature-branch`. We would like to merge `master` into `feature-branch` first, since another commit has been created on master.

![](https://i.imgur.com/UrH62CN.png)

A merge commit with parents `7d0ee7d6` and `eaec2471` satisfies the requirement that it includes all other commits, but actually commit `eaec2471` also satisfies that requirement!

So just pointing `feature-branch` to commit `eaec2471` does the trick. That is exactly what a fast-forward is:

```shell
$ git checkout feature-branch
$ git merge master
Updating 7d0ee7d..eaec2471
Fast-forward
```

This is the end result, no merge commit:

![](https://i.imgur.com/wfGOZ75.png)

Sometimes you want to keep track of the fact that a merge has happened at a certain point in time, and a merge commit carries that information. If a fast forward occurs, you do not have that merge commit. If you want the merge commit anyway, just use the `--no-ff` option and a merge commit will always be created. Even when a fast forward is possible[^2]. 

## Rebasing

Once you learn about the hammer that is called rebasing, everything looks like a nail. `git rebase` does lots of things and it is very useful. The main use of rebasing is changing the "base" of the branch.

This is an example of when you would use `git rebase`: say you were working on a feature on `feature-branch`. After a while, you have created two commits on `feature-branch` and this feature is done. You create a pull request to master. You start working on another feature and do a `git checkout second-feature-branch` and develop some more, adding two more commits. After a while, you realize you made a mistake. All changes related to the previous feature are also part of this branch. You should have created this new branch starting from `master`, but you started on `feature-branch` instead!

![](https://i.imgur.com/TuKsVur.png)

Now we want to change the base of `second-feature-branch` from `feature-branch` to `master`. This is how we do that:

```shell
$ # git rebase --onto <new-base> <old-base> <branch-to-rebase>
$ git rebase --onto master feature-branch second-feature-branch
```

And the result is that we now have a clean `second-feature-branch` that no longer includes the commits that were part of `feature-branch`. It *does* include the latest changes on master now.

![](https://i.imgur.com/KeZf1f3.png)

Rebase can do a lot more than just this. If you want to learn more about rebasing be sure to check out the man pages for [git-rebase](https://git-scm.com/docs/git-rebase). Especially the `--interactive` flag can be very useful if you want to change the history of your commits. Just remember that changing history and then force pushing the results is often considered bad practice and can lead to issues for other people if they pull your changes. Please consult your team if they are ok with it before force pushing.

## Resetting

Sometimes you make a mistake and you want to go back to where you came from. That is when `git reset` comes in handy, it can reset your repository to a certain state. First, let's distinguish between the three modes of resetting: hard, soft and mixed.

In the case of a hard reset, we can set the head of our current branch to a given commit. The file in `.git/refs/heads` is updated, our working directory is restored to what it was in that commit, as well as the staging area (where we `git add` files to is updated as well). This can for instance be convenient when you want to undo the last commit: `git reset --hard head~`[^3].

A soft reset also updates the current branch (i.e. the file in `.git/refs/heads`), but it does not touch your working directory or staging area. They will remain the same. This means that your staging area will contain changes compared to the commit that is your current head and you can immediately commit these changes withing `git add`ing them first.

A mixed reset is somewhere in between, as the name suggests. It also updates the current branch and it resets your staging area, but it does not change your working directory. If you want to commit the changes, you will have to add them first. 

The last two modes can be useful when you want to undo the last commit to add more changes, but you don't want to lose the changes you already made. Just use `git reset --mixed head~` or `git reset --soft head~`, add your changes, and commit again.

If you ever mess up and you think you have lost a commit, don't worry. An object in the object store is not immediately deleted if your branch no longer references that object. Git keeps a history of everything that happens on every branch called the reflog. Use `git reflog` to see every change on the current branch. You can also use `git reflog head` if you want to see how your current head has changed, so that includes when checkout out an other branch for instance. See the man pages for [git-reflog](https://git-scm.com/docs/git-reflog) for more information.

## Octopus merges 🐙

This final trick is something you will probably never use, but it is a very cool party trick to show to your friends! In the first blog post of this series, we learned that commits have zero or more parents. The first commit of a repository has no parents, a regular commit has a single parent, and most merge commits have two parents. But a commit can have more than two parents.

Say we want to merge both feature branches from the previous example:

```shell
$ git merge feature-branch
$ git merge second-feature-branch
```

The end result would have two new merge commits, both with two parents, on master:

![](https://i.imgur.com/jDcRJjN.png)

We can actually merge both branches into master at once, meaning we only create a single merge commit. This is often referred as an octopus merge and this what it looks like:

```shell
$ git merge feature-branch second-feature-branch
```

![](https://i.imgur.com/sv2N7zH.png)

That single commit with three parents looks a lot cooler, right? Octopus merges are not often used in practice, they can become quite complicated if you merge a lot of branches.

The only repository that I know of that contains quite some octopus merges is the Linux kernel repository. This repository even has this [monster octupus merge commit](https://github.com/torvalds/linux/commit/2cde51f)[^4] with 66 parents! 😵

## Conclusion

This is the end of our adventure with Git. I hope you learned a lot about the internals of Git and I hope that, just like me, you feel a lot more comfortable using all the capabilities that Git has.

If you have any questions, suggestions or your own Git tips and tricks, feel free to leave them in the comments!

## Further learning

There are some concepts that we did not look into in this series of blog posts. The most important one is the staging area or index. I can recommend a blog post called [Git: Understanding the Index File](https://mincong-h.github.io/2018/04/28/git-index/) for more information on the index.

Another interesting topic is how Git discards unused objects and compresses lots of objects into a packfile. The man pages for [git-gc](https://git-scm.com/docs/git-gc) and [git-pack-objects](https://git-scm.com/docs/git-pack-objects) are a good starting point for learning about these topics. Your knowledge on the object database is very useful for understanding these topics.

In general, I can recommend looking at the man pages (e.g. `man git-commit`) when you want to know more about what a certain command does. Often it contains the information you are looking for, as well as a lot of interesting information that you would never learn about otherwise.

[^1]: The head of a branch is the commit that the branch points to, i.e. the latest commit on the branch.

[^2]: There is also a `--ff` flag. If you *want* a fast forward, you can use this flag and the merge will fail unless a fast forward is possible.

[^3]: `head` refers to the last commit, `~` means the parent of that commit. Check out the man pages for [git-rev-parse](https://git-scm.com/docs/git-pack-objects) if you want to learn more about how you can specify revisions.

[^4]: Or as Linus Torvalds calls it, a [Cthulhu merge](https://marc.info/?l=linux-kernel&m=139033182525831).