情况就是这样：我正在将一堆repos迁移到github。目前，repos被组织成诸如“堆栈”，“网站”，“应用程序”等组/目录。
我没有办法（我发现）在GitHub上为repos创建组或文件夹，除了组织，这似乎是一个糟糕的选择。但也许不是吗？这里的问题是一些组非常小，而其他组很大......有子组，我想将所有项目保存在一个根桶中。
所以，我可能会使用命名约定。比如：'stack-apache'，'website-foo.com'，'application-some-project'。或者只是放弃在github中组织它们，让项目页面/网站处理组织。
重新。规模，我最初看的是20+回购，随着时间的推移新增回购，未来几年的估计费率为2-5 /年。
任何人都有这方面的经验吗？
答案 0 :(得分：15)
20+ repos
这真的不是那么糟糕。
这个想法实际上是使用组织将您的相关仓库分组在一起。这也使您的团队成员更容易将他们的活动供稿过滤到他们感兴趣的组织。
这就像在Github上一样，因为git是基于repo的，而不是基于SVN的文件系统。
也许“组织”不是一个非常直观的名称，但在像Gitlab这样的替代Git平台上，这些部门被命名为“group”。你应该真的这样认为。
答案 1 :(得分：8)
在我看来，组织在Github中的目的不同于分组回购（尽管它们确实用于组合回购）。组织更多的是关于回购访问的细粒度控制（这是我的理解）。
Bitbucket引入了“Projects”的概念，具有以下层次结构（与Github进行比较）：
Bitbucket: Team -> has N -> Projects -> has N -> Repos
Github: Organisation -> has N -> Repos
Bitbucket仍然允许Repos not 被分配给团队或项目，我猜想支持在项目概念之前存在的旧回购。
回答这个问题，不，不是直接。 Github有未完成的请求添加组，但似乎不太可能（此时）。
前缀作为一个马马虎虎的解决方案：
回购名称：[project]__[repo name]
假设你有一个客户“极致”有两个回购：
例如：acme__api
例如：acme__landing
Github的搜索快速且内联，因此在您的回购列表中搜索acme__将列出acme__项目的所有回购。
答案 2 :(得分：4)
我认为，在github上对repos进行分组的想法是在你想要彼此相关的项目之间放置一个分隔符。例如，“project1_projectA_projectX”或“project1-projectA-projectX”，甚至“project1 - projectA - projectX”。
对于我自己，我更喜欢双划线定界符，更直观地替换斜线字符分隔符（/），而不太可用于独立存储库名称。
然后，您必须创建的计划项目列表为：
只要您在名称中创建带有分隔符（_或 - ）的存储库，就不会有选项来设置回购标题页面中的回购描述或许可证。首次推送后，您必须从存储库标题页处理这些内容。但是你可以保持简单，例如，对于projectX，它将是这样的：“project1 - projectA submodule”。