20

Recently with my coworkers we were discussing how to organize the version control in a Scrum project. More specifically, the criteria for branches creation (per developer, per task, per Story, per Sprint?) and the methods of integration.

My opinion was that a useful way to organize it is to create a branch for each User Story, so you can integrate each Story in the releasable trunk once it is completed and it also allows that you always have a "deliverable version" of the application at any moment.

So if a story cannot be completed, it can be just left out and does not compromise the sprint release. (That considering a centralized tool, may be if using a distributed one the considerations would be different)

I'd like to know your own approaches, which kind of tools you prefer and the pros and cons that you have seen with the experience and the lessons learned.

4

7 回答 7

8

Keep branching protocol light-weight. In Scrum, if someone wants to branch the code to work on a specific feature, let them. Nobody should be afraid to branch. This is one of the benefits of DVCS - people branch when they want and aren't biased by team rules or standards.

For my money, it's a case-by-case basis, and if you start seeing patterns in your development processes then formalize them so everyone is on the same page.

Just make sure that every developer understands that it is their responsibility to integrate and merge their changes. That should set the bar to around about the right place to ensure people make the right call as to when to branch the code.

于 2009-03-09T23:44:19.460 回答
5

A branch per user story sounds quite excessive to me. We keep a single code base (trunk) and work out of this. The only time we would normally branch is to fix a current production problem which could not wait until a regular release.

于 2009-03-09T23:35:36.847 回答
4

每当我们有一个故事或一组故事威胁要让主分支混乱几天或涉及“许多”开发人员时，我们都会为此创建一个分支（不是很常见，我们会尝试分配任务来避免这种情况，但它发生）作为一种降低风险的事情。我们希望确保主分支始终准备好在每个 sprint 结束时发布，即使这可能意味着我们可能没有在 sprint 之后增加主分支的值。

故事/功能/任务分支经常与主分支同步，目标是始终在冲刺结束之前将分支合并回来。

当然，我们都使用 ' git '，所以实际上我们总是有一个本地分支来处理，而且我们已经变得非常擅长与 master 同步，经常足以避免大爆炸式集成，并且很少不会留下无用的/主分支中未使用的代码。

除此之外，我们做'按目的分支'（PDF）。我还在这里写了更多关于我们如何做 git的文章。

于 2009-03-10T16:12:34.687 回答
4

这实际上是一个非常有趣的话题。

我们总是在每个任务创建时强制执行分支，事实上，每个任务（不是故事，而是在 Scrum 计划会议之后分解的实际任务）将至少有一个关联的分支。

您可以在下图中看到它的样子： 替代文字

这使得鼓励同行评审之类的事情变得非常容易，因为团队可以检查任务（分支）上的修改内容，即使开发人员决定进行许多中间提交（这是一个非常好的做法！）

下面有许多链接可能会有所帮助：

  1. 每个分支的任务详细
  2. 4步走敏捷！
  3. 还有一个关于它的截屏在这里。
于 2009-04-30T22:39:55.827 回答
1

I would use one branch per release, and use Continuous Integration to keep one user story from damaging the others.

于 2009-03-09T23:45:14.373 回答
1

The only change you should do to your source versioning system is to integrate it with the continuous integration system (like TeamCity or CruiseControl.NET).

Yeah I know that I am not really answering your question but I really mean it. In agile software project you want to be able to release the product to customers (or be able to) as often as possible. That's why you need to know that whatever is in your source system is working or if it is not working why it is not working.

于 2009-03-10T02:07:42.597 回答
-1

我看不出每个功能的分支如何使您更敏捷或更精简。分行管理的成本太高了。我会争辩说，如果您觉得每个功能都需要一个分支，那么您的故事就太大了。一个故事应该在下一次 Scrum 中完成，如果没有，肯定在下一次完成。因此，如果一个分支只存在 1-2 天，我看不出它有什么用处或它的成本如何偿还。许多人处理一个故事是例行公事，所以我有时使用开发分支供开发人员工作，这样他们就可以每天多次合并代码，同时处理同一个故事，而无需部署代码进行测试（主分支） . 理想情况下，您将有如此少的故事在进行中并且如此快速地完成它们，以至于您只需要主分支而不需要其他分支。

于 2009-03-10T01:41:17.603 回答