What's the best way to transfer a GIT-SVN debug->feature branch to trunk?

Question

I've got a trunk setup where all my production code goes.

Then I have a debug branch (parent is trunk) which I add debugging code such as logging, var dumps, etc... this should never be in production. This branch rarely changes.

Lastly I have a feature branch (parent is debug) where I do all my coding with the benefits of debugging. There are constant commits to this branch.

I just want to know if there is an easier way to move my feature code to the trunk. This is what I currently do:

1. Commit all changes to my feature branch
2. Switch to master and git svn rebase changes from other devs.
3. rebase my feature branch onto the master branch (git rebase --onto master debug feature)
4. merge feature to master
5. git svn dcommit changes to other devs
6. rebase debug to master (git rebase master debug)
7. delete feature branch
8. create a new feature from the debug branch.

Answer 1

We have a separate branch for each feature or bug fix we do. These can then be merged back to trunk when they have been sufficiently tested.

Branches can be updated if they become a bit old.

We tend to release minor changes directly to trunk, but for more major changes we gather them into a release candidate branch into which we merge all the relevant branches containing changes to go live. This new branch can be deployed and tested to see if combining changes breaks anything, before it is finally merged back to trunk and goes into production.

This method creates a lot of branches, but since we name these related to our issue tracking system they are easy to keep track of. It is nice an easy to either include or exclude any changes to a release.

Hope that helps

Answer 2

I think what you're looking for is git-cherry-pick. This allows you to apply commits from feature on master without doing the rebase dance you describe.

Since you're going to delete the feature branch anyway you don't need to see an explicit merge I presume.

Answer 3

I would say that your work-flow is pretty optimal. I would consider cherry-picking to be an overkill (but it depends on the number of commits).

What you could do is squash all the commits into one and cherry-pick/rebase just this one.

And btw, why just don't write a simple script if it is something you do all the time? Git is a bit low level tool, so writing extra scripts to help with repetitive tasks is a very good idea.

Answer 4

Ok, I'll say an heresy and everybody will down vote me, but let's go. If you used svn directly, your workflow would be a lot simpler.

With the --reintegrate feature of subversion it is easy to maintain your trunk and debug branch in sync. To merge your feature branch, you'd merge all the modifications of the feature branch in the trunk. The commands would be something like:

To merge the trunk to debug:

cd debug_branch_workcopy
svn merge --reintegrate http://server/project/trunk .
svn commit

To merge the feature branch to to trunk:

svn log --stop-on-copy http://server/project/branches/feature123 #see the last revision listed
cd trunk_workcopy
svn merge -r{revision_above}:HEAD http://server/project/branches/feature123 .
svn commit

You can run the last merge command multiple times if you change the branch after the merge. Subversion will remember the already merged revisions and won't try to do them twice. If you are in Windows, the free TortoiseSVN will give you a nice merge interface.

BTW, I'd try not to have a separate branch just with debugging features. It is too easy to make a manual error and send debug code to your production trunk. I'd use something more dynamic to not run the debug code while in production.

Answer 5

Your workflow is complicated because what you are trying to do is complicated. No VCS that I know of lets you easily maintain some changes that should never be merged. It says a lot about the power of git that your workflow is not harder than it is.

I assume your language has some sort of conditional compilation mechanism (#IFDEF preprocessor directives, etc). If you wrap your debugging code in these instead you'll experience much less friction.

Answer 6

If I understand you correctly, you'd like to have your debug features only in your (pretty static) debug branch, but not in your master branch. Try this:

Do a "fake merge" of debug into master

git checkout master
git merge --no-commit debug
git checkout master .        # undo all changes, get the files from master again
git add .                    # stage all files
git commit

This way, debug will be merged into master, but none of your files in master will have changed.

Now you can simply create your feature branches on top of debug, and merge them into master when you're done. Git now knows that the debug features are stripped from master:

git checkout debug
git checkout -b new_feature  # create a new feature branch
# hack, hack, hack
git commit
git checkout master          # All works fine...
git merge new_feature        # ...so merge into master. Debug code will be stripped here

You can fast-forward the debug branch on new_feature and delete the new_feature branch after this.

Note that whenever you change the debug branch, you have to redo the fake merge procedure.