在Git中管理并行版本的最佳方法是什么？

Question

我有一个完善的软件工具包，但通常需要小的调整（主要是为了应对来自第三方产品的兼容性问题）。我现在希望生成一个“新”版本（改进的API），它将基于原始版本 - 随着时间的推移，它将与现有分支不同，但是几年后，我将需要保持原来的“实时”需要兼容性的现有客户。当然，我还需要确保“tweaks”也适用于“新”版本，因为这样的问题会出现（在大多数< / strong>个案！）也适用于“新”版本。

所以 - 我的理想（简单）工作流程将是：

1. 处理“新”版本时 - 更改仅适用于此 版本
2. 处理“旧”版本时，所有结果都会发生变化 将（尽可能自动！）应用于两个版本 一旦我对他们感到满意（当我承诺，提交或其他什么时）。

我意识到需要偶尔的人工干预，合并是相互矛盾的，但根据过去手动更改的经验，我希望这种情况很少见。

目前，我正在寻求放弃VSS（是的 - 继续嘲笑我保持这么久！），我希望Git会让这很容易，但到目前为止，似乎没有任何“简单”的解决方案，我看到的建议都是围绕“rebase”构建的，这对我来说似乎是“错误的”，因为rebase似乎做了很多其他的事情，比如重写历史，当我需要的只是一个简单的，真正的“前进”基于其他分支的变化。

• 我在这里遗漏了什么吗？
• 是否有更简单，更正确的方法来执行此操作？
• 使用不同的源代码控制系统而不是Git会更好吗？

所有的想法都非常感激！

Answer 1

您可以将旧分支的更改合并到新版本。

让我详细说明rebase： 除非您是唯一从事代码库工作的开发人员，否则我不建议您使用rebase来解决此特定问题。请记住，建议将rebase用于仅限私有分支，因为您的重写历史记录因此使任何具有重新提交作为祖先的提交无效。

如果您将旧版本分支更改为新版本，则每次需要将旧版本更改为newversion时，您将继续重写新版本分支的历史记录。这意味着，由于原始提交不再存在，所以使用新版本中的基础所做的任何工作（例如新版本独有的功能的功能分支）都将丢失。

Answer 2

查看Git flow - 使用工具支持分支这些功能的方法。基本上，对于每个新的'tweak'，你是在一个新的分支上进行的，它是在你正在维护的分支的共同祖先之前/之前，然后你将它们合并到每个分支。