755=rwxr-xr-x，644=rw-r--r--）-旧模式包括+x（可执行）标志，新模式没有。这个msysgit问题的回复建议将core.filemode设置为false以摆脱该问题。git config core.filemode false
git update-index --chmod=(+|-)x <path>。 - CB Baileygit config --global ... 命令在全局配置文件中设置选项。 - Ambergit config -l --show-origin 命令查看每个配置项的来源。 - Khouri Giordanocore.filemode为false是有效的，但请确保~/.gitconfig中的设置没有被.git/config中的设置覆盖。core.filemode设置的来源，请从存储库的根文件夹（或根文件夹下的任何文件夹）运行以下命令（适用于任何操作系统）：
git config --show-origin --show-scope --get-all core.filemode
git config --list --show-origin | sls filemode。如果您在Linux上，则需要使用以下命令：git config --list --show-origin | grep filemode。这将向您展示需要进行调整的位置。 - Frank Fucore.filemode 设置应该在每个 .git/config 中设置。每当 Git 创建一个新的仓库时，无论是 git clone 还是 git init，它都会根据您的操作系统和文件系统自动创建。它不应该出错，但如果出现问题，那么就需要在特定的仓库中进行设置修复。 - torek当仓库在Windows和Linux/Unix机器之间克隆时，通常会出现此问题。
只需告诉 Git 忽略文件模式更改即可。以下是几种方法：
仅为当前仓库设置：
git config core.filemode false
全局配置：
git config --global core.filemode false
在 ~/.gitconfig 中添加:
[core]
filemode = false
只需选择其中一个。
我在多次从旧硬盘复制带有工作文件的git仓库时遇到了这个问题。问题源于所有者和权限从旧驱动器/机器变更为新驱动器/机器。长话短说，运行以下命令来解决问题(感谢这个超级用户的回答):
sudo chmod -R -x . # remove the executable bit from all files
先前的命令会实际解决git diff报告的差异，但会取消您列出目录的权限，因此ls ./将失败并显示ls: .: Permission denied。要解决这个问题:
sudo chmod -R +X . # add the executable bit only for directories
不好的消息是，如果您有任何想要保留可执行文件的文件，例如.sh脚本，您需要还原这些文件。您可以为每个文件使用以下命令来执行此操作：
坏的消息是，如果您有任何要保持可执行状态的文件（例如 .sh 脚本），那么您将需要将它们还原回去。您可以使用以下命令对每个文件进行操作:
chmod +x ./build.sh # where build.sh is the file you want to make executable again
git config core.filemode 是否设置为 true，否则权限更改将不会被检测到。每次更改后，我还需要刷新 git 索引以使更改生效。 - pat-s我曾面临同样的问题。这个方法救了我的命：
这将把所有权限还原到所做更改前的状态，因此你将仅保留文件的更改。
https://gist.github.com/jtdp/5443498
git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never \
| git apply
这对我有用：
git ls-files -m | xargs -L 1 chmod 644
将 git config core.filemode false 设置为接受的答案确实可行，但会带来一些后果。将 core.filemode 设置为 false 告诉 git 忽略文件系统上任何可执行位的更改，因此它不会将其视为变更。如果您在将来的某个时间需要为此存储库暂存可执行位更改，则必须手动执行或将 core.filemode 设置回 true。
如果所有修改后的文件都应具有模式 100755，则可选择较小的替代方案，例如执行以下操作：
chmod 100755 $(git ls-files --modified)
这只是简单地更改模式，没有其他含义或影响。
（在我的情况下，因为 OneDrive 在我的 MacOS 文件系统上进行同步导致了这个问题；如果不更改 core.filemode，那么将来可能会再次出现模式更改的情况；对我而言，如果它再次出现，我想知道，而更改 core.filemode 将隐藏它，这不是我想要的）
这个解决方案将把git文件权限从100755更改为100644，并将更改推送回bitbucket远程仓库。
查看您的Repo文件权限：git ls-files --stage
如果是100755，而你想要100644
那么运行这个命令：
git ls-files --stage | sed 's/\t/ /g' | cut -d' ' -f4 | xargs git update-index --chmod=-x
现在再次检查您的Repo文件权限：git ls-files --stage
现在提交您的更改：
git status
git commit -m "恢复适当的文件权限"
git push
当你拉取代码时，如果所有文件在远程仓库中都是可执行的，这种情况就会出现。重新让这些文件可执行就能恢复正常了。
chmod +x <yourfile> //For one file
chmod +x folder/* // For files in a folder
您可能需要执行以下操作：
chmod -x <file> // Removes execute bit
相反，对于未设置为可执行文件并因上述操作而更改的文件，有更好的方法来解决此问题。但这只是一个非常快速和简单的临时解决方案。
看起来您更改了某个目录的权限。我执行了以下步骤来恢复它。
$ git diff > backup-diff.txt ### in case you have some other code changes
$ git checkout .
core.filemode的全部细节，请参见我的答案。请注意，每个Git存储库都应该有自己的core.filemode设置，在Git创建该存储库时由Git设置；该设置应该是该存储库的正确设置。如果由于某种原因它是错误的，您可以更改它。 - torek