使用 git 同时维护不同版本的代码
我有一个需要优化的代码。我想同时维护一组版本的代码（每个版本可以描述为一些功能、优化的组合）。最终，我将决定哪个版本是最好的。我不想将这些版本合并为更少的版本。但是，我希望能够对（大）源文件进行（小）修改，这可能会跨版本转移，并且我希望这一修改能够写入多个（可能是所有）版本。我怎样才能用 git 实现这一点？
例如，让我们考虑 3 个版本：v1、v2、v3 和源代码文件 source.cpp，其中包含许多代码在所有版本中都不同，但 A 类方法 aMethod() 是相同的。我想更新该方法并仅将更新写入版本 v1 和 v2。
我怎样才能做到这一点？
如果我修改source.cpp，例如，在v1中，而不是将其合并到v2，则会出现合并冲突（因为 v1、v2 中的 source.cpp 有所不同）。有什么办法可以避免冲突吗？如果不是，在这种情况下处理合并冲突的最佳方法是什么？ 顺便说一句，我不想增加代码粒度，以便将aMethod()放在专用文件中，因为已经编写了很多源代码，开销太大为我描述的任何此类修改执行此操作。
预先感谢，
丹尼尔
I got a code that I'm required to optimize. I would like to maintain a set of versions of the code (each version can be described as a composition of some features, optimizations) simultaneously. Eventually, I'll decide which version is the best one. I do not want to merge these versions into fewer versions. However, I would like to be able to make a (minor) modification to a (big) source file which may divert across the versions and I want this modification to write through more than one (possibly all) versions. How can I achieve that with git?
For example let us consider 3 versions: v1, v2, v3 and source code file source.cpp which has lots of code that is different across all versions but class A method aMethod() is identical. I would like to update the method and write the update to versions v1 and v2 only.
How can I do that?
If I modify source.cpp, for example, in v1, than merge it to v2 there will be a merge conflict (because source.cpp is different in v1, v2). Is there any way to avoid the conflict? If not, what is the best way to deal with the merge conflict int this case?
By the way, I don't want to increase code granularity so that the aMethod() will be placed in a dedicated file, because there is already lots of source code written and there will be too much overhead for doing this for any such modification that I describe.
Thanks in advance,
Daniel
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否尝试过 gitcherry-pick ？如果您从分支 v1 到分支 v2 执行“git merge”，则 v1 中而不是 v2 中的所有提交都将被合并，这不是您想要的。如果您只是选择带有更改的单个提交，我认为不会出现合并冲突。
Have you tried git cherry-pick? If you do "git merge" from branch v1 to branch v2 all commits that are in v1 and not in v2 will be merged over, thats not what you want. If you just cherry-pick the single commit with your change I don't think there will be a merge conflict.
如果您正在进行的优化大多彼此独立，您可以从起点为每个单独的优化进行分支，并且当您想要测试某些组合时，从起点创建另一个分支并对所需的进行章鱼合并优化。
If the optimizations you're making are mostly independent of each other, you could branch for each individual optimization from your starting point, and when you want to test some combination, make another branch from the starting point and do an octopus merge of the desired optimizations.
在单个源文件中测试各种替代方案是可以的。
正如您所指出的，git 合并旨在使版本收敛，当分布式团队希望在不互相干扰的情况下工作时，这特别有用。
它不能帮助您保持文件的不同。 cherry-pick 可以填补这个空白，但与 darcs 等价物不同的是，它不使用历史记录，并且在很多情况下可能不起作用。将您的微小更改引入主题分支可能会起作用，但您需要使它们依赖于早期的通用修订版，并且仅从它们合并，而不是合并到它们中。
由于您控制一切，因此您可以测试不同的算法，同时保持它们兼容和同步，并且不需要多个分支。
It would be ok to test the various alternatives in a single source file.
As you noted, git merging is designed to make versions converge, which is particularly useful when distributed teams want to work without stepping on each other toes.
It doesn't help you keep files distinct. cherry-pick can fill the gap, but unlike the darcs equivalent it doesn't use the history, and may not work in many cases. Introducing your minor changes into topic branches could work, but you would need to make them dependent on an early, common revision and only merge from them, not into them.
Since you control everything, you can test diverging algorithms while keeping them compatible and in sync, and you don't need multiple branches.