The merging did work most of the time.  There were conflicts where two people edited the same line in the file, but I don’t see how you can get around that sort of thing. 

BTW, we’re trying to settle on a workflow for using Git, which is why I was interested in this page.  I’m used to the flow of committing to a main line or trunk, and when a release is done, branching at that point to support the release (e.g. fixes made on the branch and merged to trunk).  Do people work that work that way with Git?  For a small group with a release cycle of every month or so that seems more straightforward than the flow of having a gatekeeper merge my branch to master and then master to stable.  We’re small enough that the gatekeeper is likely to be the person making the change.

* You need to remember what the last merge point was, and provide it as command line option when doing the merge. Other tools like git work even if you can’t remember the last point you did a merge at
* The conflict resolution algorithm in SVN is not as advanced as with most other tools. That means you spend more time having to resolve the conflicts after a merge

We worked slightly different to you. We tried to stick to the concept of “Done done”. which means we do not start on a new feature until the first one is totally done, and has been QA’ed. This feels a bit slower at first, but forces you to smooth out this process, and saves you all the time of context switching back to the old feature if there are QA issues (and there always are! :-) )

What do developers pull from to populate their local repos in the work-flow you describe? stable or master?

Also, in my case, when multiple branches are “good to go”, development cannot stop while deltas are queued up for QA tests. But we don’t know yet if they will be accepted. Still developers may need to build on top of the changes that are pending in the QA queue. How do you think this should be addressed? – Thanks, Martin.