Sequence:
- commit some code on trunk
- discover that it’s got a nasty problem.
- make a branch
- delete code on trunk (deleting entire files)
- fix code on branch
Now I want to bring the whole business back onto the trunk. A merge won’t do it, I think. What will?
Assuming there’s no git-svn craziness here (I’m not sure if your use of the word “trunk” means you came from svn and kept terminology, or are actually interacting with it)…
The cleanest way to do this, assuming your “delete code on trunk” triage step was done in an isolated commit, is to revert that commit, then merge:
If it’s not that clean, merging is the way to go; you’ll just have to handle some things. You might want to do it on a test branch just in case:
At this point, you should run into a lot of “deleted by us” conflicts (that’s how they’re reported by
git status). This indicates that they were deleted on “our” branch (master) but modified on the to-be-merged branch. It will leave the versions from the to-be-merged branch in the tree. You cangit addthem to mark them as resolved. If you have conflicts that aren’t of this form, you’ll have to work through them as usual. Once you’ve fixed it all, inspect the results, test, andgit committo complete the merge.If you’re confident that all conflicts will result from this triage/bugfix scenario, then you could have used
git merge -X theirsto tell Git to resolve all conflicts by keeping “their” version (the one from the bugfix branch). Only do this if you’re sure!git-svn note: I’ve heard that
git-svnhas issues with merges. I’ve never used it, I have no idea how it works, but if it’s the case that you’re not supposed to have merges in anything you intend to send back to the svn repo… then instead of merging above, you could rebasegit rebase master bugfix-branch. You’ll run into exactly the same merge conflicts. Once you’ve dealt with them, you can fast-forward master up to the newly-transplanted branch withgit checkout master; git merge bugfix-branch.