Question

当前，我正在尝试通过git子模块管理我的所有菜谱，而我只是想确保以后的组织方式没有任何问题。

我考虑到，从可管理性的角度来看，将所有存储库放在一个篮子（单个厨师存储库）中是很受欢迎的，但是我也不想告诉我的开发人员他们将不得不在测试厨师的代码之前执行厨师运行时，我们分别管理和提取/克隆每个仓库（我们也在使用berk和厨师服务器）。

因此，以下git子模块策略是我的解决方案：

chef-repo < main >
├── chef-repo/LICENSE
├── chef-repo/README.md
├── chef-repo/chefignore
├── chef-repo/cookbooks
│   ├── chef-repo/cookbooks/README.md
│   ├── chef-repo/cookbooks/active-directory < submodule >
│   │   ├── chef-repo/cookbooks/active-directory/Berksfile
│   │   ├── chef-repo/cookbooks/active-directory/attributes
│   │   │   └── chef-repo/cookbooks/active-directory/attributes/default.rb
│   │   │   ├── chef-repo/cookbooks/active-directory/libraries/cmd_helper.rb
│   │   ├── chef-repo/cookbooks/active-directory/recipes
│   │   └── chef-repo/cookbooks/active-directory/resources
│   │       ├── chef-repo/cookbooks/active-directory/resources/computer.rb
│   ├── chef-repo/cookbooks/example
│   ├── chef-repo/cookbooks/java < submodule >
│   │   ├── chef-repo/cookbooks/java/Berksfile
│   │   ├── chef-repo/cookbooks/java/recipes
│   │   ├── chef-repo/cookbooks/java/templates
│   ├── chef-repo/cookbooks/redhat_subscription_manager < submodule >
│   └── chef-repo/cookbooks/windows < submodule >
├── chef-repo/data_bags
├── chef-repo/environments
├── chef-repo/roles

我知道子模块也不是很流行，所以我采用了这种方法，以便开发人员可以拉动并克隆整个chef-repo，但是他们会将代码提交给单个存储库。

有更好的方法吗？

谢谢：）

Answer 1

更好的方法？子模块就足够了，即使您可以签出 subtrees （我illustrate here）

但是对于子模块，尤其是如果您的贡献者仍在其各自子模块存储库的master分支上，请不要忘记以下命令：

git submodule update --remote --recursive

这足以将所有子模块更新为对master的最新提交。

通过git子模块管理厨师食谱

1 个答案: