整理 Git 混乱
我刚刚继承了一个使用 Git 维护的项目。 代码一度被部署到 3 个独立的系统上，每个系统都维护自己的去中心化 Git 存储库。
3个系统中的每一个都在3个不同的方向上扩展了原始的基础系统。 这 3 个系统均未相互同步。 一些更改发生在主分支上，其他更改发生在新分支上。
我怎样才能将 3 个不同的来源整合在一起，以便我能够：
- 找到一个共同的基础来工作；
- 找出哪些更改是错误修复，应在所有 3 个系统中应用； 并
- 以一种合理的方式维护这 3 个系统，以便只有一个公共分支，并将 3 个不同系统所需的定制分开？
I've just inherited a project which was maintained using Git. At one point, the code was deployed onto 3 separate systems and each system maintained their own decentralised Git respository.
Each of the 3 systems extended the original base system in 3 different directions. None of the 3 systems have been synchronised against each other. Some changes are on master branch, others are on new branches.
How can I bring the 3 different sources together so that I can:
- find a common base to work with;
- find out which changes are bug fixes which should be applied across all 3 systems; and
- maintain the 3 systems in a sane way so that there is only one common branch and separate out the customisations required for the 3 different systems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我可能会首先将所有存储库推送到中央存储库中的单独分支，从中我可以轻松地在分支之间进行变基、合并等。
一个很好的可视化工具，例如 git-age、gitnub, gitx, giggle 可以创造奇迹，但你的任务可能会相当乏味，除非你能找到分支点。 如果所有分支都应用了类似的补丁，您可以使用（交互式）rebase 来重新排序您的提交应保持相同的顺序。 然后你可以开始“压缩”你的分支，通过将提交放入 master 来向上移动分支点。 有关如何使用 rebase 重新排序提交的详细说明，请参见 这里。
Git Howto 索引。 一份好的备忘单总是很高兴触手可及。 另外，我怀疑 Eric Sinks 帖子“DVCS 和 DAG，第 1 部分”的后续内容将包含一些有用的内容（它没有，但仍然是一本有趣的读物）。
其他值得拥有的链接是：Git Magic、Git Ready 和 SourceMage Git 指南
我希望所有的存储库都有良好的提交消息，告诉您每个补丁的目的，就是这样或代码审查:)
至于如何维护自定义，我们很幸运地
做到了以下几点：我们从将定制代码与通用代码分开（或保持分离）。 然后我们尝试了两种方法； 两者都工作得很好：
在第一次部署并看到第二次部署之后，我们花了一些时间尝试预见未来的定制/切入点，以减少定制存储库（替代方案 1，这是我们当前使用的方法）和基础/核心中的重复回购。
是的，每当我们注意到核心/定制拆分滑动时，我们都会尝试无情地重构:)
I would probably start by pushing all the repositories to separate branches in a central repository, from which I can rebase, merge etc between branches easily.
A good visualization tool such as git-age, gitnub, gitx, giggle can work wonders, but your task will probably be rather tedious unless you can find the branching points. If there are similar patches applied to all branches you can use (interactive) rebase to reorder your commits such that they are in the same order. Then you can start 'zipping up' your branches, moving the branch-point upwards by putting commits into master. A nice description on how to reorder commits using rebase can be found here.
Chances are the actions you need to take are described in the links provided by the Git Howto Index. A good cheat sheet is always nice to have within reach. Also, I suspect the followup to Eric Sinks post "DVCS and DAGs, Part 1" will contain something useful (It didn't, but was an interesting read nontheless).
Additional good-to-have links are: Git Magic, Git Ready and SourceMage Git Guide
I hope all the repos had good commit messages that tell you the purpose of each patch, it's that or code review :)
As for how to maintain customizations we've had luck with the following:
We started by separating (or keeping separate) the customized code from the generic code. Then we've tried two approaches; both which worked fine:
After the first deployment and seeing that the second was a fact we spent some time trying to foresee future customization/cutting points to reduce duplication across the customized repos (alt. 1, which is the approach we currently use) and in the base/core repo.
And yes, we do try to refactor mercilessly whenever we notice the core/customization split slipping :)
好的。 经过一番艰苦的努力，我终于做到了。 对于从事类似任务的其他人来说，这将涉及很多：
命令以及当事情搞砸时：
其次是
git reset --hard HEAD@{ref}OK. After a big of a slog, I've managed to do it. For anybody else embarking on a similar task, it will involve a lot of:
commands and when things got screwed up:
followed by
git reset --hard HEAD@{ref}