A few weeks ago, a moment before pushing upstream a glorious bug-fix, I ran the test suite locally, just to discover that I broke it!

Having lost all confidence in the commit history, I was out for blood, looking for the piece of code that ruined the whole PR!

![](https://cdn.sanity.io/images/kqgmf0g2/production/ea604b184a38f8c019f7319af3a16fd26c8c4487-640x418.gif?fit=clip)

With more than a hundred git aliases I consider myself quite a git nerd, so I reached out for a tool I knew: `git rebase`.

My plan was:

1. mark each commit with `edit`

2. run the test suite with `bin/rake` at each stop

3. identify the offending commit and fix whatever bugs I encountered

4. amend the commit and call it a day

That didn’t feel right tho, it was too clunky, I had a hunch that I could have done better than this! So, after reading once again the `git rebase` documentation, this little option popped out: `git rebase --exec`!

## What `--exec` does to `git rebase`

The magic of `--exec` is that it will execute a command after each commit in your interactive rebase. If the command fails, it will stop the rebase, allow you to fix whatever needs to be fixed, and move along with `git rebase --continue`.

This means that I was able to swiftly run this command after each commit and ensure that I had a green suite at every step of the PR.

```
git rebase --interactive --exec "bin/rake" origin/master
```

Don’t forget that this neat trick can be used for all kinds of problems, like, for example, running a linter for every commit of a PR.

The Nebulab

The git-rebase option no-one knows that will shock your coworkers!