When I have a fix for a change that was a few commits earlier, I always wind up running rebase twice in a row. Is it possible to do this workflow all in one step? Let's say I have 4 new commits.
* (master) D
* C
* B
* A
* Base
I find a bug in B so I create a branch and fix it.
* (master) D
* C
| * (fix) Fix.
|/
* B
* A
* Base
Next I run git rebase --onto fix B D
to move C and D onto B.
* (master) D'
* C'
* (fix) Fix.
* B
* A
* Base
Finally I run git rebase --i fix^^
to see the last few commits and I squash B and Fix into a single commit.
* (master) D'
* C'
* B'
* A
* Base
Is there a faster way to accomplish the same workflow? I imagine that merging would be easier, but merging is out for me because I'm using git svn which requires a linear history.
When the editor for the commit list in an interactive rebase shows up, you are free to add, remove or reorder commits to your liking. It's basically a way to influence the cherry-picking-in-a-loop that is going to take place (that's what rebase boils down to).
Are you aware of the --squash
option to git merge
?
--squash
Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit or move the
HEAD
, nor record$GIT_DIR/MERGE_HEAD
to cause the next git commit command to create a merge commit. This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With