我的团队过去几个月一直在开发平台，我们已准备好将其发布给公司的其他成员。我们想遵循此处的“集成管理器工作流程”：http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows。
我们的团队存储库中有一些专有代码，我们宁愿不与公司的其他人共享，因此必须创建我们当前团队存储库的“精简版”。我正在考虑做以下事情：
克隆我们现有的团队存储库以创建“集成 经理回购“
rm所有专有文件
commit rms
rebase -i --root压缩所有提交并阻止倒带
clone --bare“整合经理回购”创建“祝福回购”
现在，由于对Git缺乏经验，我对这种方法有几点不确定：
我还可以将“祝福的回购”拉进我们的团队回购中吗？
假设我可以做＃1，我认为rms会被拉，删除我们所有的专有文件。我需要Git将我们的团队回购更高级的状态视为受祝福的回购状态的子状态。这是我可以用rebase做的事情吗？
随着我们继续在平台上工作，我们将致力于我们的团队回购“公共”功能和专有功能的混合体。只推动“公共”功能的最佳方法是什么？我可以rebase更改提交顺序，以便所有“公共”功能提交都在提交历史记录的前面，然后git只推送到最新“公共”功能提交的SHA吗？
提前感谢您的帮助...我想在进行如此大的更改之前，让一些经验丰富的Git用户运行这个。
更新
对不起，我不清楚......步骤2,3和4都适用于“集成管理器回购”。无论如何，我在rebase上阅读了更多内容，并决定每次我们进行“公开”更改时，rebase我们团队的共享存储库都不是一个好主意。
我最终做的不是第2,3和4步，而是rm“集成管理器仓库”中的.git文件夹，并从git init重新开始。然后我从这个新的“集成经理回购”中撤出并使用-s ours标志与我们团队的回购合并，因为我们团队的版本是超集。现在我们的团队回购和公共回购都有一个共同的提交。我在团队回购中创建了一个“公共”分支，并将其指向此常见提交。展望未来，每当我们进行公开更改时，我们都需要将其挑选到这个“公共”分支中，然后将公共分支拉入“集成管理器回购”。
答案 0 :(得分：0)
您将无法pull从受祝福的回购更改为第1组（因为它们是rebase d），但您可以cherry-pick他们。当然，冲突可能是你日常工作的一部分。
当你压扁了你的rm时，你的受祝福的回购将永远不会看到那些rm被执行。因此，只要您cherry-pick提交到您的团队回购中，您就会拥有永不改变的文件（以及可能产生的麻烦）。
问题在于将团队回购中的变化发布回祝福的回复：）
如果我是你（嗯，前段时间我处于类似的位置），我会考虑创建任何类型的脚本，将更改从一个存储库移动到另一个存储库。当从祝福的一个到团队一个时，根据已更改的文件（如果有的话）对您可能想要查看的相关rm'ed文件发出警告。返回时，排除对rm'ed文件的更改。
无论如何，我认为这根本不是一个好主意。在疯狂之前进行三重检查 - 也许从babysteps开始？
祝你好运：）