排除Git混乱

时间:2009-03-03 09:20:49

标签: git version-control branch dvcs

我刚刚继承了一个使用Git维护的项目。有一次,代码被部署到3个独立的系统上,每个系统都维护着自己的分散式Git资源库。

3个系统中的每个系统都在3个不同的方向上扩展了原始基础系统。 3个系统中没有一个系统相互同步。一些更改在主分支上,其他更改在新分支上。

如何将3种不同的来源组合在一起,以便我可以:

  1. 找到合适的基础;
  2. 找出哪些更改是应该在所有3个系统中应用的错误修复;和
  3. 以理智的方式维护3个系统,以便只有一个公共分支,并将3个不同系统所需的自定义分开?

2 个答案:

答案 0 :(得分:13)

我可能首先将所有存储库推送到中央存储库中的独立分支,从中我可以轻松地在分支之间进行变基,合并等。

良好的可视化工具,例如git-agegitnubgitxgiggle可以创造奇迹,但除非您能找到分支,否则您的任务可能会相当繁琐点。如果有类似的补丁应用于所有分支,您可以使用(交互式)rebase重新排序您的提交,使它们处于相同的顺序。然后你可以开始“拉上”你的分支,通过将提交放入master中来向上移动分支点。有关如何使用rebase重新排序提交的详细说明可以在here找到。

您可能需要采取的行动在Git Howto Index提供的链接中有所描述。一个好的cheat sheet总是很好的触手可及。此外,我怀疑Eric Sinks发布的帖子“DVCS and DAGs, Part 1”将包含一些有用的东西(它没有,但仍然是一个有趣的读物)。

其他有用的链接包括:Git MagicGit ReadySourceMage Git Guide

我希望所有的回购都有良好的提交信息,告诉你每个补丁的目的,就是那个或代码审查:)。

至于如何维护自定义,我们已经幸运了以下内容:

我们首先将自定义代码与通用代码分开(或保持分开)。然后我们尝试了两种方法;两者都很好:

  1. 所有部署都有自己的存储库,其中保留了自定义。
  2. 所有部署都在“自定义”存储库中拥有自己的分支。
  3. 在第一次部署并看到第二次是事实之后,我们花了一些时间来预测未来的定制/切割点,以减少定制回购中的重复(alt.1,这是我们目前使用的方法)和基地/核心回购。

    是的,每当我们发现核心/定制拆分滑落时,我们都会尝试无情地重构:)

答案 1 :(得分:4)

行。在经历了一次艰难的跋涉之后,我成功地做到了。对于任何开始执行类似任务的人来说,它将涉及很多:

git rebase

命令以及当事情搞砸的时候:

git reflog

接着是

git reset --hard HEAD@{ref}