Question

是否有一种有效的方法可以使用git来管理基于相同代码逻辑但支持不同API的两个分支？这是一个具体的例子：假设我有一个名为abc.py的Python 2文件的repo。在分支A上的提交py2中，文件内容为：

print 'A'

现在，我使用新的A分支从py3分支，并使用此内容进行提交A3：

print('A')

返回py2分支，有人使用内容

进行新的提交B

print 'A'
print 'B'

在py3上，我合并py2以获取B更新并获得此合并冲突：

<<<<<<< HEAD
print('A')
=======
print 'A'
print 'B'
>>>>>>> 9d898

因此重新提出了print 'A'的冲突。我解决了这个问题

print('A')
print('B')

现在在py2中有提交C和

print 'A'
print 'B'
print 'C'

并将其合并到py3会产生冲突

<<<<<<< HEAD
print('A')
print('B')
=======
print 'A'
print 'B'
print 'C'
>>>>>>> 2c5a5

因此，所有更改都会再次引发合并冲突。

似乎这种经常从py2合并到py3的方法，每个合并将比前一个合并更复杂和痛苦。有没有办法使用git维护这样的两个分支，以前的合并历史可以更好地合并？如果没有，我想我最好不要做那么多的大＆＃34;赶上＆＃34;尽可能合并，而不是频繁进行小合并，这通常是最好的方法。

背景：我正在尝试将项目从Python 2移植到Python 3.如果我能够立即执行此操作，我会这样做并放弃Python 2支持，但我无法立即执行此操作所以我必须允许在Python 2分支上进行开发，而Python 3端口在另一个分支中完成。我知道许多大型项目通过一个代码库同时支持2和3的阶段进行了转换。由于我不需要在Python 3工作后支持Python 2，我认为如果我只做一个单向端口，移植过程会更简单，但是从Python 2移植更新的过程似乎比我想象的更难起初。

免责声明：我知道我的例子很简单，可以通过使用Python 2中__future__的打印功能来解决这个问题，但对于所有事情都没有这么简单的解决方法。此外，我认为这个问题更广泛地适用于其他情况，而不仅仅是Python 2/3。

Answer 1

尽管听到的消息令人失望，但我认为分支机构可能不是该工作的正确工具。这些分支通常被称为“长期分支”，通常在实践中从来没有像理论上最初看起来那样有用。

我建议一个更好的工具是文本预处理器，例如gpp，m4或（如果是c / c ++项目）cpp。

使用不同版本的API维护git分支的策略？

1 个答案: