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:
git checkout master
git revert <triage-commit> # could do this for multiple commits if needed
git merge bugfix-branch
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:
# start back from master
git checkout -b master-merge master
# merge your fixes
git merge bugfix-branch
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 can git add
them 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, and git commit
to 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 theirs
to 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-svn
has 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 rebase git 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 with git checkout master; git merge bugfix-branch
.