Git:在分支和多个存储库之间做出决定
我正在努力让一个组织使用 git,并且我正在尝试确定哪种方法是更好的方法,要么拥有具有多个分支(开发、集成和发布)的单个存储库,要么为每个轨道拥有多个存储库。
更简单的方法是拥有分支和一个存储库,这是我的首选解决方案。我计划使用 gitolite 来控制分支的访问。
I'm working on moving an organization to use git, and I'm trying to determine which would be a better approach, either having a single repo with multiple branches (development, integration and release), or having multiple repos for each track.
The simpler approach would be to have branches and just a single repo, and this is my preferred solution. I plan to use gitolite for access control to branches.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
更多
发布评论
评论(3)
我们两者都有。使用单独的存储库是更好的解决方案。我们大约有 50 个人,没有任何问题,工作更容易组织。 Gitolite 非常适合管理所有这些。
We have had both. Using separate repos is the better solution. We have about 50 and there are no issues, work is more easily organized. Gitolite is great for administering them all.
正如您所回复的,到目前为止您有 20GB 存储库和 50 个用户。对于单个回购来说还不错。
你需要问自己的是,这个仓库的规模和用户增长速度有多快。
存储库的大小直接影响您进行离线备份的能力(如果您关心的话)。用户数量决定了存储库服务器的网络和磁盘 I/O 负载有多大。到目前为止,市场上大多数现代服务器都可以很好地满足您的需求。当您的存储库有数百 GB 和数千个用户时,情况并非如此。
As you replied you have 20GB repo and 50 users so far. Not too bad for single repo.
What you need to ask yourself is that how fast will this repo grow in size and users.
Size of repo directly affects your ability of doing off-line backup (if you care). Number of users determines how heavy the load will be for the repo server w.r.t. network and disk I/O. Most modern servers on the market shall handle your need well so far. It's not the case when your repo is several hundred GBs and thousands of users.
在 Hg 社区中,它一直是关于创建新的存储库而不是分支,并且后来添加了命名分支。但是,创建存储库仍然很常见。 Hg 和 Git 的分支和存储库都非常轻量级,根据您的情况,选择其中之一会更有利。
In Hg community it has been about creating new repos instead of branches and named branches were added later. But, creating repositories is still common. With both Hg and Git both branches and repositories are pretty lightweight and depending on your circumstances, it is advantageous to choose one over another.