同一个开源项目需要同时维护 GitHub 和 Gitee 仓库时，可以在本地配置多个远端，也可以给一个远端设置多个推送地址。选择哪种方式，主要取决于是否需要分别观察两个仓库的状态。
保留两个独立远端
下面假设 GitHub 是已有的 origin，并以 master 为示例分支；实际操作请使用自己的当前分支。
git remote -v
git remote add gitee git@gitee.com:enilu/material-admin.git
git push origin master
git push gitee master
独立远端便于分别 fetch、检查分支与重试。认证可以通过 SSH key 或凭据管理器处理，不要把密码或访问令牌写进仓库 URL，避免出现在配置、命令历史和日志里。
-u 用来设置当前分支的上游关系，不需要每次推送都加。一个分支通常保留一个明确上游，另一个远端显式推送即可。
给 origin 配置多个 push URL
如果日常总要推送到两边，可以明确配置推送地址，取回代码的 fetch URL 则保持单一来源：
git remote set-url --add --push origin git@github.com:enilu/material-admin.git
git remote set-url --add --push origin git@gitee.com:enilu/material-admin.git
git remote get-url --all --push origin
git push origin master
这组命令假设此前没有自定义 push URL。已有配置先查询，避免重复添加。设置了 push URL 后，应该把所有希望推送到的目标都列进去，不能假定 fetch URL 仍会额外作为推送目标。
多处推送不是一个事务
一个目标成功、另一个失败时，不会自动撤回已成功的推送。应保留成功结果，确认失败原因后只重试缺失目标，不能用强制推送掩盖分支分歧。
两个平台若都接受独立提交，后续就可能分叉。最好指定主要协作仓库，明确合并和同步方向。标签需要按发布流程另行推送；代码提交也不等于覆盖平台上的 issue、附件、权限和其他元数据。
多远端减少了同步操作，但仍需要检查每个目标的返回结果，不能因为命令已经执行就认定所有仓库一致。
参考：git remote、git push。