Git和权限 哪里出错了

因此,这似乎是一个普遍的问题,并且有很多临时解决方案,但我想了解为什么通常以这种方式构建git。

问题:我克隆了一个具有一定权限的存储库,由于权限不同,git状态立即显示我的许多文件已“更改”。正如我提到的那样,我不是在寻找临时修复程序或更改默认Linux权限的方式,而是在寻找git为什么这样做以及问题的根本根源。

例如,对于我尚未提交的任何其他更改,我可以执行git checkout还原更改,但是当我执行此操作时,它不会更改文件的权限。如果git实际上正在跟踪我的权限,并认为权限更改了对文件的更改,为什么我不能执行git checkout才能恢复到初始权限?而且,如果git正在跟踪权限,那么除了让我能够更改我的权限并使之成为其他克隆或存储我的存储库的人创建具有相同权限的文件之外,还有什么目的?

我想我的问题归结为,如果git在文件更改时跟踪权限更改,为什么git不让我使用任何常规命令来确保我的项目与其他合作者保持最新状态权限是否与内容一样?为什么我需要经过临时绷带才能避免每次提交人员设置了不同的默认文件权限时,我的存储库就被文件权限更改提交所填充?如果这是一个生产项目,我们应该怎么做才能使权限更改提交实际上进入项目?例如,我们要限制文件,以便只有该组才能在生产环境中读取该文件,为什么开发人员不能像满足项目其他要求那样进行更改和提交/推送/拉取请求?一切都在linux btw上完成,因此我不在讨论来自不同文件系统的提交。

fanlianhou 回答:Git和权限 哪里出错了

Git只为文件保留一个权限位。在大多数情况下,Git仅存储文件-它不存储目录(或文件夹,如果您更喜欢该术语),而是按需创建它们。虽然Git确实存储符号链接,但是符号链接没有关联的权限-至少在Git中(通常在OS中也没有)没有关联权限。

更具体地说,当Git存储文件时,它以“模式”存储它。该模式完全是100644100755 1 该模式条目进入 index ,这是Git用于构建 next 提交-您可以在工作树中看到和使用的文件被设置为可执行或不可执行, chmod系统调用,前提是您的操作系统和文件系统实际上支持chmod操作。

如果您使用的是Unix或Linux类型的系统,当Git设置了这些模式位(如果可以)时,它会根据您的 umask 设置+x位。 umask告诉系统要设置哪些 not 位:002的umask表示文件为rwxrwxr-xrw-rw-r--,因为002得到已清除。 007的umask表示文件是rwxrwx---rw-rw----,因为007已被清除我们剥夺了对以下内容的读取,写入和执行权限: “其他”。 (这三个字段是“所有者”,“组”和“其他”,其中4 =读,2 =写,1 =执行。)

因此:索引通过存储mode(+ x)​​或100755(-x的100644来保存+ x或-x位)。在包括Windows在内的所有系统上都是如此。同时,工作树保留了操作系统和文件系统允许的所有内容。在Windows上,这通常根本什么都没有。

如果工作树没有任何内容,请使用Git:

  • 在创建存储库时记下了这一点,并且
  • 只保留存储在索引中的模式。

如果存储在索引中的模式(是很典型的)来自某个现有提交,那么它可能是正确的,并且Git应该将其保留,所以应该这么做。

将新文件添加到 索引以获取{我认为我尚未测试并且未运行Windows)模式100755,以防万一,但是您可以使用{{1} }或git update-index --chmod=+x进行更改:git update-index --chmod=-x表示+x,而100755表示-x

但是,如果工作树包含有用模式位-如果可以运行100644chmod +x somefile更改 { {1}}在您的工作树中-然后Git记下了这一点,当您第一次创建存储库时,现在 chmod -x somefile复制 somefilegit add进入索引中的+x-x设置。同时,100755根据需要更新存储在工作树中的 actual 模式。


1 很久以前,Git存储了更多位。原来这是一个错误并已更改,因此现在它仅存储644或755模式。 (前面的100644表示文件,其余的位是Linux样式的权限:644表示git checkout100表示rw-r--r-- 。)尽管有一些存储库,它们的内部 tree 对象的755行包含rwx-r-x-r-x,但是mode暗中允许一些额外的模式。 / p>


哪里出错了

如上所述,Git在运行100664(或git fsck(内部运行git init,更多或更多)时会检测实际文件系统减)。也就是说,Git正在创建一个 new 存储库。这个新的存储库需要知道:如果我在文件上设置了可执行位,操作系统会正确记住吗?

因此,Git实际上在操作系统提供的文件系统中设置或清除文件上的可执行位。 2 如果设置和/或清除“ sticks”,则Git知道操作系统正确处理了可执行位。

如果操作系统能够正确处理+ x和-x,则Git会将新存储库中的git clone设置为git init。如果不能正确处理+ x和-x,则Git会将新存储库中的core.filemode设置为true

稍后,Git将咨询 core.filemode,以了解操作系统的false在工作树上是否正确运行。 如果将存储库从一个文件系统移动到另一个文件系统,则记录的core.filemode可能不正确。在这种情况下,您可以手动调整chmod

如果某个同事或同事的文件系统不能正确处理core.filemode,并且该同事错误地摆弄了他或她的core.filemode,该同事将创建错误的chmod条目的新提交。 您对此无能为力(好,除了对他们进行教育外):提交一旦创建,就无法更改。您可以剔除错误的提交,并进行良好的替换(以其带来的所有痛苦),也可以只修复下一次提交中的模式而不必担心,但您必须让同事或同事工人停止这样做。

如果您有一个不会停止这样做的同事,而该权限与并不真正相关,则可以故意对自己的Git说谎。只需将core.filemode设置为mode即可忽略您自己操作系统正确跟踪的core.filemode设置。这不是一个很好的解决方案,只是一个变通办法,直到您可以教育将伪造的模式位放入存储库的人为止。


2 此文件是Git为新存储库构建的false文件。也可以在编译时禁用该测试:也就是说,某人可以构建一个假定且chmod 不起作用的Git,只需将chmod设置为.git/config

本文链接:https://www.f2er.com/2984566.html

大家都在问