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

我有一个非常成熟的软件工具包，但它通常需要很小的调整（主要是为了应付来自第三方产品的兼容性问题）。我现在希望生成一个“新”版本（改进的API），它将基于原始版本 - 这将与现有分支不同，随着时间的推移，但几年之后，我将需要保留原始的“现场”为了兼容性而需要它的现有客户。当然，我也需要确保“调整”也适用于“新”版本，因为这些问题（也会在大多数！）也适用于“新”版本。在Git中管理并行版本的最佳方式是什么？

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

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

我意识到需要偶尔进行手动干预，合并是冲突的，但根据过去人工更改的经验，我认为这很少见。现在，我正在放弃VSS（是的 - 继续嘲笑我保持这么久！），我希望Git能够让这个简单，但到目前为止，没有出现到任何“简单”的解决方案，我看到的建议都是围绕“rebase”构建的，这对我来说似乎是“错误的”，因为rebase似乎做了很多其他的事情，比如重写历史记录，当我需要的只是一个简单，真实的“前进”基于来自其他分支的变化。

我在这里错过了什么吗？
是否有一个更容易，正确定义的方式来做到这一点？
用不同的源码控制系统而不是Git会更好吗？

非常感谢所有的想法！

来源

2012-04-22 medconn

我认为你在这里错过了一些东西，因为'rebase'被设计为*完全*用于你的用例。它重写历史，因为它*应该*。如果你做得对，它只会在特定的本地分支中重写历史记录，因此中央仓库中的历史记录都不会被重写。 – 2012-04-22 09:22:12

你也可以直接合并，以使事情变得更简单，但rebase是一个更好的解决方案。 – 2012-04-22 09:23:12

相关：http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions – 2012-04-22 09:30:19

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

让我详细说明rebase：除非您唯一的开发人员在代码库上工作，否则我不会建议您为此特定问题使用rebase。记住rebase建议与专用分支机构一起使用，只有自您的重写历史记录，因此使作为祖先的任何提交失败的提交无效。

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

来源

2012-04-22 09:24:21

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

来源

2012-04-22 19:13:56 Novelocrat

虽然伟大的工作流git-flow不能解决这个特殊问题 – CharlesB 2012-04-22 22:20:32

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

回答

相关问题