9

我有一个完善的软件工具包，但通常需要进行一些小调整（主要是为了应对来自 3rd 方产品的兼容性问题）。我现在希望制作一个“新”版本（改进的 API），它将基于原始版本 - 随着时间的推移，这将与现有分支有所不同，但几年后，我需要保持原始的“实时”版本需要它以实现兼容性的现有客户。当然，我还需要确保“调整”也适用于“新”版本，因为这些问题（在大多数情况下！）也适用于“新”版本。

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

  1. 在处理“新”版本时 - 更改仅适用于该版本。
  2. 在处理“旧”版本时，一旦我对它们感到满意（当我提交、提交或其他方式时），所有产生的更改都会（尽可能自动地！）应用于两个版本。

我意识到偶尔需要手动干预，合并发生冲突，但根据过去手动更改的经验，我预计这种情况很少见。

目前，我希望放弃 VSS（是的 - 继续嘲笑我保留这么久！），我希望 Git 能让这变得简单，但到目前为止，似乎没有任何“简单“解决方案，我所看到的所有建议都是围绕“rebase”构建的，这对我来说似乎是“错误的”，因为 rebase 似乎做了许多其他事情，比如重写历史，而我所需要的只是一个简单、真实的“前进”基于来自另一个分支的更改。

  • 我在这里错过了什么吗？
  • 有没有更简单、正确定义的方法来做到这一点？
  • 使用不同的源代码控制系统而不是 Git 会更好吗？

非常感谢所有想法！

4

2 回答 2

5

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

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

如果您将旧版本分支更改重新定位到新版本，那么每次您需要将更改从旧版本带到新版本时，您将不断重写新版本分支的历史记录。这意味着在新版本中使用基础完成的任何工作，例如新版本独有的功能的功能分支将丢失，因为原始提交不再存在。

于 2012-04-22T09:24:21.830 回答
0

看看Git flow - 一种使用支持​​它的工具来分支这些功能的方法。基本上，对于每一个新的“调整”，你都在一个新的分支上执行它，该分支植根于你正在维护的分支的共同祖先/之前，然后你将它合并到每个分支。

于 2012-04-22T19:13:56.463 回答