我刚刚继承了一个使用 Git 维护的项目。代码一度被部署到 3 个独立的系统上，每个系统都维护自己的去中心化 Git 存储库。
3个系统中的每一个都在3个不同的方向上扩展了原始的基础系统。这 3 个系统均未相互同步。一些更改发生在主分支上，其他更改发生在新分支上。
我如何将 3 个不同的来源整合在一起，以便我可以：
- 找到共同的合作基础；
- 找出哪些更改是错误修复，应在所有 3 个系统中应用；和
- 以一种合理的方式维护 3 个系统，以便只有一个公共分支，并将 3 个不同系统所需的定制分开？
我可能会首先将所有存储库推送到中央存储库中的单独分支，从中我可以轻松地在分支之间进行变基、合并等。
一个好的可视化工具，例如git-age, gitnub, gitx, giggle可以创造奇迹，但除非你能找到分支点，否则你的任务可能会相当乏味。如果有类似的补丁应用于您可以使用的所有分支（交互式）rebase重新排序您的提交，使它们处于相同的顺序。然后你可以开始“压缩”你的分支，通过将提交放入 master 来向上移动分支点。可以找到有关如何使用 rebase 重新排序提交的详细描述here.
很可能您需要采取的操作已在提供的链接中进行了描述Git 如何建立索引。一个好的备忘单触手可及总是很高兴。另外，我怀疑埃里克·辛克斯帖子的后续内容“DVCS 和 DAG，第 1 部分”将包含一些有用的东西（它没有，但仍然是一本有趣的读物）。
其他值得拥有的链接是：git 魔法, 准备好 Git and SourceMage Git 指南
我希望所有的存储库都有良好的提交消息，告诉您每个补丁的目的，就是这样或代码审查:)
至于如何维护定制，我们很幸运做到了以下几点：
我们首先将定制代码与通用代码分开（或保持分离）。然后我们尝试了两种方法；两者都运行良好：
- 所有部署都有自己的存储库，其中保存了自定义内容。
- 所有部署在“自定义”存储库中都有自己的分支。
在第一次部署并看到第二次部署之后，我们花了一些时间尝试预见未来的定制/切入点，以减少定制存储库（替代方案 1，这是我们当前使用的方法）和基础/核心中的重复回购。
是的，每当我们注意到核心/定制拆分滑动时，我们都会尝试无情地重构:)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
