不确定为什么会发生这种情况，但问题是我将分支推送到远程后我正在更改分支上的文件权限。然后我从我们的集成分支中检出一个新的分支，它具有“死分支”的权限，这就是它的方式：
# 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关心和存储每个文件的唯一权限是“是或不可执行”权限。 TL;对于chmod的这种行为的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仅根据需要删除并替换工作树文件。这种需求在很大程度上取决于索引内容，索引索引工作树。这解释了为什么一些（但不是全部）文件权限最终被保留。有关这方面的更多信息，请参阅Checkout another branch when there are uncommitted changes on the current branch。