git不支持默认一键推多仓，但可通过单remote配多个pushurl实现真正多推；独立remote需显式指定推送目标，而多pushurl方式一次push origin即同步至所有配置地址。

直接推送到多个远程仓库不是 Git 默认行为，但完全可行——关键在于配置方式和推送命令的选择。用错方法会导致只推到一个、漏推、或后续 git push 失效。

git remote add 添加多个独立远程名

这是最清晰、最可控的方式，适合日常开发中主仓（如 GitHub）+ 备份仓（如 Gitee）的场景。

• 每个远程仓库有唯一名称，比如 origin（GitHub）、gitee（Gitee）、backup（GitLab）
• 添加命令必须带新名字：git remote add gitee https://gitee.com/user/repo.git
• 不能重复使用 origin；否则会报错 fatal: remote origin already exists.
• 推送时需显式指定目标：git push origin main 和 git push gitee main 要分开执行
• 好处是 fetch/push 地址分离明确，分支策略可独立控制（比如只向 gitee 推 main，不推 dev）

git remote set-url --add --push 合并推送目标

把多个推送地址“塞进”同一个远程名（通常是 origin），让一次 git push origin 自动发往所有配置的 push URL。

Lovefromio Github

使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。

下载

• 先确认已有 origin：git remote -v 应显示一条 fetch 和一条 push 地址
• 追加第二个 push 地址：git remote set-url --add --push origin https://gitee.com/user/repo.git
• 再执行 git remote -v，你会看到 origin 对应两条 (push) 行
• 注意：fetch 地址不会变，仍只从第一个 URL 拉取；只有 push 会多发
• 风险点：如果某个 push URL 失败（如网络不通、权限不足），整个 git push origin 就会中断，不会“尽力而为”

git config --add remote.origin.pushurl 手动写配置

本质和上一种方法一样，只是绕过 git remote 命令，直接操作 .git/config 文件。

• 等价命令：git config --add remote.origin.pushurl https://gitee.com/user/repo.git
• 执行后可在 .git/config 中看到多个 pushurl = ... 行（同一 section 下）
• 比 set-url --add --push 更底层，也更易误配（比如漏写 --add 导致覆盖而非追加）
• 不推荐新手手动编辑 .git/config，容易格式错乱导致 Git 报错 fatal: bad config line ...
• 适合脚本化批量配置，或 CI/CD 中动态注入备份地址

推送时容易忽略的分支跟踪问题

用 -u 设置上游只对当前推送的远程生效，多个远程之间不共享 upstream 信息。

• git push -u origin main 只设置本地 main 跟踪 origin/main
• 再执行 git push -u gitee main，会报错 fatal: The current branch main has no upstream branch. —— 因为 upstream 已被占用
• 想同时跟踪两个远程？不行。Git 不支持一个本地分支对应多个 upstream
• 所以日常建议：只对主远程（如 origin）用 -u；其他远程始终显式写全命令，避免歧义
• 后续同步时，git pull 默认只拉 origin，git push 默认只推 origin，别指望它自动覆盖所有远程

真正麻烦的不是加远程，而是推送失败后的状态恢复——比如向 gitee 推送因网络超时中断，而 origin 已成功，这时两个远程的 main 分支就不同步了。手动修复前，务必先 git fetch 确认各自 HEAD，再决定是重推、合并还是 reset。