如何在Git中防止其他贡献者修改指定个人目录文件？

这套方案针对防误操作的软限制需求设计，不做硬权限封锁，满足所有人可查看全仓库内容、仅可正常提交自身目录变更的要求，实现成本低，不会阻塞特殊场景下的协同操作。

本地第一层拦截：pre-commit提交钩子 #

从本地提交环节就拦住误修改，不用等推到服务端才发现问题，每个用户本地配置一次即可：

• 克隆仓库后，进入本地仓库的.git/hooks/目录，新建名为pre-commit的文件
• 将下面的脚本内容写入文件，把USER_DIR变量的值改成你自己的个人目录名，比如你的目录是/personA就填personA

#!/bin/sh
USER_DIR="personA"
CHANGED_FILES=$(git diff --cached --name-only)

for file in $CHANGED_FILES; do
  if echo "$file" | grep -q "^person[^/]*\/" && ! echo "$file" | grep -q "^${USER_DIR}\/"; then
    echo "提交拦截：你修改了其他用户的个人目录内容，请撤回对应修改后再提交"
    echo "异常文件路径：$file"
    exit 1
  fi
done
exit 0

• 给钩子文件加执行权限，在终端执行chmod +x .git/hooks/pre-commit

配置完成后，只要暂存区里有其他个人目录的修改，提交时就会直接被拦截，从源头避免误提交。如果确实有特殊需要修改他人目录，提交时加--no-verify参数就能临时跳过检查。

服务端兜底拦截：pre-receive推送钩子 #

如果怕有人本地跳过钩子误推，可以在仓库服务端配置全局的pre-receive钩子，所有推送请求都会经过检查，不需要每个用户单独配置：

• 登录Git服务所在的服务器，进入对应仓库的hooks目录（裸仓库路径一般是xxx.git/hooks/）
• 新建pre-receive文件，写入以下脚本：

#!/bin/sh
while read oldrev newrev refname; do
  # 跳过删除分支的请求
  if [ "$newrev" = "0000000000000000000000000000000000000000" ]; then
    continue
  fi
  # 遍历本次推送的所有提交
  for commit in $(git rev-list $oldrev..$newrev); do
    COMMIT_AUTHOR=$(git log -1 --format=%an $commit)
    COMMIT_FILES=$(git diff-tree --no-commit-id --name-only -r $commit)
    for file in $COMMIT_FILES; do
      # 匹配个人目录下的文件
      if echo "$file" | grep -q "^person[^/]*\/"; then
        DIR_OWNER=$(echo "$file" | cut -d'/' -f1)
        if [ "$COMMIT_AUTHOR" != "$DIR_OWNER" ]; then
          echo "推送拦截：提交 $commit 作者为 $COMMIT_AUTHOR，却修改了 $DIR_OWNER 名下的目录文件 $file"
          echo "若需协同修改他人目录，请联系仓库管理员走例外合并流程"
          exit 1
        fi
      fi
    done
  done
done
exit 0

• 同样给文件加执行权限chmod +x pre-receive

注意：使用这个钩子需要要求所有贡献者把本地Git的提交用户名（git config user.name）设置成和自己的个人目录名完全一致，否则会触发误拦截。

可选增强：本地工作区他人目录只读 #

如果想从编辑环节就避免手滑改到别人的文件，可以直接把本地其他用户的个人目录设为只读：

• Linux/macOS下在仓库根目录执行命令，把命令里的目录名换成其他贡献者的目录即可：
  chmod -R a-w personB/ personC/
• Windows下右键其他用户的个人目录，打开属性面板勾选「只读」保存即可。

设置后打开他人目录下的文件时，编辑器会直接提示文件不可写，从最前端避免误修改。

不建议配置pull时自动覆盖他人目录修改的逻辑，这种操作很容易冲掉仓库里其他人正常提交的更新，破坏提交历史，前面三层防护已经足够覆盖绝大多数误操作场景，同时保留了特殊场景下协同修改的灵活性。

内容的提问来源于stack exchange，提问作者Gere