不知道为什么会发生这种情况，但问题是我将分支推送到远程后，我正在更改该分支上的文件权限。然后我从我们的集成分支中签出一个新分支，它具有"死分支"的权限，它是这样的：
# 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?
基本上，我们将文件更改为不可写，并且该分支永远不会合并到任何分支中 - 我们在修改文件权限之前将其推送到远程。
为什么不可写文件权限显示在从未与不可写文件分支合并的其他分支中？
Git 关心并为每个文件存储的唯一权限是"是或不可执行"权限。The TL;chmod 的这种行为的 DR 是"不要那样做"——为此使用单独的克隆或单独的工作树。有关更多详细信息，请继续阅读。
具体而言，在每个提交快照中，每个文件(或blob，实际上是(都标记为模式100644(不可执行(或100755(可执行文件(。 您将git ls-tree输出中看到这一点，就像在任何现有提交上运行一样。所有其他权限(包括读取或写入能力(均由您决定。 在 Unix 和类 Unix 系统上，当 Git 创建工作树文件时，它实际上使用模式0777(如果文件是可执行的(或0666模式(如果不是(。 您的掩码会从这些权限中删除任何不需要的权限;典型的 UMASK 值是022(删除组和其他写入权限(或002(仅删除非组/其他写入权限(，但安全子系统可能会使用077(删除所有组和其他权限(。
请注意，Git 确实能够保持内部存储库数据组可写，但这些文件不是工作树文件：这些文件主要影响 Git 存储松散和打包对象、引用值等的目录。 这些由core.sharedRepository设置控制;请参阅git config文档。 (请记住，在目录中创建和删除文件的能力取决于当前用户和组 ID 在目录本身上写入的权限。 好吧，也就是说，除非您涉及 ACL;然后它变得非常复杂。
使用git checkout从一个提交切换到另一个提交时，Git 仅根据需要删除和替换工作树文件。 这种需求在很大程度上取决于索引内容，索引索引工作树。 这就解释了为什么某些(但不是全部(文件权限最终会被保留。 有关此内容的详细信息，请参阅当当前分支上有未提交的更改时签出另一个分支。