问题标签 [branching-and-merging]

我正在考虑从 HG 切换到 Plastic SCM（http://www.plasticscm.com，主要是因为它似乎提供了更好的 VS 集成），并且他们提倡“任务驱动分支”，即从主线分支每个特征。这是有道理的，但是，我有几个问题：

1. 他们建议不要在完成后将您的任务合并回主线。这似乎很不直观，我原以为在测试后会立即合并回tip，这样您以后就不必重新设置基准。更不用说，如果任务没有合并回来，并且说新版本即将发布，则需要合并可能数百个不同的分支，并确保它们在短时间内相互配合（测试独立并不意味着他们会与他人相处融洽，恕我直言）。所以，这似乎注定要失败，我错了吗？你练习这个方法吗？
2. 假设我对上面的错误，给定以下场景：任务A，B，C。其中B，C依赖于A的完成，最好完成A，将其合并回主线，然后从那里分支到 B/C 上工作，或者，子分支您的初始分支（您为 A 创建的分支）。这甚至可能吗？受到推崇的？如果同一个人正在实施 A、B、C，我的脑海中似乎稍微清晰一些。如果不是，显然，合并回主线是最有意义的。

让我知道你们的想法！

谢谢。

我有一个存储库，我一直在master分支上工作，最后添加了大约 10 个左右的提交，我现在希望这些提交在另一个分支上，因为它们描述了我现在认为是实验性的工作（我仍在学习良好的 Git 实践）。

考虑到这一点，我现在想让这最后 10 个提交形成他们自己的分支，可以这么说，这样我就可以master只为“发布”/“稳定”提交保留干净和保留。

为了说明，我所拥有的是：

您可以看到标记为X和的提交Z都在master分支上，而我想要的是标记为Z（现在被认为是实验性“功能 Z”工作）的提交位于它们自己的分支上并master以最右边的X. 为了说明，所需的图表：

这样，我将master保留用于发布和其他稳定提交，能够根据需要合并 A、B 和 Z 功能。

那么如何将“Z”提交移动到他们自己的分支上呢？

我在我的项目中使用 Git 并尝试遵循最佳实践：

1. 我在一个主题分支上工作
2. 准备好后，我将主题分支合并到我的开发分支中，使用git merge --squash. 这使我的开发分支保持清洁。
3. 每当dev分支稳定并且团队决定是时候发布时，我们将dev分支合并到master分支，而不使用 squash，并将该提交标记为版本发布。

这应该保留我们的历史记录，并且使用 gitk，我们可以看到所有提交的来源。但是，我希望能够只看到应用于主分支的提交。我试过了：

这些都没有显示主分支的历史。有没有办法轻松做到这一点？

我在 SCM 工作，使用各种工具（Subversion、Clearcase、TFS、Perforce）和技术（主要是.NET、Java）。在我开始工作之前，正常的业务顺序是创建一个受控分支。

我将受控分支定义为： - 一个单独的分支，其中包含开发人员无法访问的提升代码。只有一个构建工程师团队可以访问它。

受控构建： - 构建引擎从受控分支获取代码并生成开发人员无法修改的工件。

因此，作为受控构建过程的一部分，合并到这个分支已成为重要的一步。这可能会产生速度和错误的问题（这将主要通过自动化来缓解）。

好处：自动代码锁定（因为开发人员不能修改分支）分支名称可以不同（其他团队不一定遵循标准化的做法，我们不一定能够施加所需的压力。）查找确切版本代码的简单方法状态（即版本的受控分支中的最新代码是去生产的）

缺点：在与开发人员讨论问题时，速度将开发构建与受控构建相匹配（这是自动化的，但有点混乱）。错误（过程中另一个混乱的地方） 安全/角色分离功能是否可以通过使用变更列表/变更集/不可变标签来完全处理？

问题：

我应该建议从当前的受控分支策略转移吗？我错过了其他好处吗？

我有一个应用程序（cms），其结构如下：

这是我们所有项目的基础中央存储库。然后项目获得自己的皮肤：（基于/default/主题）

（这个应用程序有 12 个基于默认主题的自定义主题）。

整个事情是关于维护应用程序并使所有克隆与 BASE 保持同步。

现在，我们将 BASE 添加为远程仓库：

然后在需要时拉取更新：

修改中的.php文件后，/application一切正常。当我们default在 BASE repo 中修改主题中的文件时，问题就开始了（例如，拼写错误reset.css）。CLONE1/default我们需要主题和所有主题的这些变化CLONEx/own-x/。

当然，需要一些 bash 脚本来告诉在哪里复制和提交更改，但是如何在不发生合并冲突的情况下使整个事情保持同步呢？

我们使用git flow. 和主题现在不在单独的分支中default。mobile我们需要他们吗？我们还没有使用子模块。

组织此工作流程的方法有很多种，但您会选择哪一种作为最佳方法？

我听说在 Mercurial 存储库中创建分支的唯一方法是在工作副本中进行更改，然后将它们提交到新分支。

在 Subversion 中，我可以创建一个分支而无需进行更改（通过复制trunk到 下的路径tags） - 是否也可以在 Mercurial 中执行此操作？

我目前只见过 TortoiseHg，所以这可能只能通过命令行工具完成，我不知道。

我的工作流程是：

• 创建功能分支。
• 在该功能分支中做一些工作。
• 创建一个发布候选分支。
• 合并功能以发布候选分支。
• 部署、测试、修复部署、测试、修复候选发布分支。
• 将发布候选分支合并到主干。

提前谢谢了。

我正在使用 Subversion 1.3 或 1.4。我还不能将我的服务器升级到 1.5。我已经创建了一个分支，进行了更改，现在需要将它合并回主干，因为我已经完成了我的分支工作。

自从我分支以来（约一个月），许多变化都发生在主干上。我已经使用 SVN 的“合并修订”功能将它们合并到我的分支中。这意味着该分支包含最新的主干代码以及我的更改。

我不能使用 Tortoise SVN“重新集成分支”功能，因为我没有 1.5。我尝试将分支的修订范围合并到主干中，但我遇到了很多冲突（和树冲突）。我不知道为什么，因为我的分支已经合并了来自主干的所有更改（重新设置）。

我做了一些重组（移动文件，创建/删除目录）。我觉得我错过了什么；如果我的分支有最新的主干代码加上分支更改，为什么合并回主干充满冲突？

如何快速/轻松地将更新的分支合并回主干？

我有一个我一直在使用的存储库，它有大约 805 个网站的修订版本。

从项目一开始就设想，一旦我们通过开发使其成为一条捷径，我们将分成多个分支，一个用于基本框架，最初一个用于基于该框架的第一个网站。最终会有更多基于该框架的网站。

我刚刚根据 HEAD 修订创建了两个分支，一个称为“框架”，一个称为“站点”。

我有两个工作副本，一个在 ubuntu 开发服务器上。这是我做大部分开发工作的地方，但我在 Windows 机器上还有另一个工作副本。这用于事物的设计方面。

到目前为止，这工作得很好，两个工作副本都可以愉快地提交到主干。

我遇到的最大问题是现在我有了分支，windows机器可以访问分支，但是ubuntu机器给出了错误：

我正在使用 TortoiseSVN 的一台 windows 机器，而 ubuntu 机器是 subversion 命令行。

存储库位于：

后备箱位于：

和分支机构：

我用来将我的 ubuntu 机器工作副本切换到另一个分支（比如框架分支）的命令是：

正如我上面提到的返回：

谁能解释为什么 Windows 机器可以访问分支，但 Ubuntu 客户端不能？

我已经从共享存储库中签出代码，并对其进行了一些工作。在此过程中，我一直在将共享存储库中的更改合并到我的代码中。

我想将我的本地存储库推送到共享存储库上的新分支，以便其他人可以访问它们，同时不会损坏共享存储库。

我将如何使用 Git 执行此操作？

我正在尝试采用更改的分支并将其恢复为与它分歧的上游相同。这些更改都是本地的并且已被推送到 github，因此既不可行，git reset也不git rebase真正可行，因为它们更改了历史记录，这对于已经推送的分支来说是一件坏事。

我也尝试git merge过各种策略，但它们都没有撤消本地更改，即如果我添加了一个文件，合并可能会使其他文件重新排列，但我仍然会拥有上游没有的那个文件有。

我可以从上游创建一个新分支，但我真的很想要一个合并，在修订历史方面应用所有更改以获取我的分支并再次使其与上游相同，以便我可以安全地推送该更改没有破坏历史。是否有这样的命令或一系列命令？