GitLab本地部署环境下：推送至特性分支时自动修改文件内容、合并至Master分支时自动恢复的实现方案

我来给你分享几个针对本地GitLab场景的可行方案，完美解决你手动修改文件的繁琐操作——毕竟自动化才是效率王道嘛！

方案一：利用GitLab服务器端预接收钩子（pre-receive hook） #

这是最直接的服务器端解决方案，因为预接收钩子会在GitLab服务器接受推送内容之前运行，能直接修改推送的提交内容，完全符合你“仓库内文件被修改后让应用直接拉取使用”的需求。

操作步骤： #

1. 找到仓库的钩子目录：本地部署的GitLab，每个项目的钩子目录通常在/var/opt/gitlab/git-data/repositories/<你的命名空间>/<项目名>.git/hooks/（如果你的GitLab安装路径不同，可通过GitLab管理后台查看仓库存储路径）。
2. 创建pre-receive脚本：在上述目录下新建名为pre-receive的文件，添加以下逻辑（根据你的实际需求修改文件路径、分支规则和修改内容）：

#!/bin/bash

# 配置参数
TARGET_FILE="config/app-settings.json"  # 你需要修改的目标文件路径
FEATURE_BRANCH_PREFIX="feature/"        # 特性分支的前缀，比如feature/xxx
MASTER_BRANCH="master"                  # 主分支名

# 遍历推送的所有引用（分支/标签）
while read oldrev newrev refname; do
    branch=$(git rev-parse --symbolic --abbrev-ref "$refname")
    
    # 处理特性分支推送：自动修改目标文件
    if [[ "$branch" == "$FEATURE_BRANCH_PREFIX"* ]]; then
        # 临时检出推送的新提交
        git checkout -b temp-feature "$newrev"
        
        # 这里替换成你的具体修改逻辑，比如修改配置项
        sed -i 's/"env": "production"/"env": "test"/' "$TARGET_FILE"
        
        # 提交修改并覆盖原推送的提交
        git add "$TARGET_FILE"
        git commit --amend --no-edit --no-verify
        
        # 更新推送的引用到新的提交哈希
        new_feature_rev=$(git rev-parse temp-feature)
        git update-ref "$refname" "$new_feature_rev"
        
        # 清理临时分支
        git checkout -
        git branch -D temp-feature
    fi
    
    # 处理合并到Master的情况：自动恢复文件原始内容
    if [[ "$branch" == "$MASTER_BRANCH" ]]; then
        # 获取Master分支在推送前的原始文件内容
        git checkout "$MASTER_BRANCH"
        original_content=$(cat "$TARGET_FILE")
        
        # 检出推送的新Master提交
        git checkout -b temp-master "$newrev"
        
        # 恢复文件到原始内容
        echo "$original_content" > "$TARGET_FILE"
        
        # 提交恢复修改并更新Master分支
        git add "$TARGET_FILE"
        git commit --amend --no-edit --no-verify
        
        new_master_rev=$(git rev-parse temp-master)
        git update-ref "$refname" "$new_master_rev"
        
        # 清理临时分支
        git checkout -
        git branch -D temp-master
    fi
done

exit 0

3. 赋予脚本执行权限：运行chmod +x pre-receive，确保GitLab能执行这个钩子。
4. 测试验证：先在测试仓库推送一个特性分支，查看仓库内的目标文件是否被自动修改；再合并到Master，确认文件恢复原始内容。

注意点： #

• 脚本修改后无需重启GitLab，下次推送时会自动生效。
• 建议先在测试仓库验证逻辑，避免影响生产仓库数据。

方案二：基于GitLab CI/CD的自动化流程 #

如果不想操作服务器端钩子，也可以用GitLab自带的CI/CD来实现——通过分支触发不同的job，自动修改或恢复文件并推回仓库。

操作步骤： #

1. 配置CI权限：在GitLab项目的「设置」→「CI/CD」→「变量」中添加一个GITLAB_TOKEN变量，值为拥有仓库推送权限的个人访问令牌（PAT），勾选「保护变量」避免泄露。
2. 编写.gitlab-ci.yml：在项目根目录创建该文件，添加以下内容：

stages:
  - auto-modify
  - auto-restore

# 推送特性分支时自动修改文件
modify-feature-file:
  stage: auto-modify
  only:
    - /^feature\/.*$/  # 匹配所有feature/开头的分支
  except:
    - /CI: Auto modify/  # 避免CI自动提交触发无限循环
  script:
    - |
      # 配置Git用户信息（CI运行环境默认无配置）
      git config --global user.name "GitLab CI Bot"
      git config --global user.email "ci-bot@your-company.com"
      
      # 执行文件修改逻辑（替换成你的需求）
      sed -i 's/"env": "production"/"env": "test"/' config/app-settings.json
      
      # 提交并推回仓库
      git add config/app-settings.json
      git commit -m "[skip ci] CI: Auto modify file for feature branch"
      git push https://$GITLAB_TOKEN@your-gitlab-domain/<命名空间>/<项目名>.git HEAD:$CI_COMMIT_BRANCH

# 合并到Master时自动恢复文件
restore-master-file:
  stage: auto-restore
  only:
    - master
  except:
    - /CI: Auto restore/
  script:
    - |
      git config --global user.name "GitLab CI Bot"
      git config --global user.email "ci-bot@your-company.com"
      
      # 从远程Master分支拉取文件原始内容
      git fetch origin master:origin-master
      git checkout origin/master -- config/app-settings.json
      
      # 提交恢复并推回Master
      git add config/app-settings.json
      git commit -m "[skip ci] CI: Auto restore file to original for master"
      git push https://$GITLAB_TOKEN@your-gitlab-domain/<命名空间>/<项目名>.git HEAD:master

3. 测试触发：推送一个特性分支，查看CI是否自动运行并修改文件；合并到Master后确认CI自动恢复文件。

注意点： #

• 提交消息中加入[skip ci]是为了避免CI自动提交后再次触发流水线，防止无限循环。
• 确保GITLAB_TOKEN的权限仅包含仓库的推送权限，遵循最小权限原则。

额外提醒 #

不管选择哪种方案，都建议先在测试环境中完整验证流程：

1. 推送特性分支，确认文件修改生效；
2. 运行CI测试，确认应用能拉取到修改后的文件；
3. 合并到Master，确认文件恢复原始内容；
4. 检查Master分支的CI运行情况，确保应用拉取的是正确的原始文件。

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