Bash脚本执行git子模块添加时内联credential.helper失效导致认证失败

密码中包含感叹号（!）是导致脚本场景认证失败的极高概率诱因，结合手动执行正常、脚本内单独校验账号密码、工作路径、用户信息均无误的现象，可按以下顺序逐点排查：

• 优先验证shell特殊字符解析对凭证值的破坏作用
  手动交互终端执行时，shell的历史扩展规则、引号配对逻辑和非交互Bash脚本环境存在明显区别：哪怕你单独echo $password能输出正确的密码值，只要你把带密码的字符串嵌套进git -c credential.helper=...的多层单引号结构里，非交互环境下可能因为转义规则不一致，导致实际传给git子shell的凭证值出现截断、错配——比如密码里的!如果触发了历史扩展逻辑，会被替换成终端历史记录里的命令片段，最终凭证值完全失真；因为这个替换发生在git调用helper的子shell语境下，你提前做的密码输出校验根本发现不了问题。
• 用调试模式抓取真实执行的命令参数
  在脚本中对应报错命令的前一行加上set -x，运行脚本后看终端打印的真实git执行语句，重点核对credential.helper参数的实际解析结果：很多时候你以为传的是完整的内联凭证函数，实际因为引号配对错位，函数体被拆成了零散参数，git拿到的根本不是可正常返回凭证的helper程序，只会笼统报认证失败。
• 补做凭证传递链路的端到端校验
  临时修改内联的credential helper函数，在函数最开头加一行日志输出，把实际拿到的用户名、密码写到临时文件里：

  git -c credential.helper='!f() { echo "DEBUG: user=$username pass=$password" > /tmp/cred_debug.log; echo username=$username; echo password=$password; }; f' submodule add "https://<某Git仓库>/common.git"
  

  运行命令后查看/tmp/cred_debug.log的内容，和你预期的凭证值做逐字符对比——很多时候因为外层单引号包裹的原因，$username、$password变量根本没有被主脚本提前展开，直接被原样传入git拉起的子shell，子shell里没有定义这两个变量，最终返回空凭证导致认证失败。
• 核对脚本运行环境的Git版本差异
  手动执行时调用的Git程序，和脚本运行时因为PATH优先级不同加载的Git版本，有可能存在credential helper执行逻辑的版本差异，在脚本中增加git --version的输出，和手动执行的版本做交叉对比，排除旧版本Git对子shell凭证传递的兼容问题。

为什么手动执行正常：交互终端输入整行命令时，shell对引号嵌套、特殊字符转义、变量展开的处理顺序是逐字符实时解析的，刚好能匹配你写的命令的预期逻辑；脚本非交互运行时，shell会先对整个脚本做一次性的语法解析、变量预展开，多层嵌套的引号结构很容易出现配对错位，最终传给git的参数和你手动输入的根本不是同一个内容。

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