TFS 2010 - 我们有代码分支。告诉开发人员要编码哪个分支的最佳方法是什么？
根据您的经验，指定工作项的编码位置的最佳方法是什么？您使用特定字段吗？目前，我们在 WIT 中使用自定义的“要修复的版本”字段，但它与开发或主线代码分支不直接相关。我们最终会沟通哪些版本（v6.1、v6.2 等）与哪些分支相关，但仍然需要完成“映射”。这实际上只适用于已发布版本中的“修补程序”，因为分支的名称与“要修复的版本”相同。如何指定工作项，以便开发人员轻松知道在哪里编码并提供最少的维护？
更新：只是为了澄清一点......我们有 Dev、Main 和 Release（每个版本一个）分支。我们 90% 的开发都是在 Dev 中完成的。一旦迭代结束，我们将 Dev 反向集成到 Main，但此时我们不会发布它。在 Main 上进行了一段时间的测试，并且可以在 Main 上修复某些错误。当开发中的下一个迭代（新故事）继续进行时，这一切都会继续。一旦 Main 上的情况看起来不错，我们将分支到新版本（新的 Release 分支），并且 Main 上的开发将结束，直到下一次迭代开始，我们再次从 Dev 反向集成到 Main。当然，一旦 Main 上的问题得到解决，我们就会将 Main 集成到 Dev。在任何时候，我们都可能有一个错误需要在开发版本、主要版本或发布版本上修复。我们在 Main、Dev 和 Release 中进行错误修复，这让一些开发人员感到困惑。我们告诉他们“版本”，但他们必须知道未来或当前版本链接回哪个分支。这就是我试图找到任务工作项的最佳实践的地方。
What's the best way in your experience to designate where work items should be coded? Do you use a particular field? We currently use a custom "Version to Fix" field in our WIT, but it doesn't relate directly to Dev or the Main line code branches. We end up communicating which Versions (v6.1, v6.2, etc) relate to which branches, but there is still a "mapping" that needs to be done. This really only works for a "Hot Fix" in a released version because the branch is named the same as the "Version to Fix". How are work items designated so that is easy for developers to know where to code and provides the least amount of maintenance?
Updated: Just to clarify a bit ... we have Dev, Main, and Release (one for each release) branches. We do 90% of our development in Dev. Once an iteration has ended we reverse integrate Dev to Main, however we don't release it at that point. Testing is done on Main for a while and select bugs could be fixed on Main. This all goes on while the next Iteration (new stories) moves on in Dev. Once things look good on Main we'll branch to a new version (new Release branch) and development on Main will end until the next iteration starts and we again Reverse Integrate to Main from Dev. Of course we forward integrate Main to Dev once things are fixed on Main. At any point we may have a bug that we want fixed on Dev, Main, or on a Released version. Where we have bug fixes going on in Main, Dev, and Release we are confusing some developers. We tell them the "version" but they have to know what future or current version links back to what Branch. That's where I'm trying to find the best practice with the Task work item.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以在一个分支内拥有多个版本（变更集），但分支的扩散并不是一个好主意。
一个简单（但功能强大）的分支策略是创建一个主分支，然后创建 2 个子分支：1) Dev，2) QA 现在问题是没有问题的。开发人员在 Dev 分支中开展工作。当他们准备好时，他们会将更改反向集成到 main 中。然后将更改向前集成到 QA。如果构建通过了 QA，则可以将其投入生产。
一些组织将采用特殊的分支实践，例如为新的主要版本创建分支，甚至为特殊功能创建分支。它们遵循反向集成到主分支（以及适当时的后续正向集成开发分支）的相同过程。
构建可以链接到变更集。如果特定构建有错误，开发人员会查找变更集编号，将其从版本控制中拉出，检查将其与错误的适当工作项关联起来的工作，然后重建它。该新的“错误修复”版本现在具有与其关联的唯一构建 ID 和变更集 ID。
You can have multiple versions (changesets) within a branch, but the proliferation of branches is not a good idea.
A simple (but powerful) branching strategy is to create a main brach, then create 2 children: 1) Dev, 2) QA Now the question is a non-question. Developers do their work in the Dev branch. When they're ready they reverse integrate changes to main. Then changes are forward integrated to QA. If the build passes QA, then it can be rolled to production.
Some organizations will employ special branching practices like creating a branch for a new Major version or even a branch for a special feature. These follow the same process of reverse integration into main (and subsequent forward integration dev branches when appropriate).
Builds can be linked to changesets. If a particular build has a bug, the developers look up the changeset number, pull it down from version control, check the work in associating it with appropriate work items for the Bug, and rebuild it. That new "bug fix" version now has a unique build id and changeset id associated with it.
这实际上取决于您的商店；我们的环境采用迭代构建，因此错误修复始终进入最新的分支（通过日期戳命名 - IE Branch_05252011 左右）。
如果您有其他类型的版本控制/分支策略，最好的选择是将所需的修复分支放在标题中：
或者，我相信 TFS 甚至还可以提供一个专门的下拉列表，您可以在创建工作项时填充该下拉列表自定义内容。然后，您可以使用要定位的分支来填充该分支。
That's really going to depend on your shop; our environment works on an iterative build, so the bug fixes always go into the most recent branch (named via date stamp - IE Branch_05252011 or so).
If you have some other kind of versioning / branching strategy, the best option would be to place the desired fix branch in the title:
Alternatively, I believe TFS can also even offer a specialized drop down that you can populate when creating the work item with custom content. You could then populate that with the branch to target.
这是一个非常有效的解决方案：使用 TFS Power Tools 设置签入策略，并将自定义路径策略与工作项查询策略相关联，以便分支的所有签入都需要与属于某个工作项的工作项关联。特定于分支机构的查询。这样，如果签入没有与分支匹配的工作项，则不会被允许。可以使用您需要的任何条件来定义查询，并且可以根据需要更新查询本身并将其重新分配给不同的分支。
但需要注意的是：查询本身是在客户端进行评估的，因此作为管理员，您可以更新查询以阻止或允许某些项目进入分支，但开发人员需要刷新团队资源管理器来更新其查询，否则可以允许未经授权的项目进入，也可以阻止授权的项目。我正在研究这个问题的一个解决方案是添加一个自定义的签入策略，该策略将始终得到满足，但同时会导致 VS IDE 刷新团队资源管理器。我已要求 MS 将此直接添加到他们的 TFS Power Tools 工作项查询签入策略中，但他们尚未回复。
Here is a very effective solution: Set up a check-in policy using TFS Power Tools, and associate a Custom Path policy with a Work Item Query policy, so that all checkins for a branch will require association with a work item that falls into a branch-specific query. That way if the checkin does not have a work item that matches the branch, it will not be allowed. The query can be defined using whatever criteria you need, and the queries themselves can be updates and reassigned to different branches as needed.
One caveat, however: the queries themselves are evaluated at client-side, so as an administrator you can update the query to block or allow certain items into a branch, but the developers will need to refresh Team Explorer to update their query, otherwise it can allow unauthorized items in, or it can block items that are authorized. One solution I am looking into for this issue is to add a custom check-in policy that will always be satisfied but in the meantime will cause the VS IDE to refresh Team Explorer. I have asked MS to add this directly to their TFS Power Tools Work Item Query checkin policy but they have not responded.