如何管理来自多个开发人员的合并更新? [英] How can I manage merging updates from several developers?

问题描述

我与一个中等规模的开发人员团队一起工作，他们都致力于一个产品.开发人员编写代码以解决功能或错误修复票证，然后将其签入我们的主要开发分支(在 Subversion 中).在 QA 人员在那里测试和验证票证后，我将其合并到主干中.我通常手动执行此操作，因为很多工单跨越多个修订版，这些修订并不总是连续的，并且可能一次包含多个工单的修复程序.

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.

我确信会有所帮助的一件事是鼓励开发人员每次修订只签入一张票.我们使用 Jira 来跟踪我们的任务，因此每个 Subversion 修订版都应该在日志中包含一个 Jira 问题 ID - 当我合并代码时，我会寻找包含我正在合并的问题的修订版.

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.

推荐答案

这个问题与 DVCS 无关.这是流程问题，而不是技术问题.以下是我对很多人正在做的事情以及 ClearCase UCM 推动的流程的看法:

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

当我修复我的错误时，我会将它提升回主干，或者我试图修复的特定版本.我将合并到 release-1.0-tfix 和主干，因为它需要在几个地方进行修复.完成后，我删除分支并继续下一个问题.因此，当我测试它并处理问题时，我有两个带有 JIRA 修复的代码分支(如果修复差异很大).

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).

但是除非运行成功的构建/测试周期，否则不会将任何内容提升到主干或 -tfix 树，并且它具有用于跟踪的 JIRA 属性.通过这种方式，您可以将每个单独的修复与开发人员、分支联系起来，并验证问题是否得到正确修复.此外，问题不会丢失(哦，JIRA1029 是否已进入 1.2 版?好吧，您可以通过在您的存储库中查找 JIRA1029 来验证这一点.您永远不必猜测，这就是使软件开发可重复并使我们更接近错误的原因== 0.

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.

这篇关于如何管理来自多个开发人员的合并更新?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！