Reputation: 1603
I have a branch with a few commits I'd like to interactively rebase. However, after pulling and merging there are now other commits interleaved with mine so I can't just do something like git rebase -i HEAD~3
Is it possible to do an interactive rebase while choosing individual commits? Something like git rebase -i 23duirs 3eujsfe ...
Another possibility-- If I simply run git rebase -i
I believe it's possible to cut and paste my commit lines to be consecutive, and squash from there, is that correct? Is there a best practice for doing so, to minimize the chance of conflicts with the unrelated commits in there?
Upvotes: 9
Views: 21964
Reputation: 1050
Little hacky solution.
Create a new local branch(LOCAL_B) from the origin. cherry-pick your commits from LOCAL_A to LOCAL_B and squash them using git rebase -i HEAD~3
.
Now, take a backup of LOCAL_A for safety.
Delete LOCAL_A. Create new local branch LOCAL_A from the remote. Cherry-pick the squashed commit from LOCAL_B to LOCAL_A.
you are done.
Upvotes: 0
Reputation: 41488
Rebasing after a merge is a pain in git.
I generally try to avoid this issue, by not merging others' work, but instead I fetch and rebase
git fetch upstream
git rebase upstream/master
(you can also use git pull --rebase upstream master
, but this has a drawback of not updating your remotes/upstream/master
tracking branch, which git fetch
does; hence I prefer fetch && rebase
instead of pull --rebase
).
That way, my commits are always on top of everything in master, until my development is ready, then I open a pull request with a clean history without merges I.e. at any point in time, last n commits in the branch that I am working on, are my commits, and I can easily reword, squash them etc.
The easiest way to amend some old commits is git rebase -i
, and the param you pass to git rebase -i
is a single commit-ish; all the commits newer than the provided commit will be displayed in the interactive rebase screen. I don't know of any way for this screen to just display some commits newer than the param.
The alternative to change old commits is git filter-branch
, but it's rather much more complicated to use.
Upvotes: 4
Reputation: 108169
Given this
pick <unrelated a>
pick A
pick <unrelated b>
pick B
pick <unrelated c>
you can definitely do
pick <unrelated a>
pick <unrelated b>
pick <unrelated c>
pick A
squash B
Provided that your commit are really unrelated to the other changes, this will work just fine.
Upvotes: 7