Working on a project with git, I have two feature branches, call them dev-a and dev-b, branched from my develop branch (which is branched from master).
I worked on dev-a for a bit, finished it, and merged it back into develop, did a little work on develop, and started on dev-b, worked for a bit, then found something that should have been done on dev-a, so I checkout dev-a, and fix it. My DAG now looks like this:
commit hashes are obviously made up and not real hashes; they’re just for reference
* 008 - (dev-a) Fix problem on dev-a
|
| * 007 - (dev-b) Work on dev-b
| * 006 - Work on dev-b
| |
| * 005 - (develop) Work on develop
| * 004 - Work on develop
| * 003 - Merged dev-a
|/|
* | 002 - Work on dev-a
* | 001 - Work on dev-a
\|
* 000 - Work on develop
|
What I want to do, though, is have that commit happen “before” the merge, so that I can rebase develop and dev-b on top of it, keeping everything neat and tidy:
* 007 - (dev-b) Work on dev-b
* 006 - Work on dev-b
|
* 005 - (develop) Work on develop
* 004 - Work on develop
* 003 - Merged dev-a
/|
* | 008 - (dev-a) Fix problem on dev-a
* | 002 - Work on dev-a
* | 001 - Work on dev-a
\|
* 000 - Work on develop
|
It’s also important to note that the fix for dev-a won’t conflict with any later commits – it’s a fairly small change to a single file. All of the relevant commits are local and haven’t been shared.
I’m fairly certain I can do this, as git is fairly flexible, but I don’t know for sure if it’s possible, how to do it, or whether it’s a good idea.
This is all very straightforward, just do the merge again and rebase everything against it.