日常开发里，Git 工具的问题经常不是不会 commit，而是卡在网络、认证和仓库归属上：GitHub 打不开、SSH key 不生效、HTTPS push 卡住、私有仓库不知道放哪里、镜像仓库和主仓库来回混用。把这些问题拆开看，会比临时换命令更稳。
先分清三件事
Git 本身只负责版本管理，GitHub、Gitee、GitLab 这类平台负责远端托管，代理和 SSH 配置负责连接通道。排障时不要把它们混在一起。
- 本地 Git：分支、提交、rebase、stash、tag、ignore。
- 远端平台：仓库权限、组织、私有仓库、Webhook、CI。
- 网络通道：HTTPS、SSH、代理、DNS、公司网络策略。
如果 git status、git log 都正常，问题大概率不在 Git 本体；如果 git ls-remote 都卡住，优先看网络和认证；如果能拉不能推，再看远端权限和 protected branch。
HTTPS 和 SSH 怎么选
HTTPS 好处是配置简单，很多平台文档默认也先给 HTTPS 地址。缺点是遇到代理、凭据缓存、双因素认证时容易卡在 credential helper 上。
SSH 的好处是认证稳定，适合长期私有仓库和多台机器。缺点是第一次要配置 key，并确认平台已经绑定公钥。
个人长期开发建议：
- 常用私有仓库优先 SSH。
- 临时 clone 开源项目可以用 HTTPS。
- 在代理环境里，先用
git ls-remote测远端连通，再执行大体积 push。 - 同一个仓库不要频繁切换 URL，除非正在排障。
查看远端地址：
git remote -v切换到 SSH：
git remote set-url origin [email protected]:OWNER/REPO.git代理环境下先做只读测试
如果网络不稳定，不要一上来就 git push。先跑只读命令：
git ls-remote --heads origin main这条命令能快速判断 DNS、代理、认证和远端仓库是否可达。只读能通，再推送；只读都不通，先换代理或检查 SSH key。
对于大文件或大量对象的 push，如果 HTTPS 卡在 POST git-receive-pack，可以尝试 SSH 通道。SSH 能看到 Writing objects 和 remote: Resolving deltas，更容易判断是真在上传，还是卡在连接层。
私有仓库和镜像仓库的边界
自用项目建议有一个主远端，其他镜像只作为备份或发布渠道。主远端负责真实历史，镜像仓库负责同步，不要让两个仓库都承担读写主线，否则很容易出现分支分叉。
一个简单规则是：
origin指向主仓库。- 备份远端命名为
backup或平台名。 - 日常只 push
origin。 - 真要同步镜像时，明确执行
git push backup main。
这样排障时也能少问一句“到底哪个仓库才是真的”。
提交前后怎么检查
提交前：
git status --short
git diff --check提交后：
git log -1 --oneline
git status --short --branch推送后再确认：
git fetch origin main
git status --short --branch如果本地显示 ahead N，说明本地还有提交没有进入 origin/main；如果没有 ahead/behind，只剩工作区未提交改动，那就是远端同步已经完成，剩下的是本地未提交文件。
最后抓住一句话
GitHub 和 Git 服务工具的核心不是记住更多命令，而是把“版本历史、远端权限、网络通道”分开排查。先确认本地提交，再确认远端连通，最后确认 push 是否更新了目标分支，很多卡住的问题就不会变成玄学。
