问题:当多个用户有权访问同一工作目录时,如果git执行任何操作,则可能会在元数据中发生权限问题.
免责声明:在你惩罚我之前 - 我意识到共享一个工作目录与Git所代表的相反,我不是在谈论除了这个共享目录中的只读操作之外的任何事情 - 我们在我们自己的本地存储库中完成所有工作.
我愿意接受另一种方式来做我们正在尝试做的事情,因为我们的做法当然不是最佳做法,但我不确定那些对其他人有用的对话.那么现在让我提供一些我们为什么这样做的细节:
我们团队中有几位构建大师.我们部署到Linux服务器,我们在那里进行构建,使用直接从Git获取的构建脚本.我们目前无法使用CI(例如Jenkins/cruisecontrol),因此我们有一个我们结帐的存储库并从中进行QA构建.
我们执行了一些git操作作为脚本的一部分.这包括一些提交标记(东西标记为QA-current,QA-previous等...).所以我想我们实际上并不是完全只读的.由于构建脚本的性质,我们将其sudo作为普通用户运行(让我们称之为用户DevAdmin).我意识到这可能是一种不好的做法,也许是痛苦的根源,因为它迫使我们使用共享的回购结账.
如果在那个工作目录中我们总是被淹没的话,这一切都会好的.问题在于,有时候,我们中的一个人会偶然做一个git pull或类似的东西,而不是被Devdomin作为DevAdmin.所以大部分文件.git都归DevAdmin所有(他们执行了初始克隆),但每当我们这样做时,我们最终会.git/objects得到包含特定用户拥有的文件的dir .这些是作为群不可写的创建的.例如,我也注意到ORIG_HEAD了错误的所有权.因此,当我们尝试使用DevAdmin时,我们会遇到问题.
我们可以做些什么来解决这个问题吗？现在,我们必须认识到它已经发生,然后让服务器管理员chown .git回到DevAdmin.或者让用户删除有问题的元文件,或者至少将chmod它们删除为可写组.这一切看起来都很糟糕.
我考虑了几个不涉及改变我们的构建和维护过程的选项:
如果我们删除了组写访问权限.git并将其限制为DevAdmin,那是否会阻止这种情况再次发生？这似乎是最直接的选择.
或者有没有办法让所有东西都成为.gi可写的,即使它是新创建的？这似乎是在惹麻烦.
还有其他明显的东西我不见了吗？我意识到最好的办法可能是改变我们的流程,以便用户可以在他们自己的仓库中工作,但在商业环境中,仓库可以变得非常大(罐子还没有分离出来,很多二进制文件等等) ...),我们不能为每个人的帐户提供多GB的回购.此外,我们的系统管理员在他们改变流程以允许它之前会有很多工作要做.
任何想法都表示赞赏.