问题标签 [branch]

假设我团队中的某个开发人员搁置了他在分支 A 中所做的更改。而我正在处理分支 B。我可以将他的更改搁置到分支 B 中吗？（通过 GUI 或命令提示符）

分支的颠覆概念似乎集中在为整个存储库创建一个 [un] 稳定的分支以进行开发。是否有创建单个文件分支的机制？

对于用例，请考虑一个具有多个特定于平台的源 (*.c) 实现的通用头 (*.h) 文件。这种类型的分支是永久性的。所有这些分支都会看到持续的发展，偶尔会出现跨分支合并。这与通常具有有限生命周期的不稳定开发/稳定发布分支形成鲜明对比。

我不想分支整个存储库（便宜与否），因为它会产生不合理的维护量以在主干和所有分支之间不断合并。目前我正在使用 ClearCase，它有一个不同的分支概念，这使得这很容易。我被要求考虑过渡到 SVN，但这种范式差异很重要。我更关心的是能够轻松地为单个文件创建替代版本，而不是像切割稳定的发布分支这样的事情。

我一直在重构我和其他人的代码。当我在一个分支而不是 Trunk 工作时，这有时会导致一些极其痛苦的合并，尤其是如果我不定期合并回 Trunk（分支的代码会慢慢从 Trunc 移开，当人们修改 Trunk 我必须手动弄清楚如何将其应用于分支）。

我知道的解决方案是

1. 不断地合并到 Trunk 和从 Trunk 合并 - 减少痛苦的合并，但是为什么要在分支中工作呢？
2. 每当您需要重构某些东西时，切换到 Trunk，在那里进行重构并合并到您的分支 - 我觉得这不是很实用，因为每次重构切换环境的实际成本是巨大的。

你做什么工作？

我需要定制一个开源项目。这些更改是针对特定组织的，对公共项目没有用处。代码更改包括禁用组织不需要的功能（影响 5% 的代码）、为组织定制其他功能（影响 20% 的代码）以及添加新的自定义功能（添加大约 10% 的新代码）。

我可以从当前版本开始并从那里进行自定义。但是，原始项目继续取得进展并引入新功能，我希望能够在这些改进出现时将其纳入。

管理此问题的最佳方法是什么？现在，我只能在发布版本可用时获得它们，但我应该很快就可以只读访问原始项目的 Subversion 存储库。我是使用 Subversion 存储库的新手，但也可以将它们用于我的代码。

我有义务在这个特定项目中使用 CVS，所以即使我真的想切换到其他东西，比如 Git，我也不能。

所以，我真正的问题是这样的：我们有一个约定，每次发布时我们都会在 CVS 中创建一个新分支（我们也标记，但这不是重点）。我们称这些版本分支，它们使我们能够轻松地检查特定版本并对其进行热修复更改 - 这就是我们的次要版本。

但是现在我有一些大的、充满风险的变化即将到来，如果我在 Git 中工作，我会在眨眼之间创建一个功能分支。然而，在 CVS 中工作时，我尝试在另一个项目中创建功能分支，但很快发现事情变得一团糟。我最终得到了很多分支，但我忘记了哪些分支已同步，哪些需要合并，哪些不再使用。

那么，接近问号，在 CVS 中使用特征分支是否可行？它们是不是太麻烦而不值得，还是我最终会因为不使用它们而感到抱歉？我是否应该硬着头皮开始在 HEAD 中编码，但要弯曲我的编码过程，以尽可能不引人注意的方式引入更改？

我有一些我已经决定的提交，事后，将是更多的分支工作而不是主干工作。如何创建分支并恢复主干，同时仍确保以后合并不痛苦？

是否像将当前主干复制到分支并还原主干一样简单？或者这会在以后引起头痛吗？

这篇文章（How do you manage database revisions on a medium-sized project with branches?）让我想知道如何最好地使用分支和部署到开发、登台和生产（以及本地副本）来处理 Web 项目。

我们本身没有“发布”：如果一个功能大到足以引起注意，我们将其推送（在必要的测试/等之后），否则我们批量处理一些，当感觉“舒适”时，推送那些活着。目标是每月部署一次或两次以上，因为不断变化的站点往往会让用户有点不安。

以下是我们的做法，感觉有点脆弱（目前使用 svn，但考虑切换到 git）：

1. 两个“分支”——DEV 和 STAGE，给定的 STAGE 版本标记为 TRUNK
   • 开发人员检查每个更改的 TRUNK 副本并为其创建一个分支
   • 开发人员在本地工作，经常签入代码（就像投票一样：尽早且经常）
   • 当开发人员感到满意时，它并没有完全损坏，将分支与 DEV 合并并部署到开发站点。
   • 根据需要重复 3-4，直到更改“完成”
   • 将变更分支与 STAGING 合并，部署到暂存站点。进行预期的最终测试。
   • 一段时间后，将给定的 STAGE 版本标记为 TRUNK，并实时推送主干
   • 合并 TRUNK 更改回 DEV 以保持同步

现在，其中一些步骤非常复杂，而且在实践中很难做到（TRUNK -> DEV 总是中断），所以我不得不想象有更好的方法。

想法？

我有一个具有标准布局的颠覆存储库，即主干/和分支/（和标签/）。当进行更大的更改时，会使用功能分支，定期与主干同步，然后重新集成回主干（现在使用 1.5）。很标准的东西。

我想知道的是，这样的功能分支，一旦完成并合并，是否应该保留或删除。颠覆书偶尔似乎暗示删除它们是很常见的，但我也看到了一堆保留分支的开源项目。

我也有点担心删除一个分支将如何使跟踪存在的分支变得更加困难，尤其是当潜在的重复名称进入场景时（比如我们搜索重构两次），它们的提交历史消失在存储库深处的某个地方等等

另一方面，分支被大量使用，尤其是现在的 1.5，我确实喜欢不必通过大量非活动分支来查找我目前正在处理的分支的想法。

我想念的优点和缺点是什么？人们在做什么？

另请参阅：
如何查看哪些 Git 分支正在跟踪哪个远程/上游分支？

如何找出本地分支正在跟踪的远程分支？

我是否需要解析git config输出，或者是否有可以为我执行此操作的命令？

我们的 svn 存储库有很多分支，它们是子树的分支。这适用于 svn，因为我可以在我的工作副本的正确位置检查该子树。但是，如果我使用 git 检查同一个分支，我会得到一个只有分支子树的工作副本。是否可以让 git 重新定位分支，以便我的工作副本结构是相同的，无论我是在主干还是分支上？

我意识到我们的 svn 实践与 git 始终在整个树上工作的哲学相冲突。人们如何处理这个问题？