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 git-rebase option no-one knows that will shock your coworkers!

We don't like to write the same code multiple times. If you have to apply any changes to projects that share files (the files you are editing), you can use git to accomplish this boring task.
This is the hypothetical directories structure where the 2 repositories of this example is located:

```plaintext
-- projects/
  |---first_repo_path/
  |---second_repo_path/
```
#### Create the patch

We can start looking for what commit we would like to start to create the patch with. Let's enter into the first repo and show the last commits:

```plaintext
$ cd projects/first_repo_path/
$ git log --pretty=oneline --abbrev-commit -3
a5f83e3 fixes security bug #123
789f90c fixes security bug #98
48c120e fixes problems with rails_admin
```

The second command print some important details on our commits. We can now detect our commit target ("789f90c" in our example) and create the patch with the command:

```plaintext
git format-patch -M 789f90c --stdout > fixes_security_bugs.patch
```

This will create the file *fixes_security_bugs.patch* the incapsulate the changes of the last two commits.

#### Apply the patch to other repository

To apply the patch to the other repository, we can move to his root and launch this command:

```plaintext
$ cd ../second_repo_path/
$ git am --signoff < ../first_repo_path/fixes_security_bugs.patch
```

Done!

#### Resolve possible conflicts

If there are any problems and the patch application fails no changes will be applied to the second repository. We can solve conflict using:

```plaintext
git apply --reject --whitespace=fix fixes_security_bugs.patch
```

that allows to apply only changes that don't create conflicts. Refused code will be placed in *.rej* files that we can manually apply to our original code.

The Nebulab

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

How to create a single patch from different git commit