我有一个完善的软件工具包，但通常需要小的调整（主要是为了应对第三方产品的兼容性问题）。 我现在希望生成一个基于原始版本的"新"版本（改进的 API） - 随着时间的推移，这将与现有分支不同，但在几年内，我需要为需要它的现有客户保持原始"活动"兼容性。 当然，我还需要确保"调整"也适用于"新"版本，因为此类问题（在大多数情况下！）也适用于"新"版本。
所以 - 我理想的（简单）工作流程是：
- 在处理"新"版本时 - 更改仅适用于版本。
- 在处理"旧"版本时，所有生成的更改将（尽可能自动！）应用于两个版本一旦我对他们感到满意（当我提交、提交或其他什么时）。
我意识到偶尔需要手动干预，合并是冲突的，但根据过去手动更改的经验，我希望这种情况很少见。
目前，我正在寻求放弃 VSS（是的 - 继续嘲笑我保持这么久！），我希望 Git 能让这变得简单，但到目前为止，似乎没有任何"简单"的解决方案，我看到的建议都是围绕"rebase"构建的，这对我来说似乎是"错误的"，因为 rebase 似乎做了许多其他事情，例如重写历史， 当我所需要的只是基于另一个分支的变化的简单、真正的"前进"。
- 我在这里错过了什么吗？
- 有没有更简单、正确定义的方法可以做到这一点？
- 使用不同的源代码管理系统而不是 Git 会更好吗？
所有的想法非常感谢！
您可以将旧分支中的更改合并到新版本。
让我详细说明一下变基：除非您是唯一在代码库上工作的开发人员，否则我不建议您对这个特定问题使用 rebase。请记住，建议仅将 rebase 用于私有分支，因为您的重写历史记录会使任何将重定基提交作为祖先的提交无效。
如果您将旧版本分支更改重新设置为新版本，那么每次您需要将更改从旧版本引入新版本时，您都会不断重写新版本分支的历史记录。这意味着在新版本中使用 base 完成的任何工作，例如新版本独有的功能的功能分支都将丢失，因为原始提交不再存在。
看看 Git flow - 一种使用工具支持这些功能进行分支的方法。基本上，对于每个新的"调整"，你都会在你维护的分支的共同祖先上/之前根植于一个新分支上，然后将其合并到每个分支中。