What I would have loved is for git checkout branch2 ; git rebase -i master
to show me branch1
directly in the editor, and then when I save the editor, that the branch1 got updated accordingly. So I could move a commit from branch2 to branch1 directly in git rebase -i
and have that "stick". Maybe with a '--rebase-branches' or something.
So arrhhh, I share your pain.
What I do is somwhat of a hack that mimics this missing feature. I often find that during creating long-lived branches, I keep accumulating stuff that should've gone into master before "this" branch. Fixing coding standard breaches, discovering and fixing obvious errors, documentation updates for existing code, etc. This is what I'd use your branch1
for. And then the commits that actually are part of my new feature go in branch2
.
So what I do instead of creating a branch1
branch is to create a branch1
pseudo-branch "marker" - a tiny commit that I'll throw away later with git rebase
. I create it like:
touch marker.master
git add marker.branch1
git commit -m "*** BRANCH1 ***" marker.branch1
Now when I create commits, I mix commits that should go into master before this branch and "new" commits for this actual branch.
When it becomes time to clean up / rebase, I git rebase -i master
. Now my *** BRANCH1 ***
commit is obvious in the list of commits, and I can move commits destined for branch1
up above that "line".
Because I don't have an actual branch1
branch, git rebase master
does exactly what I want, it moves branch2
and my branch1
pseudo-branch marker as one unit.
When I'm done rebasing and am ready to push, I manually make a note of the commit ID for *** BRANCH1 ***
, say abcdef1
, and then:
git checkout -b branch1 abcdef1^
Then:
git checkout branch2
git rebase -i branch1
And remove the abcdef1
commit.
This way I can easily move commits between my branch1
and branch2
branches during git rebase -i
and only actually create a real git branch1
branch at the very end.
But oh, I'd really like for git rebase -i
to do this for me!