【发布时间】：2014-02-20 22:48:48
【问题描述】：
在一个环境（SQL Server、TFS、SSDT、VS）中，每个解决方案大约有十几个 TFS SQL Server Data Tools 数据库项目（仅限数据库项目），同时有四到五个分支，您建议使用集成分支还是不是？那么为何不）？ 是否值得开销？ 如果没有，我们如何最好地执行分支之间的合并？
【问题讨论】：
标签： sql-server tfs sql-server-data-tools
【发布时间】：2014-02-20 22:48:48
【问题描述】：
分支与工作流程和发布策略之间的关系完全取决于您的团队工作流程。让我举两个不同的例子来说明你想要一个集成分支的地方，以及你可能不想要的地方。
示例 #1
您有 5 个功能分支，它们中的一些或全部将被集成在一起以创建下一个版本。在这种情况下，您显然需要一个集成分支。
示例 #2
您有 3 个分支，分别代表软件的 v1 - v3，它们都在同时开发中。在这种情况下，您可能不需要集成分支。所有 v1 代码都应该合并到 v2/v3 分支中，但不能反过来。
【讨论】：
-
感谢您的回答！我们有五个开发团队，每个团队将使用一个分支，它们在时间上重叠，并且都有不同的开始/结束日期。我们一次只发布一个分支。所有分支的所有代码最终都会合并到主干/基线中，有时会转发到其他分支。我想这与您的示例#2 最相似？我宁愿跳过集成分支，但是我们如何最好地在发布之前将特定更改从分支一合并到分支二？如果我们碰巧需要将分支 2 的签入应用到分支 1 怎么办？
-
我认为主干/基线是一个集成分支。
-
好的，但是你也有一个 main/production/live/.. 分支？
-
是的，你会有一个“主”分支以及你的集成分支，但如果这是你的方法，这听起来是最安全的事情。实际上，我们现在正在朝着这个方向发展，因为我们的分支机构在不同时间通过环境进行推广。
-
我不认为拥有匹配环境（例如生产）的分支是一个好习惯。您从一个分支进行构建，并且随着时间的推移，build 可能会部署到多个环境。分支应该遵循您的代码集成的工作流程，而不是您的部署工作流程/管道/环境。