问题标签 [branching-and-merging]

我对 SVN 中的分支和合并有基本的了解。你分支，做任何事情，合并回主干。

你必须合并回主干吗？

我的场景：

我在 ASP.NET MVC2 中有一个小应用程序，使用 Linq to SQL。随着 MVC3 的推出，我要么将其升级到 MVC3，要么从头开始重做（使用 EF 4）。无论哪种情况，下一个“版本”都将与我现在拥有的非常不同。

我想知道我应该如何处理 SVN 部分。我应该把它作为当前存储库 (/svn/project/trunk/mvc3) 的一个分支放在 SVN 中，还是应该启动一个新的存储库 (/svn/project_mvc3/trunk)。

我的问题很简单，我在我们的项目中做了很多更改，我不想立即与主分支合并。在进行这些更改时，我没有在开始时使用分支。所以现在我试图找到一种方法来使用分支来检查我的代码，但似乎没有解决方案。我该怎么做，最好的方法是什么。我正在使用连接到 TFS 2008 的 Visual Studio 2010。

非常感谢。

在它出现之前，我已经查看了关于这个主题的几个线程，包括这些：

• 合并：Hg/Git 与 SVN

• Mercurial 与 SVN 中的私人分支机构相比

• 为什么在 Mercurial 中分支和合并比在 Subversion 中更容易？

我正在考虑为我们的开发组切换到 Mercurial（来自 Subversion）。在我这样做之前，我正在做通常的优点/缺点列表。

我的“优点”之一是合并在 Mercurial 中更胜一筹，但到目前为止，我还没有找到令人信服的证据。也就是说，在 HgInit.com 上发表了我无法验证的声明：

例如，如果我稍微改变一个函数，然后将它移动到其他地方，Subversion 并不会真正记住这些步骤，所以当需要合并时，它可能会认为一个新函数突然出现. 而 Mercurial 会分别记住这些内容：函数更改，函数移动，这意味着如果您也稍微更改了该函数，Mercurial 更有可能成功合并我们的更改。

这将是非常引人注目的功能，但据我所知，这只是热空气。我一直无法验证上述说法。

我创建了一个 Mercurial 存储库，做了一个 Hello World，然后克隆了它。在其中，我修改了函数，提交它，然后移动它，然后提交它。在另一个中，我只是在函数中添加了另一个输出行并提交。

当我合并时，我得到的合并冲突与使用 Subversion 时基本相同。

我知道 mercurial 可以更好地跟踪文件重命名，并且 DVCS 除了合并之外还有其他优势，但我对这个例子很感兴趣。乔尔·斯波尔斯基（Joel Spolsky）是不是在这里偏离基地，还是我错过了什么？

我在这方面没有经验，但似乎因为 Mercurial 保留了更多信息，理论上它可以在合并方面做得更好（如果开发人员也经常签入）。例如，我认为 Mercurial 通过比较多个更改来获取上下文更改是可行的，例如，我修改函数、签入、移动函数、签入，然后 Mercurial 将这两个部分关联起来。

然而，Mercurial 的合并似乎并没有真正利用添加的信息，并且似乎与 Subversion 的操作方式相同。它是否正确？

我有一个发布分支（RB，从 C5 开始）和一个主干（C10）上的变更集，我现在想合并到 RB。

该文件在 C3 处有更改（两者共有），在 RB 上的 CS 7 中有一处，在 C9（主干）处有一处，在 C10 处有一处）。所以我更改文件的历史记录如下所示：

当我将 C10 从主干合并到 RB 时，我希望看到一个合并窗口显示我 C10 | C3 | C7，因为 C3 是共同的祖先修订版，而 C10 和 C7 分别是我的两个分支的提示。但是，我的合并工具向我显示了C10 | C9 | C7.

我的合并工具配置为 show %1(OriginalFile)|%3(BaseFile)|%2(Modified File)，所以这告诉我 TFS 选择 C9 作为基本修订版。

这完全出乎意料，与我习惯于在 Mercurial 或 Git 中工作的合并方式完全相反。我做错了什么还是 TFS 试图通过合并让我发疯？

这是默认的 TFS 合并行为吗？如果是这样，您能否深入了解他们为什么选择以这种方式实施它？

我正在使用带有 VS2010 的 TFS 2008 作为客户端。

这是我们的情况：我们的 Mercurial 存储库中有两个分支，我们将它们称为分支 A 和分支 B。

• 分支 A 用于代码的稳定版本
• B 分支用于开发分支

在分支 A 中修改的所有内容都已合并到分支 B。但是现在我们发现分支 B 中的代码与分支 A 有几个不同之处。我们在分支 A 中进行了一些大的代码更改，将这些更改合并到分支 B这将是一个真正的痛苦，实际上我们想对解决方案进行替代实施。但是稍后我们还希望继续对分支 A 进行更改，并且仍然能够将这些后来的小更改合并到分支 B。所以问题是：当合并到分支 B 并合并时，是否可以从分支 A 跳过一些单个变更集后来又从 A 到 B 的变更集？（可能使用纯 Hg 解决方案且没有变通方法，使用备份副本等...）

这里概述了我们将达到的目标：

提前感谢您的任何建议

我有一个简单的分支计划，有一个主分支和一个开发分支。在开发分支中，我在源代码旁边有一些与开发过程相关的文档，在将最新版本的开发合并到主分支时，这些文档不应合并到主分支。是否可以将源代码管理中的特定文件或文件夹标记为“忽略”以进行合并？

谢谢你的帮助。

最近我开始为我的项目实施新的实验功能。不幸的是，我在开始之前忘记了分支，并将几个提交推送到共享存储库服务器到主分支。由于其他人可能已经检查了我的提交，我想避免覆盖服务器上的历史记录。

由于我的更改，master 目前不稳定，这也不好。因此，我想恢复对 master 所做的更改，创建一个单独的分支来包含这些更改，并且一旦它们足够稳定，仍然能够将它们重新引入（合并）回 master。

我想在我的主人之上应用一个小的主题分支（在贡献者的远程仓库上）。我认为这样做的规范方法是：

但我想让提交一个接一个地应用，而不是生成一个合并提交。

天真的运行git rebase contributor/topic-branch显然是行不通的，因为它将我的主应用到主题分支上，就好像主题分支是我的上游一样。所以我尝试了这个：

这就是我想要的，除了现在我有一个分离的 HEAD，我需要修复 master 分支以指向 HEAD（使用branch -f）。我当然可以编写一个 Bash 函数来自动执行此操作，但是是否有一种“正确”的方法可以在不使用的情况下拉入主题分支merge？

这本书说不应该使用重新集成的分支，因为它不能接受提交，实际上建议删除它。

如果我不记得了，如何测试分支是否已经重新集成？

我试图弄清楚如何将分支从单独的回购合并到当前。

我有以下内容：

PJT1 - 包含分支 default 和 foodog

PJT2 - 包含分支默认值

从 PJT2，我执行以下操作：

现在，如果我查看 PJT2，我会看到正确的文件和更改。但是，如果我这样做hg branches，我会得到以下信息：

并hg branch揭示以下内容：

如何从 PJT1 的foodog分支中获取内容到 PJT2 的default分支中？