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

Question

假设一个TFS分支是从一个主分支创建的,它有两个项目(FirstNewProject),但是当该分支中的工作仍在进行时,另一个分支被创建(SecondNewProject)任务完成,另一个分支被合并回来.

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

第一个冲突是SccNumberOfProjects = 3TFS变量,它在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 以及 SecondNewProject 合并到 Main 分支。SecondNewProject 中的SccNumberOfProjects是 3，而 FirstNewProject 中的 SccNumberOfProjects 是 4，所以你很困惑SccNumberOfProjectsMain 分支应该是 3 还是 4，对吗？

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

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

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

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