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.
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.
We always enforce branch per task creation, in fact, each task (not story, but actual tasks as decomposed after the scrum planning meeting) will have at least one associated branch.
You can see how it looks like at the following diagram:
This makes things like encouraging peer reviews very easy, since the team can checked what was modified on a task (branch), even when developers decided to make many intermediate commits (which is a very good practice!)
There's a number of links below that can be helpful:
Whenever we have a story or a set of stories that threatens to leave the master branch in disarray for several days or involves 'many' developers we create a branch for that (not very common, we try to task things to avoid this, but it happens) as a sort of risk-mitigation thing. We want to be sure that the master branch is always ready for release at the end of each sprint, even if it potentially means that we might not have increased the value of the master branch after the sprint.
The story/feature/task branch is synchronized against the master branch very often, and the goal is to always have the branch merged back well before the end of the sprint.
Of course, we all use 'git', so in effect we always have a local branch that we work on, and we've become pretty good at synchronizing with master often enough to avoid big-bang integrations and seldom enough to not leave useless/unused code in the master branch.
Other than that, we do 'branch-by-purpose' (PDF). I also wrote a bit more about how we do git here.
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.
I don't see how a branch per feature can make you more agile or lean. The cost of branch management is just too high. I would argue that if you feel you need a branch per feature then your stories are too big. A story should be completed by the next scrum and if not, certainly by the next one. So if a branch only exists for 1-2 days I don't see how it can be useful or its cost repaid. It is routine for many people to work on a story so I sometimes use a dev branch for developers to work in so that they can merge code Many times per day while working on the same story without the code being deployed to test (main branch). Ideally you would have so few stories in progress and complete them so fast that you would only need the Main branch and no others.
发布评论
评论（7）
保持分支协议的轻量级。 在 Scrum 中，如果有人想要对代码进行分支以处理特定功能，那就让他们去做吧。 没有人应该害怕分支。 这是 DVCS 的好处之一 - 人们可以根据需要进行分支，并且不会受到团队规则或标准的偏见。
在我看来，这是一个具体案例的基础，如果您开始在开发过程中看到模式，那么请将它们正式化，以便每个人都在同一页面上。
只需确保每个开发人员都明白集成和合并他们的更改是他们的责任。 这应该将标准设置在正确的位置附近，以确保人们就何时分支代码做出正确的决定。
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.
每个用户故事一个分支对我来说听起来有点过分了。 我们保留一个单一的代码库（主干）并解决这个问题。 我们通常分支的唯一一次是修复当前的生产问题，而该问题不能等到常规版本发布。
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.
这实际上是一个非常有趣的话题。
我们总是强制每个任务创建一个分支，事实上，每个任务（不是故事，而是 Scrum 计划会议后分解的实际任务）将至少有一个关联的分支。
您可以在下图中看到它的样子：
这使得鼓励同行评审之类的事情变得非常容易，因为团队可以检查在任务（分支），即使开发人员决定进行许多中间提交（这是一个非常好的实践！）
下面的许多链接可能会有所帮助：
That's a very interesting topic actually.
We always enforce branch per task creation, in fact, each task (not story, but actual tasks as decomposed after the scrum planning meeting) will have at least one associated branch.
You can see how it looks like at the following diagram:
This makes things like encouraging peer reviews very easy, since the team can checked what was modified on a task (branch), even when developers decided to make many intermediate commits (which is a very good practice!)
There's a number of links below that can be helpful:
每当我们有一个故事或一组故事可能会让主分支陷入混乱几天或涉及“许多”开发人员时，我们就会为此创建一个分支（这种情况并不常见，我们会尝试分配任务来避免这种情况，但它发生）作为一种风险缓解措施。 我们希望确保主分支始终准备好在每个冲刺结束时发布，即使这可能意味着我们可能不会在冲刺之后增加主分支的价值。
故事/功能/任务分支经常与主分支同步，目标是始终在冲刺结束之前将分支合并回来。
当然，我们都使用'git'，所以实际上我们总是有一个我们工作的本地分支，并且我们已经非常擅长与 master 同步，足以避免大爆炸集成，并且很少足以不在 master 分支中留下无用/未使用的代码。
除此之外，我们还执行“按目的分支”(PDF) 。 我还在此处写了更多关于如何使用 git 的内容。
Whenever we have a story or a set of stories that threatens to leave the master branch in disarray for several days or involves 'many' developers we create a branch for that (not very common, we try to task things to avoid this, but it happens) as a sort of risk-mitigation thing. We want to be sure that the master branch is always ready for release at the end of each sprint, even if it potentially means that we might not have increased the value of the master branch after the sprint.
The story/feature/task branch is synchronized against the master branch very often, and the goal is to always have the branch merged back well before the end of the sprint.
Of course, we all use 'git', so in effect we always have a local branch that we work on, and we've become pretty good at synchronizing with master often enough to avoid big-bang integrations and seldom enough to not leave useless/unused code in the master branch.
Other than that, we do 'branch-by-purpose' (PDF). I also wrote a bit more about how we do git here.
我会为每个版本使用一个分支，并使用持续集成来防止一个用户故事破坏其他用户故事。
I would use one branch per release, and use Continuous Integration to keep one user story from damaging the others.
您应该对源版本控制系统进行的唯一更改是将其与持续集成系统集成（例如 TeamCity 或 CruiseControl.NET）。
是的，我知道我并没有真正回答你的问题，但我是认真的。 在敏捷软件项目中，您希望能够（或能够）尽可能频繁地向客户发布产品。 这就是为什么您需要知道源系统中的任何内容是否正常工作，或者如果不工作，为什么它不工作。
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.
我不明白每个功能的分支如何使您更加敏捷或精益。 分支机构管理成本太高。 我认为，如果你觉得每个功能都需要一个分支，那么你的故事就太大了。 一个故事应该由下一次 Scrum 完成，如果没有，当然也由下一次 Scrum 完成。 因此，如果一个分支仅存在 1-2 天，我不知道它如何有用或如何偿还其成本。 对于许多人来说，处理一个故事是例行公事，因此我有时会使用开发分支供开发人员工作，以便他们可以每天多次合并代码，同时处理同一个故事，而无需部署代码来测试（主分支） 。 理想情况下，您正在进行的故事很少，并且完成得很快，因此您只需要主分支，而不需要其他分支。
I don't see how a branch per feature can make you more agile or lean. The cost of branch management is just too high. I would argue that if you feel you need a branch per feature then your stories are too big. A story should be completed by the next scrum and if not, certainly by the next one. So if a branch only exists for 1-2 days I don't see how it can be useful or its cost repaid. It is routine for many people to work on a story so I sometimes use a dev branch for developers to work in so that they can merge code Many times per day while working on the same story without the code being deployed to test (main branch). Ideally you would have so few stories in progress and complete them so fast that you would only need the Main branch and no others.