【问题标题】:Is there a canonical way to retroactively split a git repo into a public and private variant?是否有一种规范的方法可以追溯地将 git repo 拆分为公共和私有变体?
【发布时间】:2019-03-29 13:09:33
【问题描述】:

我有一个 git 存储库,其中包含一些敏感数据可能是硬编码的,或者是正式硬编码的,现在驻留在 git 历史记录中的某些位置。

为了使项目公开可用,以便具有相似兴趣的程序员可以从中受益并回馈更改,我想分叉它以清理有问题的文件。

我考虑的过程如下:

  1. Shallow/Shared 将 repo 本地克隆到新的本地位置,此文件夹将成为公共变体。后续步骤在新的存储库中。
  2. 将master分支到一个分支public-master
  3. 删除所有其他分支引用。
  4. 消毒public-master
  5. 壁球public-master
  6. git reflog expire --expire-unreachable=now --all && git gc --prune=all --agressive 删除所有无法访问的 refs,现在是任何不在公共分支中的 obj
  7. git push 将公共 master 添加回上游到私有存储库中。
  8. 将源远程设置为公共 repo url,分支到 master。推送到原点。

这是否足以清理我的存储库,或者在此之后是否可以恢复敏感数据。有没有更明智和通用的方法来解决这个问题?有没有多余的步骤?

例如,我可以在一个存储库中完成这一切吗,或者 git-packs 的性质是否意味着我仍然可以推送包含敏感信息的 obj

【问题讨论】:

  • 为了公开它,显然从头开始创建一个只有最新(经过清理的)提交的存储库更好。此外,敏感数据通常会转到一个单独的文件,从第一次提交开始,该文件在 .gitignore 中被忽略。
  • 我知道,但这是一个爱好项目,所以我使用了马虎的 opsec。因此,为什么这里需要追溯方法。
  • 啊,我明白了,是的,在完成所有这些步骤之后,这实际上相当于刚刚生成了经过清理的版本,然后将工作树复制到了一个全新的 repo 中。唯一的问题是我希望能够从私人仓库中提取,然后他们将拥有未共享的历史记录。
  • @b-fg 。所以我想也许一个更好的问题是,给定一个全新的回购,我怎样才能将新的公共分支移植到我的旧私人回购中。然后将新功能放入公共 repo,然后拉回私有 repo。

标签: git publishing privacy computer-forensics git-reflog


【解决方案1】:

结合@VonC 和@b-fg 答案我认为最明智的解决方案如下。 请注意,很容易用可能包含敏感日期的 obj 污染新的公共存储库,而是构建一个新的公共存储库。

  1. 将私有存储库分支到public
  2. 消毒public
  3. 为公众初始化新的 repo。
  4. git --work-tree=/path/to/private add -p . 导致 git 使用公共索引运行,但使用私有清理工作树。公共回购现在已经上演了所有经过消毒的分支的工作树,所以git commit
  5. 本地存储库具有来自索引中已清理分支的工作树,但没有工作树,换句话说,它看起来像当前工作树中的所有内容都已从索引中删除。使用git reset --hard将文件“恢复”到新仓库的工作树
  6. 切换回私有存储库并将公共存储库添加为远程。 git remote add public file://path/to/public/repo
  7. 历史记录 private/publicpublic/master 现在是不相交的。所以我们需要将它们嫁接在一起。使用git branch -u public master 设置private/public 的上游现在拉允许不相交的历史记录git pull --allow-unrelated-histories
  8. 将公共分支设置为只能读取,不能写入更改,以防止意外污染公共仓库git remote set-url public --push "This Branch is Read-Only"

现在只在公共存储库中创建新功能,并根据需要将它们拉回私有存储库。

【讨论】:

  • 是的,我支持这个答案。
【解决方案2】:

唯一的问题是我希望能够从私人回购中提取,然后他们将拥有未共享的历史记录。

这似乎是不可避免的,因为您已经更改了分支历史并将其压缩。

我不会从新的公共 repo 中提取,而是简单地考虑对新 repo 克隆所做的更改,然后决定要添加到旧私有 repo 的本地克隆中的哪一个:

# update local content of new repo
cd /path/to/public/repo 
git pull

# check what needs to be added
cd /path/to/clone/of/old/repo
git --work-tree=/path/to/public/repo add -p .

您将看到新旧之间的差异,这些差异来自公共 repo 上可能进行的新演变。

【讨论】:

  • 哦,你知道我不明白为什么工作树 arg 以前在那里。我认为正确的解决方案就在这里。需要明确的是,我只会将公共更改拉回旧仓库,而不是相反,因为那样会冒着污染公共对象的风险。
  • @awiebe 好的,然后反转路径。
  • 我现在要接受这个,并写一个更详细的说明我最终做了什么。
猜你喜欢
  • 2013-11-07
  • 1970-01-01
  • 2016-08-29
  • 2014-02-03
  • 2012-10-09
  • 2015-11-22
  • 2011-11-01
  • 1970-01-01
相关资源
最近更新 更多