如何在不污染基线的情况下对代码进行分支？
使用 TFS，我们有以下内容：
- 主基线
- 每个开发工作的开发分支。这些被合并回基线。
- 随每个版本创建的发布分支。错误修复在这里进行、发布并合并回基线。
- 使用架子集，如果需要，我们可以在开发分支之间共享代码，而不会污染基线。对于代码审查很有用。
- 当我们将开发更改交付到基线时，我们会启动一个自动构建，并自动将我们的更改放置在测试服务器上。
问题是业务分析师在测试服务器上之前无法看到我们的更改，而目前在测试服务器上获取更改的唯一方法是将它们签入基线。因此，如果 BA 发现有问题，不幸的是，代码已经在基线中，我们将不得不费尽心思将其删除。
有没有一种方法可以改变我们的分支策略或流程，以获得 BA 想要看到的内容，而又不会污染我们的基线？
Using TFS, we have the following:
- A main baseline
- A development branch for each development effort. These get merged back to the baseline.
- A release branch that is created with each release. Bug fixes are made here, released, and merged back to the baseline.
- Using shelvesets, we can share code across development branches if needed without contaminating the baseline. Useful for code reviews.
- When we deliver our development changes to baseline we have an automated build that kicks off and automatically places our changes on the test server.
The problem is that the business analysts can't see our changes until they're on the test server, and currently the only way to get our changes on the test server is to check them into baseline. So if the BA's find something wrong, the code is, unfortunately, already in baseline and we would have to go through the trouble of taking it back out.
Is there a way we can change our branching strategy or process to get the BA's what they want to see without contaminating our baseline?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你们的分支策略听起来正是我们在我公司决定的。我认为问题不在于您的分支策略，我认为问题在于您必须检查基线中的更改才能将它们应用到测试服务器。
在我的公司，更改在升级并在生产中运行之前不会被签入基线。发布分支是部署到测试服务器的内容……如果发现错误，或者 BA 想要更改某些内容，我们不必经历从基线中删除更改的痛苦。
但是，如果您有很多并发版本，那么在将所有版本移至生产环境之前将它们合并在一起可能会变得很痛苦，因为直到过程的后期您才会合并到基线中。在我的公司，我们有一个非常严格的发布时间表，并尝试一次只让一个版本投入生产。因此，等待将版本合并到基线中直到版本升级到生产环境并没有给我们带来任何问题，或者到目前为止的额外工作......
您多久发布一次？您是否能够将发布分支部署到测试服务器上，并让基线代表当前生产中部署的内容？
（我会对此发表评论，但我仍在努力赢得这一特权......）
Your branching strategy sounds exactly what we decided on at my company. I don't think the issue is with your branching strategy, I think the issue is that you have to check changes into the baseline in order to apply them to the test server.
At my company, changes aren't checked into the baseline until they are promoted and running in production. Release branches are what are deployed to the test servers... if bugs are found, or the BAs want to change something, we don't have to go through the pain of removing the changes from the baseline.
However, if you have a lot of concurrent releases, this can become a pain to merge all of the releases together before moving them to production, since you aren't merging into the baseline until later in the process. At my company, we have a very strict release schedule, and try to only have a single release working its way to production at a time. Because of this, waiting to merge the release into the baseline until the release has been promoted into production hasn't created any issues for us, or extra work so far...
How often do you do releases? Would you be able to deploy release branches onto your test servers, and have the baseline represent what is currently deployed in production?
(I'd make this a comment, but I'm still working on earning that privilege...)
我不喜欢这种方法，我建议：
包含稳定代码的主要基线。发布成功后，代码才会从各自的发布分支合并到该分支中。
从 Main 为每个版本创建的 Release 分支。该分支将用于生成发布版本并将部署到测试环境。
从发布分支创建的开发分支，它将用于开发工作，并在我准备好进行构建测试时合并到发布。
I would not prefer this approach, I would suggest:
A main baseline which contains stabilized code. The code will be merged into this branch from respective release branch only after successful release.
A Release branch which gets created from Main for each release. This branch will be used to generate Release Builds and will be deployed to test environment.
A Development Branch created from Release Branch, it will be used for Development efforts and will be merged to Release when I'm ready to give my build to test.