合并具有项目 ID 冲突的解决方案文件的最佳实践答案

【问题标题】：Best practice for merging solution files with project id conflicts合并具有项目 ID 冲突的解决方案文件的最佳实践
【发布时间】：2016-02-07 03:01:10
【问题描述】：

假设一个 TFS 分支是从具有 2 个项目 (FirstNewProject) 的某个主分支中创建的，但是当该分支中的工作仍在进行时，创建了另一个分支 (SecondNewProject)，该任务已完成并合并了另一个分支退下来。

如果我们现在尝试将第一个分支合并回主分支，这两个分支都是从其分支的，我们现在在解决方案文件中存在冲突，显然只能手动解决...

第一个冲突是 SccNumberOfProjects = 3 TFS 变量，它在 FirstNewProject 和 SecondNewProject 解决方案文件中是相同的，但需要更改为 SccNumberOfProjects = 4，因为当 SecondNewProject 合并回来时，项目的数量是 3，但现在我们'正在合并 FirstNewProject 项目数量现在是 4 个。

手动将此变量更改为 4 会创建无效的解决方案文件吗？

第二个冲突在 Global 部分，它与项目编号有关。

SecondNewProject 将这些行添加到解决方案文件中：

SccProjectUniqueName3 = SecondNewProject\\SecondNewProject.csproj
SccProjectName3 = SecondNewProject
SccLocalPath3 = SecondNewProject

FirstNewProject 将这些行添加到解决方案文件中：

SccProjectUniqueName3 = FirstNewProject\\FirstNewProject.csproj
SccProjectName3 = FirstNewProject 
SccLocalPath3 = FirstNewProject

但 FirstNewProject 现在是第 4 个项目，所以我们应该将这些条目更改为

SccProjectUniqueName4 = FirstNewProject\\FirstNewProject.csproj
SccProjectName4 = FirstNewProject 
SccLocalPath4 = FirstNewProject

手动，这会使解决方案文件无效吗？在这种情况下合并回来时还有其他事情要做吗？

【问题讨论】：

标签： visual-studio tfs

【解决方案1】：

合并 sln 是很糟糕的经历。但是我看到了这个问题的另一种解决方案 - 为什么不保留本地版本，然后手动添加新项目（来自 Visual Studio）。我知道这是手动的，但它更不容易出错

【讨论】：

是的，合并解决方案是一场真正的噩梦，因为该文件是迷你数据库，其中包含通过 GUI 引用的相互关联的项目。所以我遵循你解释的过程，即使它是手动的：在合并中选择一个分支的解决方案并手动添加另一个分支的项目。

【解决方案2】：

假设你的分支结构是这样的：

 FirstNewProject
/ 
Main branch
\
 SecondNewProject

现在您已经在 FirstNewProject 和 SecondNewProject 中进行了编辑，并且希望将 FirstNewProject 合并到 Main 分支以及 SecondNewProject。 SecondNewProject 中的SccNumberOfProjects 是 3，而 FirstNewProject 中的 SccNumberOfProjects 是 4，所以你混淆了 Main 分支中的 SccNumberOfProjects 应该是 3 还是 4，对吗？

我不确定您为什么要求更改 SccNumberOfProjects 会使解决方案文件无效。由于您在 Main 分支和其他分支之间执行合并，因此源分支和目标分支应该相同。

就分支和合并策略而言，基本的分支计划应如下图所示：

主分支是开发分支和发布分支之间的连接分支。该分支应该代表产品的稳定快照，可以与 QA 或外部团队共享。发布分支是为了隔离代码为发布做准备。并且所有更改都应该发生在开发分支上。当代码在 Development 分支中运行良好时，将其合并到 Main 分支。当你想发布解决方案时，从 Main 分支合并到 Release 分支。

对于您的场景，您需要检查您想要哪个分支，并修改分支以解决冲突。然后你就可以按照分支策略来管理你的分支了。

【讨论】：