单个 Git 存储库中的公共和私有代码答案

【问题标题】：Public and private code in a single Git repository单个 Git 存储库中的公共和私有代码
【发布时间】：2011-12-27 18:04:27
【问题描述】：

我参与的一个研究小组目前将他们的所有代码都托管在一个私有 SVN 存储库中。我们想开放我们的代码并将其大部分移至 Github。问题是，有些代码很敏感，不应该开放，但我们仍然希望它受到版本控制。目前，我们在 Github 上有开放代码，私有代码仍在私有 SVN 存储库中。有没有在单个 Git 存储库中执行此操作的好方法？

【问题讨论】：

标签： git version-control

【解决方案1】：

只有一个 git 存储库，没有。您可以使用git submodules，它允许您“组合”存储库。将您的公共代码保存在 github 上，为您的私有代码创建另一个私有托管的 git 存储库，该存储库将公共代码作为子模块引用。公共子模块内的更改可以推送到 github，github 上的更改可以拉回，但子模块外的更改不会暴露给公共社区。尽管代码树将合并到一个根目录中，但您必须在单独的模块之间独立管理提交、推送和拉取，许多人认为这很麻烦且有问题，因此您应该在广泛分发之前对工作流程进行一些实验。

【讨论】：

【解决方案2】：

没有。

除非您想编写 git 挂钩来加密/解密源代码，否则您将不得不使用两个存储库。当有人克隆 git 存储库时，他们实际上是对其进行了克隆，因此如果不加密，就不可能将其部分设为私有。

【讨论】：

【解决方案3】：

Git 子模块已移至此处：http://git-scm.com/book/en/Git-Tools-Submodules

这个想法是子模块是嵌入在私有 git 存储库中的公共 git 存储库。您可以单独管理它们，其优势在于私有 git 存储库在目录结构中嵌入了 publict 存储库文件。

例如：

/private-repository
    /some (private) directory
    /public-repository
        /some (public) directory
    /some other (private) directory

另一种选择是使用 git-crypt https://www.agwa.name/projects/git-crypt/

【讨论】：

【解决方案4】：

是的，git 子模块似乎也为我们解决了这个问题。我们曾经在我们私有存储库的同一分支中开发开源 CMS 和高级扩展（付费）。现在我们决定将核心开发切换到 github public repo 并拆分开发。

这就是我们的方法。

创建具有两个分支的公共存储库。 master 用于发布，develop 用于实际开发。
我们为每个扩展创建了新的存储库
我们有一个私有存储库，其中包含我们继续开发的核心文件，并将所有高级扩展添加为子模块。当然是私人的。分支名称 - dev.

为了合并更改，我们只需从分支 dev 中挑选出来进行开发，就是这样。在这种情况下，我们为公共存储库提供了一个干净的与核心相关的历史记录，并且只克隆一个存储库然后递归更新子模块非常容易。需要更多时间才能同步，无论如何这是值得的。

干杯

【讨论】：

【解决方案5】：

这是我用于项目初始阶段的工作流程。

private-master分行
confidential-removed 位于 private-master 之上的分支已删除私有内容 - 每个内容只能删除一次，而不是每次发布
public-master 基于非常早的提交，没有任何私人内容
version-branch 在 public-master 之上
一个通过樱桃采摘或挤压合并来自confidential-removed的新提交来准备版本分支
从version-branch 到public-master 的合并请求经过仔细审查，以确保所有贡献都可以公开，差异是人类可读的
public-master 也被推送到公共远程/分叉

或者，可以使用public-feature-branches 代替version-branches，他们将首先在内部进行审核，然后在公共存储库中进行审核。

此工作流程的特点：

同一文件在公共和私人中可以有不同的版本
无需根据宣传级别编码不同的文件夹
无需基于宣传级别的多个存储库中的代码
公共分支开发者的贡献可以合并到私有分支，但可能会出现一些冲突。

以下是这种方法的缺点：

需要专人进行额外的工作，并且
也有点容易出错。
cherry-picking 可能会揭示隐藏的依赖关系（即，选择的代码可能会使用一些未选择的代码）。

如果项目变大，参与者数量增加，保密性变得更加重要，应该真正将项目一分为二，并将公共作为共享后端，作为您私人的库或插件。

【讨论】：