Git Rebase or SVN Reintegrate for Feature Branches?

We are currently using S开发者_如何学运维VN, but considering moving to Git to support our new workflow, which relies heavily on rebase.

We're considering a development workflow where each individual feature is developed on a separate branch, then merged into trunk/master when it's ready for release. The branch will always be deleted after it is merged back into trunk/master.

One proposal is to use git rebase to keep the feature branch up-to date with changes in master (so we can test in the branch exactly what will be released), and to simplify the merge from branch -> master.

The alternative we're considering is to use svn merge to keep the feature branch up-to-date with changes in trunk, then using svn merge --reintegrate to merge the feature branch back into trunk for release.

What are the differences and potential pitfalls of each of these approaches? And which is more appropriate for our workflow?

This is a really straightforward workflow in git. Several developers use one or both of the methods you described.

Personally, I'm a fan of scott Chacon's strategy and have found it really useful.

You can rebase to keep the master branch in a linear history, and that's normal, but it does have a slight possibility of throwing some major loops to guys just starting out in git. Rebasing changes history and can really cause problems if you're not careful.

Git-merge (not the svn-merge --reintegrate you noted) is a little more straightforward in git if you're just starting out. Git's merging strategies are really well thought out and automatically keep you out of trouble.

If I'm developing on feature branch and then merging it into master, I like to run git merge --no-ff feature while on master to create the merge commit just to be explicit.

As you're just starting out with git, I'd go for the merge workflow. IMHO, it's more intuitive if you're coming from a svn background.