将解决方案文件与项目ID冲突合并的最佳实践

Question

让我们说一个TFS分支是从一个主分支创建的，它有两个项目（FirstNewProject）但是当工作仍在该分支中时，另一个分支被创建（SecondNewProject）任务完成了其他分支合并回来了。

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

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

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

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

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 

手动并且会使解决方案文件无效，在这样的情况下合并回来时还有什么要做的吗？

Answer 1

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

Answer 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分支。

对于您的方案，您需要检查所需的分支，并修改分支以解决冲突。然后，您可以按照分支策略来管理您的分支机构。