SonaQube is great tool for monitoring quality of source code.

Gradle projects can be easily integrated with SonarQube by Sonar Runner Plugin.

You can start analysis by command:

gradle sonarRunner

This works perfectly on command line, but execution by Bamboo CI terminates with following error:

ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: Missing commit 4a3e...237f

The problem is that Bamboo creates shallow git clones by default. You can find this options under Repositories tab – Advanced options.

Solution: disable “Use shallow clones” options and start job again.

Correct configuration:


Result: 🙂


Do you use git? Then you probably know the basic commands like git pull, git merge and git rebase. These are pretty common, but also complex. Over the time, I have adopted few simple rules which help me to use them effectively.

Git pull considered harmful

You have probably noticed that sometimes your git pull generates automatic merge commits. They do not hold any useful information and if your repo is busy, your history can be literally flooded.

I like to keep my history linear and simple. That is why I recommend to set the default git pull configuration to fast-forward only (linear type of merge which does not create any commits).

With Git 2.0 and newer, you can just update your settings:

git config --global pull.ff only

Older versions do not have this option, but you can use an alias instead:

git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'

@{u}” is a shortcut which reffers upstream of the tracked branch.


git up

Rebasing non-linear changes

When the fast-forward merge is not possible, the default git pull behavior would be a three-way merge. But in order to keep the history clean, rebase can be used.

You might have heard, that rebase is evil (git rebase hell), but as long as your rebased commits are only local, you should be safe.

Again, I recommend an alias:

git config --global alias.upr '!git remote update -p; git rebase -p @{u}'


git upr

The git pull --rebase does a similar thing, but it currently doesn’t have an option to rebase merge commits, so you can end up with a slightly different history. Git rebase -p will try to replay merge commits and preserve your history.

Clean up your commits before publishing

Before you push your commits to the repository, it’s good to revise them.  You can run the git interactive rebase to squash your commits or modify commit messages.

An alias for the interactive rebase of unpushed commits:

git config --global alias.ri '!git rebase -i @{u}'


git ri

The goal is to publish only clean and relevant commits, no experiments or fixing typos. Therefore I usually do the git rebase and push at the end of my programming sessions (typically at the end of the day), so I see all the commits in one place.

Keep in mind that interactive rebase does not preserve merge commits (combining interactive rebase and preserve merge is not recommended), so you might want to do it before you merge a new branch.

Three-way merge between branches

Three-way merge is a non-linear merge with conflict resolution. It should be always used when merging non-local branches:

  • Merge of feature branch to the master
  • When you are working on a feature in a branch and you would like to merge commits from master.

This type of merge generates the merge commit, which serves as a source of information about the merge (branches, commits, time and date, responsible user).

How to force a three-way merge:

git merge --no-ff the_other_branch

Replace the “the_other_branch” with a name of  the source branch for merge to your current branch.


  • Disable automatic three-way merge with git pull.
  • If you cannot pull with a fast-forward merge and your commits are only local, run the rebase with preserve merges enabled.
  • Use three-way merge for merging between branches or when updating you feature branch.
  • Before push, revise your commits and clean them with interactive rebase if needed.


Never rebase any pushed or pulled changes (not branches, nor commits).

Want to know more?

You made changes in your repository. You made the commit and at the very same moment you realize that it’s not completely correct.

You need to fix the last commit.

Git provides possibility to amend last change.

Type command for git gui interface:

git gui


Click radio button Amend Last Commit.


You can change the commit message or remove staged item by double click.


When you made all necessary changes click Commit.


Sometimes it is necessary to work only with text console.

Git provides rich command line interface, but browsing history is little bit cumbersome.

If you like command line tools and email client mutt then there is awesome tool for you: tig.

tig is text mode interface for git.

Just enter directory with cloned git repo and type:



Quick navigation:

  • Enter – show details
  • Tab – switch window pane
  • q – quit

You can find more information at

This tool is available for Mac and Linux. Windows version is available in Cygwin.