2

在过去的几个月里，我的团队一直在开发一个平台，我们准备将它发布给公司的其他人。我们想遵循此处找到的“集成管理器工作流程”：http: //git-scm.com/book/en/Distributed-Git-Distributed-Workflows。

我们的团队存储库中有一些专有代码，我们不希望与公司的其他人共享，因此必须创建我们当前团队存储库的“精简”版本。我正在考虑执行以下操作：

  1. 克隆我们现有的团队存储库以创建“集成管理器存储库”

  2. rm所有专有文件

  3. commit有效值

  4. rebase -i --root压缩所有提交并防止倒带

  5. clone --bare“集成管理器回购”创建“祝福回购”

现在，由于对 Git 相对缺乏经验，我对这种方法有几点不确定：

  1. 我还能从“blessed repo”中拉取到我们的团队 repo 中吗？

  2. 假设我可以做到 #1，我认为 rms 将被拉出，删除我们所有的专有文件。我需要 Git 将我们的团队 repo 的更高级状态视为祝福 repo 状态的子状态。这是我可以用 rebase 做的事情吗？

  3. 随着我们继续在平台上工作，我们将承诺向我们的团队回购“公共”功能和专有功能的混合体。仅推送“公共”功能的最佳方式是什么？我rebase可以更改提交的顺序，以便所有“公共”功能提交都在提交历史记录的前面，然后 git push 只到最新的“公共”功能提交的 SHA？

在此先感谢您的帮助...在进行如此大的更改之前，我想由一些更有经验的 Git 用户运行它。

更新 对不起，我不清楚......步骤2、3和4都适用于“集成管理器回购”。无论如何，我阅读了更多内容，rebase并认为rebase每次我们进行“公开”更改时，对我们团队的共享存储库都不是一个好主意。

我最终做的而不是步骤 2、3 和 4 是rm“集成管理器存储库”中的 .git 文件夹，并从 .git 重新开始git init。然后我从这个新的“集成管理器存储库”中提取并与我们团队的存储库合并，使用-s ours标志，因为我们团队的版本是一个超集。现在我们的团队 repo 和公共 repo 有一个共同的提交。我在我们的团队仓库中创建了一个“公共”分支，并将其指向这个常见的提交。展望未来，每当我们进行公开更改时，我们都需要将其挑选到这个“公共”分支中，然后将公共分支拉到“集成管理器存储库”中。

4

1 回答 1

0

您将无法pull从受祝福的 repo 更改为 team one（因为它们是rebased），但您可能可以更改cherry-pick它们。当然，冲突可能会成为你日常生活的一部分。

当你压扁你rm的 s 时，你的祝福回购将永远不会看到那些rms 被执行。因此，每当您将cherry-pick这些提交提交到您的团队存储库中时，您只会拥有永远不会更改的文件（以及可能产生的麻烦）。

问题将是从团队回购发布更改回祝福的:)

如果我是你（好吧，前段时间我处于类似的位置），我会考虑创建任何类型的脚本，将更改从一个存储库移动到另一个存储库。当从祝福者转到团队一者时，请根据已更改的文件（如果有）对您可能希望查看的相关 rm'ed 文件发出警告。返回时，排除对 rm'ed 文件的更改。

无论如何，我认为这根本不是一个好主意。在疯狂之前进行三重检查 - 也许从婴儿步开始？

祝你好运 ：）

于 2013-08-13T01:17:35.657 回答