问题
I work with a mid-sized team of developers all working on one product. Developers write the code to address a feature or bug fix ticket, then check it into our main development branch (in Subversion). Once the ticket has been tested and validated there by the QA folks, I merge it into the trunk. I normally do this manually, since a lot of the tickets span several revisions, which are not always sequential and may include fixes for several tickets at once.
One thing that I'm sure would help is encouraging developers to only checkin one ticket per revision. We use Jira to track our tasks, so every Subversion revision should have a Jira issue ID in the log - when I'm merging code, I go looking for revisions that include the issue I'm merging in.
Are there other ways I could manage this better? Do other teams branch off of the trunk for every ticket and issue? As I said, we have one main development branch, at least partly because we are building a lot of new functionality pretty quickly, and I imagine we would wind up with dozens of branches pretty quickly if we made one for each ticket.
回答1:
This question has nothing to do with DVCS or not. It's a PROCESS issue, not a technology issue. Here's my take on what a lot of people are doing, and the process that ClearCase UCM promotes:
/project/trunk
/branches
/release-1.0-JIRA1023
/release-1.0-darthcoder-JIRA1029
/darthcoder-JIRA1029
/branches/release-1.0-tfix <- This is the patch trunk. Main trunk is future dev
When I fix my bug, I'll promote it back to trunk, or the to the specific release I'm trying to fix. I'll merge to release-1.0-tfix, and to trunk, because it needs to be fixed in several places. When I'm done, I delete the branch and move on to the next issue. So I have two branches of code with the JIRA fix in it while I'm testing it and working on issues (if the fix is wildly divergent).
But nothing gets promoted to trunk or the -tfix trees unless a successful build/test cycle is run, and it has a JIRA property for tracking. This way you can tie each individual fix back to a developer, a branch, and verify things get fixed properly. Also that issues don't get lost (oh did JIRA1029 make it into version 1.2? Well you can verify that by looking for JIRA1029 in your repository. You never have to GUESS, and that's what makes software development repeatable and gets us closers to bugs == 0.
回答2:
Are you working on concurrent releases? For all of my projects that don't have much concurrent release development (usually < 10 devs), we work in trunk. A single checkin should only apply to a single ticket. If it just happens to fix another ticket the ticket is updated and marked for test.
Why are you merging? Is that your code review or your way of ensuring that the build isn't broken. I personally would set up some continuous integration and skip this step. You should be able to trust your developers not to break the build and have CI catch them if they do.
来源：https://stackoverflow.com/questions/1213697/how-can-i-manage-merging-updates-from-several-developers