如何使用git / github处理两个独立但非常相似的代码库?

时间:2011-11-06 18:51:51

标签: git github codebase

在git和git-hub中处理两个独立但非常相似的代码库的最佳方法是什么?

背景

我有一个小型shell脚本项目的git存储库。它只有2或3个代码文件,我经常在一个文件中工作。虽然我最初的目标是服务于我的特定目标,但我认为它对其他人来说更有用。我编写了一般用例版本,然后将其修改为特定于我的特定目标。在特定的版本中,我可能会修改变量,输入密码,切换一些代码的顺序,取出for循环...无论如何。

我尝试了什么

我尝试了两种不同的方法,并且都没有像我认为的那样最佳:

  1. 两个单独的回购
    • 问题:代码被修改为一个,不能轻易地和有选择地合并到其他
  2. 一个回购中的两个分支
    • 问题:分支最终会合并在一起。我并不是要将这些完全合并在一起,而是有选择地合并部分代码。
    • 问题:我发现当尝试在分支之间使用合并命令时,很容易混淆什么分支被合并的代码。我以某种方式合并了其中两个完全无意的代码,并且在我查看两个分支中文件的内容之前没有任何关于错误合并的迹象
  3. 我还看到How to merge two seperate - yet similar - codebases into one SVN rep?与SVN有关。因为我不知道SVN,所以我很难跟随。我认为这是一个不同的问题,因为他并没有试图公开这个代码的一个版本。

    我想解决的用例

    具体来说,问题在以下时间出现:

    • 评论同步 - 我正在准备我的专业版,并注意到我可以在一行末尾添加一个解释性评论。我添加它,但评论现在不是通用版本。
    • 东西我不想共享 - 我正在准备我的专业版本,我添加了密码或更改操作的完成顺序。我不希望这些更改进入通用版本。
    • 相同文件 - 上述两个更改通常位于同一个文件中,这使得很难将内容合并在一起。有交互式合并,但我不知道是否可以在单个文件中完成交互。
    • 一般 - >专业 - 我或其他人可能会更新通用版本,以获得在我的专业版本中也有用的新内容或评论。我想把这些从一般 - >>专业版,不会弄乱专业版中的任何其他代码差异。

    Git vs Github

    大多数情况下,我的问题是想知道如何在git的范围内做到这一点。但是,它也可能影响如何与github进行交互。我的通用版本在github上。专业版不应该在github上。我认为如果我小心的话,我上面的分支方法没有推动两个分支......但我总是不确定。无论哪种方式,解决方案应该允许有一个公开的版本,一个版本只是本地保存...即使它有点复杂或需要小心。

4 个答案:

答案 0 :(得分:4)

这可以通过两个分支轻松完成。我不确定为什么你说“代码被修改为一个,不能轻易地和有选择地合并到其他代码”,因为在Git中合并很容易。

我建议的结构是为您的通用版本设置一个分支,为您的个人版本设置一个分支。合并只应在一个方向发生,从一般分支到个人分支。这意味着您对常规版本所做的任何更改都会合并到个人版本中。

换句话说,这没关系......

git checkout personal
git merge general

这是你永远不应该做的......

git checkout general
git merge personal

如果您对个人版本进行了更改,并且认为在通用版本中使用相同的代码会很精彩,那么您应该可以使用樱桃选择轻松地处理这个问题。只需稍加考虑就可以在个人分支中组织提交。您将需要在个人分支中进行提交,该提交仅包含您想要带到一般版本的更改,然后只需将其从个人分支中删除并将其放到一般分支上。

两个存储库可以完成同样的事情。这样可以降低您不小心将个人版本上传到Github的风险,但这会使处理这两个版本变得更加繁琐。

就个人而言,我会在同一个回购中使用两个分支。

答案 1 :(得分:1)

为避免将您的专业版推送到github,请将push.default配置设为tracking(或upstream为git> = 1.7.4.2)。有关血腥的详细信息,请参阅http://longair.net/blog/2011/02/27/an-asymmetry-between-git-pull-and-git-push/

无论您使用单独的仓库还是仅使用分支,合并都应该同样有效。作为一个高级答案,你最终必须非常善于合并。其中很多都将来自于真正深入研究git如何在分支,合并和变基的低级别工作。与其他版本控制系统不同,我发现git需要深入了解其内部才能真正正确使用它。

答案 2 :(得分:1)

我的想法是使用两个分支:一般版本的公共分支(推送到GitHub)和专用代码的私有分支(未在GitHub上发布)。但是,我想补充说git stash是一个必不可少的工具,可以让你在你勾勒的场景中做你想做的事情(你正在处理个人版本,你发现要在一般版本中进行更改。)

确实总是在常规分支中实现常规更改,然后执行

git checkout personal
git merge general

现在,此外,您可以有效地使用 git stash;让我们来看看您正在更新专用版本并考虑一般性更改的场景:

  1. 您将当前更改保存到专用版本:

    git stash
    

    与最后一次提交相比,这会隐藏更改,而不会创建新提交。这对于存储正在进行的未提交作品非常有用。

  2. 你去一般分支,以便做出你正在考虑的一般性改变:

    git checkout general  # or master, or whatever name your general branch has
    

    然后,您可以实施常规修改并照常提交。

  3. 在恢复专用版本的工作之前,您可以导入常规更改:

    git checkout personal
    git merge general
    

    git非常聪明,可以很好地执行此操作:只需对您的代码进行最新的,通常有用的更新。

  4. 您可以通过导入正在进行中的藏匿工作来恢复您在专业分支上的工作:

    git stash pop
    
  5. 这就是全部!关键是使用git stash来保存工作中间的更改,而不是为此创建提交,然后使用git stash pop应用您的更改。

答案 3 :(得分:0)

使用git submodules。如果要保留子模块的单独分支,请在该项目的repo中创建一个分支,并将所有更改保存在本地分支中,并在子模块结帐时仅使用该分支。

不同变更集之间的合并是您需要半手动完成的。 Git有很好的合并支持,如果你不保持两个分支相距太远,你应该能够通过最少的人工干预获得。 github(或任何其他托管服务提供商)实际上与此任何事情无关。如果您想将分支保密,请不要将其推送到公共仓库。就这么简单。