问题标签 [baseless-merge]

我向 TFS 发出以下命令：

但是我有大量需要合并的变更集。是否有为此的快捷方式，或者以某种方式指定列表，例如：

我有以下分支结构：

我想将 Release 1.1 重新设置为 Main 所以它看起来像

我想这样做的原因是因为许多变更集需要从 Main 合并到 Release 1.1 而不是Release 1

我一直在尝试使用以下命令从 Main 到 Release 1.1 进行毫无根据的合并：

效果很好，一旦签入，我可以将 Release 1.1 重新设置为 Main。

但问题是，这个命令合并了 Main 中的所有内容，我只想创建一个合并关系。我不想合并从 Main 到 Release 1.1 的所有内容，因为同时发生了其他分支的许多其他更改。

有没有办法实现这一点，或者所有未来的变更集每次都需要毫无根据地合并？

我们在 TFS 2012 上的分支机构遇到了棘手的情况，现在我们不确定我们的行动会产生什么结果。

有问题的分支结构如下：

伪图大致是时间正确的 - 首先分支 B 从 A 分支，然后创建了后来的分支 C。数字是有问题的变更集（实际上我们的问题涉及每个分支上的多个变更集，但我已经简化了图表）。

我们想将变更集 3 从 C 合并到分支 B。Visual Studio 警告我们将执行无根据的合并（显然，因为分支 B 和 C 是兄弟而不是父子）。警告是这样的：

我们继续合并。然后在某个时候，一位开发人员发现我们忘记从分支 A 更新我们的分支 B，并且我们需要从分支 B 中的变更集 1 进行更改。但问题是变更集 1 有一些代码行，这些代码行后来在变更集中进行了修改我们合并的3个（分支C）。

现在的问题是，在我们完成变更集 3 从 C 到 B 的无基础合并之后，当我们将变更集 1 从 A 合并到 B 时，分支 B 会发生什么？

即使在我们进行了毫无根据的合并之后，当 TFS 发现变更集 1 的冲突代码行时，TFS 是否足够聪明以保留最新变更集 3 的更改？

PS我们会从这个错误中吸取教训，并会尽量避免将来毫无根据的合并......

也许是一个简单的问题，但我很难找到答案。我经常在使用 TFS 作为源代码控制的客户端工作，他们完全避免使用 TFS 源代码控制的无基础合并功能

部分原因是过去它需要命令行工具来执行此操作，但可能更重要的是，当您现在在界面中执行此操作时，它会向您显示一个黄色感叹号警告符号，表明您确实在执行毫无根据的合并。

这种吓唬他们，让他们完全避免它。我一直在四处寻找，以确定无根据的合并是否涉及任何特定风险，但我无法找到（或有关无根据的合并如何在幕后工作的详细信息）

I am doing a baseless merge between a branch B and C, since we do not want to go to trunk and down. B and C are latest with all trunk changes.

Before I did a baseless merge in Visual Studio 2013, I did compare of the two branches, It said 6220 files compared(150 different, 179 only in source and 213 only in target), so I was happy.

Even after i did the merge it came up with around 100+ conflicts to resolve, But what worried me was that the changeset had 6000+ files, so it is clear that if i check-in TFS would check-in files which have not been changed as well.

Is there an option so that the final merged changeset contains only the files that are different + only in source +only in target ?

Here is what I did to do the merge and avoid unchanged files in the changeset

1. Exclude all the newly added files that is only in source (fortunately I had this entire list)
2. Undo your pending changes. When you get the confirmation dialog choose "No to all". Visual Studio will take some time to process and will end up with the files that have only changed.
3. Then Include the newly added files that was excluded in Step 1

我正在为我目前所处的情况寻找正确的分支和合并策略。几周前，我从 Main 为应用程序的 1.6 版创建了一个新的 Dev 分支。这个版本现在正在测试中，将在未来几周内上线。

从今天开始，我需要开始 1.7 版的开发，但我不确定如何在 TFS 中进行。我认为有两种情况：

1. 1.7 的 dev 分支是从 Main 创建的（像往常一样），我将所有 1.6 的更改集成到 1.7 分支中并开始我的开发。一旦准备好进行测试，1.6 中的任何更改都将合并到 1.7 分支中。
2. 1.7 的 dev 分支是通过分支 1.6 dev 分支创建的，1.6 中的任何未来更改将再次按照第 1 点进行合并。

#1 的问题在于，根据 TFS，1.6 和 1.7 之间没有直接关系，这导致了毫无根据的合并。
#2 的问题在于 1.7 和 Main 之间没有直接关系，这导致稍后在 1.7 完成并与 Main 合并时进行毫无根据的合并。

这是无法避免毫无根据的合并的情况，还是我的整个策略都错了？