的确，Git 的授权做不到 Subversion 那样按照路径进行授权。 Subversion 可以通过授权文件，将权限设置到每一个路径。但是也有缺憾，即权限不能在分支中继承。例如为 /trunk 及其子目录的授权，不能继承到分支或者里程碑中相应的目录下。群英汇通过泛路径授权能够简化分支授权的配置，但毕竟也还是需要进行配置。 Git 的授权模型只能实现非零即壹式的授权，要么拥有全部的写权限，要么没有写权限，要么拥有整个版本库的读权限，要么禁用。 从技术上将，Git 可能永远也做不到类似 SVN 的路径授权（读授权）：

• 如果允许按照路径授权，则各个克隆的关系将不再是平等的关系，有的内容多，有的内容少，分布式的理念被破坏
• 如果只有部分路径可读，则克隆出来的提交和原始提交的提交ID 可能不同。因为提交ID是和提交内容有关的，克隆中提交的部分内容被丢弃，势必提交的 ID 也要重新计算
• 允许全部代码可读，只允许部分代码可写，在版本控制的管理下，是没有多大实际意义的，而且导致了提交的逻辑上的不完整。

那么有什么办法来解决授权的问题么？

1. 公司内部代码开放。即代码在公司内部，对项目组成员一视同仁的开放。 就像上周末在北京 OpenParty 上， ThoughtWorks 工程师所说的，虽然我并不是非常认同：

   公司内部对代码进行精细控制没有意义。代码没什么好隐藏的，有的公司代码拿出去还有害。（因为代码太烂？）

2. 公司对代码库进行合理分解，对每个代码库分别授权。即某个代码库对团队成员完全开放，对其它团队完全封闭。
3. 公司使用 Subversion 做集中式的版本控制，个人和/或团队，使用 Git-svn。这样在无法改变公司版本控制策略时，程序员采用的变通之法。
4. Git 服务器的部署实际上可以使用钩子对 分支和路径进行写授权，即可以控制谁能够创建分支，能够写特定文件。

您有什么更好的建议呢？