问题标签 [feature-branch]

我有两个功能分支：featureA 和 featureB。

FeatureA 是完整的，但没有合并到主干，因为它未经测试，我们还没有准备好测试它。

我正在研究 featureB，并意识到我需要在 featureA 中实现更改才能继续。

最好的方法是什么？我想我有几个选择：

选项1

将 featureA 合并到 featureB 分支（或者如果我小心地获得所有我想要的，可能只是特定的修订），然后恢复我需要的所有更改。

选项 2

重新实现featureB中的变化（这次不会太复杂），整理一下featureA和featureB合并到同一个地方时的冲突。

无论哪种方式，这些功能都将被合并到一个发布候选分支中，以供测试和部署。一旦该 RC 分支被确认为已测试，它将一次性合并到主干中。

从 Subversion 功能分支提出需要从另一个功能分支进行更改

我有两个功能分支：“FeatureA”和“FeatureB”。FeatureA 已经完成，但没有合并到主干，因为它是否应该在下一个版本中得到确认尚未确定。

FeatureB正在进行中，结果表明需要对实际应用于 FeatureA 的 dbml 进行一些更改。

我有几个选项，其中之一是仅合并 dbml 和相关文件。我知道从工作副本根目录合并/更新/提交等是最佳实践，但如果我继续这样做会导致什么问题？

我有一个关于两个源代码控制场景的问题，都有功能分支和发布分支：

• 在场景 1 中，功能分支被合并到主干。
• 在场景 2 中，功能分支被合并到最新的发布分支。

与情景 1 相比，情景 2 的后果是什么？

这两种情况的可能优点和缺点是什么？

两个场景的更多细节：

• 所有开发都在功能分支中完成
• 分支总是从主干完成

场景 1（类似于此 SO-answer中描述的内容）：

• 功能分支总是合并到主干
• 当开始准备新版本时，从主干创建一个新的发布分支
• 在发布分支进行 QA 和部署之后，发布分支中的更改/错误修复将合并到主干和更新的发布分支
• 对主干的更改合并到所有功能分支

场景二：

• 功能分支总是合并到最新的发布分支
• 当当前发布分支不再接受新功能并开始准备最终发布时，从主干创建一个新发布分支
• 从发布分支进行 QA 和部署后，发布分支中的更改/错误修复合并到主干
• 对主干的更改将合并到所有功能分支和最新版本分支

有很多关于在 git 中“撤消”合并是多么不容易的话题。简短版本：如果您撤消合并提交，它还会告诉 git 将来永远不要合并这些更改。

在进行合并时我可以做些什么来减轻这个问题吗？在很多情况下，撤消合并真的非常有用，只是在软件开发的正常过程中，更重要的是，在需要回滚更改时控制发布分支的状态。

编辑

我在这篇文章中看到了解决方案，并没有真正将其视为解决方案，更多的是对问题的解释。这个需要

1. 总是使用 --no-ff
2. 当您想要恢复依赖于它们的代码时，请记住所有未完成的合并（这可能是未来的几个小时、几天、一周或几个月……）

我想要的是

这是它在 Subversion 中的工作方式。假设我有一个名为“release-candidate”的分支，它是我们在登台服务器上运行的，也是我们尝试功能的地方。假设我合并到功能 A 分支中。在 Subversion 中，它是一个变更集，所有文件的所有历史都被合并。假设我们不喜欢它，所以我们想把它拿出来。我们只需撤消那个单一的变更集，而不必考虑其他任何事情。我们可以在将来的任何时候将功能分支 A 合并回来，而不必记住我们曾经将它合并并取出。

我希望能够尽可能接近该流程。我想优化“将来不必记住东西”，即使它使事情在某种程度上采取了更多步骤。（这可能是不可能的......）

我们广泛使用功能分支作为开发策略。简而言之，允许我们做的是始终保持稳定的主干，而实现复杂功能的开发人员在可能损坏的分支上工作，直到该功能经过充分测试。此时分支被合并回主干，然后在主干上进行完整的集成/回归测试循环等。

我遇到的问题如下：在分支中实现上述功能的过程中，显然有很多对分支的提交。每个提交都有具有潜在教育和文档（？）价值的评论，有时可能非常有用。当您将分支大规模合并回主干时，所有这些注释都会丢失并替换为无用的“将 blah 合并到主干”类型的注释。

有没有人有任何解决方案可以帮助保留该元数据？在您看来，这甚至是一个问题吗？

PS我正在使用SVN。

我有很多 Git 分支。如何删除已经合并的分支？有没有一种简单的方法可以将它们全部删除而不是一个一个删除？

我正在使用中间 Git 存储库来镜像远程 SVN 存储库，人们可以从中克隆和工作。中间存储库的主分支每晚从上游 SVN 重新建立，我们正在开发功能分支。例如：

我可以成功地将我的功能分支推回远程，并得到我期望的结果：

然后我重新设置分支以跟踪远程：

一切都很好。我想从这里做的是将功能分支重新定位到远程的主分支，但我想从我的本地机器上执行此操作。我希望能够做到：

使远程功能分支与远程主控保持最新。但是，这种方法会导致 Git 抱怨：

git pull可以解决问题，但会导致我想避免的合并提交。我担心消息状态feature -> feature而不是feature -> origin/feature，但这可能只是一个演示文稿。

我是否遗漏了什么，或者以完全错误的方式解决这个问题？避免在远程服务器上执行 rebase 并不重要，但它使修复 rebase 中的任何合并冲突变得更加困难。

我们将Vincent Driessen的一个成功的 Git 分支模型用于我们的分支模型。一切都很好，但我还没有真正看到提出的特定问题。

据我了解，当需要新功能时，您将分支development并创建一个新feature分支。你会处理这个，当你完成后，你会将此分支合并到development分支中。

如果开发人员制作了一个功能，然后将该功能合并回来，却development发现功能代码中存在一些错误，该怎么办。这应该在哪里解决？是否应该从开发开始一个新的fix/分支并在那里修复代码？bugfix我看不到另一种方式。

应该怎么做呢？

谢谢

不久前，我克隆了一个 Hg 存储库，并且一直在进行重要的本地提交（主要版本更改）。

与此同时，躯干略微前进；几个提交，但微不足道的变化。

管理将此分支合并回主干的最简单方法是什么？

考虑到我的“分支”发生了重大变化，最好将最新的主干与我“分支”的主干版本进行“比较”，然后对我的 v2 重新进行相同的功能更改？- 如果是这样，我如何知道这个版本是什么？

谢谢