Question

不确定为什么会发生这种情况，但是问题是我在将该分支推送到远程之后更改了该分支的文件权限。然后，我从集成分支中签出一个新分支，它具有“死分支”的权限，方法如下：

# on feature branch
git checkout --no-track -b foo
git reset --soft "remotes/origin/dev"
git add .
git add -A
git commit --allow-empty -am "bar"
git push -u origin foo
chmod -R -w .  # remove all write permissions in current dir

# later on
git branch --no-track z "remotes/origin/dev"
git checkout z
### ughh this new branch z files are not writable, but whyyyy?

基本上，我们将文件更改为不可写，并且该分支永远不会合并到任何分支-我们在修改文件权限之前将其推送到远程。

为什么不可写文件权限显示在从未与不可写文件分支合并的其他分支中？

Answer 1

Git关心和存储的每个文件的唯一权限是“可执行或不可执行”权限。 这种chmod行为的TL; DR是“不要这样做”，为此，请使用单独的克隆或单独的工作树。有关更多详细信息，请继续阅读。

具体来说，在每个提交快照中，每个文件（实际上是 blob ）都被标记为模式100644（不是可执行文件）或100755（可执行文件）。您可以在git ls-tree输出中看到这一点，就像在任何现有提交上运行时一样。所有其他权限（包括读取或写入的权限）由您决定。在Unix和类似Unix的系统上，当Git创建工作树文件时，它实际上使用0777模式（如果文件是可执行文件）或0666模式（如果不是）。您的 umask 会从其中剥离任何不需要的权限；典型的umask值为022（删除组和其他写许可权）或002（仅删除非组/其他写许可权），但是安全子系统可以使用077（删除所有组和其他写许可权）。其他权限）。

请注意，Git确实能够保持内部存储库数据组可写，但是它们不是工作树文件：这些文件主要影响Git存储松散和打包对象的目录。值等。这些由core.sharedRepository设置控制；参见the git config documentation。（请记住，在目录中创建和删除文件的能力取决于当前用户和组ID在目录本身上写入的权限。嗯，也就是说，除非涉及到ACL，否则它将变得非常复杂。）

在使用git checkout从一个提交切换到另一个提交时，Git仅根据需要删除并替换工作树文件。需求主要由 index 内容确定，索引索引工作树。这解释了为什么保留部分而非全部文件权限的原因。有关此的更多信息，请参见Checkout another branch when there are uncommitted changes on the current branch。

文件权限在git分支之间共享

1 个答案: