Git 重复认证问题
问题现象
在 Debian/Linux 系统中通过 HTTPS 拉取 GitLab（或 GitHub）项目时，第一次 git pull 输入了账号密码，第二次拉取仍然要求输入密码。第一次的鉴权信息没有保存吗？
原因分析
第一次输入密码后，Git 默认并不会自动保存它——Git 本身没有内置的、永久性的密码存储功能。
当通过 HTTPS 协议拉取代码时，每次操作都需要验证身份。如果没有配置凭据助手（Credential Helpers），Git 找不到存储的密码，就只能每次都提示你输入。
对比：Windows 下的 Git for Windows 安装时默认集成了 Git Credential Manager（GCM），所以感觉"自动记住密码"。详见下文 Windows 下的行为。
解决方案：配置凭据助手
方案一：临时缓存密码（cache）——推荐用于个人电脑
将密码在内存中缓存一段时间（默认 900 秒即 15 分钟），超时后需重新输入。优点是密码不会明文保存在硬盘上。
# 配置默认缓存 900 秒（15 分钟）
git config --global credential.helper cache
# 配置缓存 1 小时（3600 秒）
git config --global credential.helper 'cache --timeout=3600'
方案二：永久存储密码（store）——适用于服务器等可信环境
将用户名和密码（或 Token）以明文形式永久保存在 ~/.git-credentials 文件中，注意安全风险。
git config --global credential.helper store
配置完成后，执行一次 git pull 或 git push，输入用户名和密码，Git 就会将其保存，之后不再需要重复输入。
方案三（更推荐）：使用 Personal Access Token（PAT）
对于 GitLab 等平台，更安全的做法是使用**个人访问令牌（Personal Access Token）**代替密码：
- 在 GitLab 网站上生成一个 Token
- 第一次
git pull或git push时，用户名输入 GitLab 用户名，密码处粘贴这个 Token - 配合上面配置的
cache或store助手，Token 就会被缓存或存储下来
另一种免密方式是改用 SSH 协议，配置方法见 Debian 配置 GitHub 的 SSH 连接。
常见问题排查
如果配置后依然不生效，检查以下几点：
1. 检查配置是否生效
git config --list | grep credential.helper
确认输出是你刚刚设置的值。
2. 检查是否存在多个配置冲突
系统级、全局级或项目级的配置可能不一致，分别检查：
# 系统级
git config --system --list | grep credential
# 全局级
git config --global --list | grep credential
# 项目级（需在仓库目录下执行）
git config --local --list | grep credential
如果发现多个，移除多余的只保留一个。例如移除全局配置：
git config --global --unset credential.helper
3. 文件权限问题（针对 store 模式）
确保 ~/.git-credentials 文件权限为 600（仅用户可读写）：
chmod 600 ~/.git-credentials
Windows 下的行为
Windows 下不需要手动配置——新版 Git for Windows（v2.29 及以上）安装时默认勾选安装 Git Credential Manager（GCM），并在全局配置 .gitconfig 中自动设置它作为凭据助手。
验证 GCM 是否生效
git config --global credential.helper
输出 manager 或 manager-core 说明 GCM 已正常工作。
工作原理
第一次通过 HTTPS 操作 Git（如 clone、pull）时，GCM 弹出 Windows 身份验证对话框，成功输入一次凭据后，GCM 将其安全存储在 Windows 凭据管理器中，之后所有 Git 操作自动获取凭据，不再重复输入。
如果 Git 版本较旧没有自动安装 GCM，需要手动升级或单独安装。