文章目录
- 1. 简介
- 2. 格式
- 3. 选项
- 4. 示例
- 4.1 基础用法
- 4.2 推送并建立关联（首次推送推荐）
- 4.3 推送到不同名称的远程分支
- 4.4 删除远程分支
- 4.5 强制推送（谨慎使用）
- 4.6 推送所有分支和标签
- 5. 注意
- 5.1 首次推送必须建立关联
- 5.2 强制推送的风险
- 5.3 推送被拒绝的常见原因
- 5.4 常用别名设置
- 6. 小结
- 参考文献
1. 简介
git push用于将本地仓库的提交推送到远程仓库。
简单来说：git push把你本地提交的代码上传到远程服务器（如 GitHub、GitLab）。
# 基本对应关系gitpush=gitpush origin HEAD# 将当前分支推送到远程的同名分支2. 格式
gitpush[<options>][<repository>[<refspec>]]如果命令行没有<repository>指定推送的远程仓库，则会采用branch.*.remote配置。如果缺少配置，则默认为origin。
如果命令行没有<refspec>指定引用规格，取决于push.default配置。
push.default值 | 行为 | 示例（当前分支为main） |
|---|---|---|
simple（默认） | 推送当前分支到远程同名分支，且要求两者已关联 | git push origin main |
current | 推送当前分支到远程同名分支（不要求关联） | git push origin main |
matching | 推送所有有同名远程分支的本地分支 | 推送main、dev、feature等 |
upstream | 推送到当前分支的上游分支（需已设置--set-upstream） | 推送到已关联的远程分支 |
nothing | 不推送任何东西，必须显式指定 | 必须写git push origin main |
3. 选项
-d,--delete所有列出的引用都会从远程仓库中删除。这相当于将所有引用前加上冒号。 -u, --set-upstream 推送并建立本地分支与远程分支的关联（之后可直接用`gitpush`） -f,--force强制推送（覆盖远程分支，⚠️ 慎用） --force-with-lease 更安全的强制推送（若远程分支有新提交则拒绝） --all,--branches推送所有本地分支（即 refs/heads/ 下的 refs）；不能与其他<refspec>一起使用。--tags推送所有标签--delete删除远程分支 -v,--verbose显示详细信息 -n, --dry-run 模拟执行，显示将要推送的内容，但不实际推送4. 示例
4.1 基础用法
基础用法是最常见的推送场景，适用于日常开发中的代码同步。
# 将当前分支推送到 origin 的同名远程分支gitpush origin HEAD# 解释：HEAD 指向当前检出的分支，这个命令会将当前分支推送到远程的同名分支# 将本地 main 分支推送到远程 main 分支gitpush origin main# 解释：明确指定本地分支和远程分支名称，适合需要精确控制的场景使用场景：
- 日常开发完成后，将本地提交推送到远程仓库
- 团队协作时同步代码变更
- 持续集成/持续部署流程中的代码推送
注意事项：
- 确保远程仓库有对应的分支（首次推送需要建立关联）
- 推送前建议先执行
git pull拉取最新代码，避免冲突 - 如果远程分支有新的提交，可能需要先合并或变基
4.2 推送并建立关联（首次推送推荐）
首次推送本地分支到远程时，建立上游关联可以简化后续操作。
# 推送并设置 upstream，之后可直接用 git pushgitpush-u|--set-upstream origin main参数说明：
-u或--set-upstream：设置上游分支关联origin：远程仓库名称（默认远程仓库）main：本地分支名称
建立关联后的好处：
- 简化命令：之后只需输入
git push即可推送，无需指定远程和分支 - 自动跟踪：Git 会记住这个关联关系
- 状态显示：
git status会显示本地分支与远程分支的对比状态
适用场景：
- 创建新分支后的首次推送
- 从其他仓库克隆后创建新分支
- 需要简化工作流程的日常开发
4.3 推送到不同名称的远程分支
有时需要将本地分支推送到远程的不同名称分支，这在多环境部署或特定工作流中很有用。
# 将本地 feature 分支推送到远程 dev 分支gitpush origin feature:dev语法解析：
feature:dev：冒号前是本地分支，冒号后是远程分支- 这个命令不会建立上游关联，每次都需要完整命令
使用场景：
- 环境部署：将开发分支推送到测试环境分支
- 代码审查：将功能分支推送到特定的审查分支
- 备份目的：将本地分支推送到备份分支
- 多团队协作：不同团队使用不同的分支命名规范
示例扩展：
# 将本地 develop 分支推送到远程 staging 分支gitpush origin develop:staging# 将本地 hotfix 分支推送到远程 production 分支gitpush origin hotfix:production4.4 删除远程分支
清理不再需要的远程分支是仓库维护的重要部分。
# 删除远程的 feature 分支gitpush origin-d|--deletefeature# 或使用更简洁的语法gitpush origin :feature如果误删了远程分支，可以通过本地分支重新推送：
# 假设本地还有该分支gitpush origin feature4.5 强制推送（谨慎使用）
强制推送会覆盖远程历史，必须谨慎使用。
# 强制覆盖远程分支（⚠️ 会丢失远程上的提交）gitpush--forceorigin main# 更安全的强制推送（如果远程有新提交则拒绝）gitpush --force-with-lease origin main4.6 推送所有分支和标签
批量推送操作适用于特定场景。
# 推送所有本地分支，如果远程不存在对应分支，会自动创建gitpush--allorigin# 推送所有标签（谨慎使用，可能包含临时标签）gitpush--tags标签推送的最佳实践：
# 推送单个标签gitpush origin v1.0.0# 删除远程标签gitpush origin--deletetag v1.0.05. 注意
5.1 首次推送必须建立关联
# 首次推送（设置 upstream）gitpush-uorigin main# 之后可以直接用gitpush5.2 强制推送的风险
| 场景 | 风险 | 建议 |
|---|---|---|
| 多人协作的公共分支 | ⚠️ 会覆盖他人的提交 | 禁止使用--force |
| 个人开发分支（未共享） | ✅ 可以 | 可用--force-with-lease更安全 |
| 重写历史（如 rebase）后 | 必须使用--force | 先确认没有其他人基于此分支开发 |
5.3 推送被拒绝的常见原因
| 错误信息 | 原因 | 解决方法 |
|---|---|---|
failed to push | 远程有新提交 | git pull --rebase后重新推送 |
rejected | 权限不足 | 检查仓库权限或 SSH Key |
protected branch | 分支受保护 | 通过 Pull Request 合并 |
5.4 常用别名设置
gitconfig--globalalias.pu"push -u"gitconfig--globalalias.pf"push --force-with-lease"# 使用别名gitpu origin maingitpf origin main6. 小结
| 需求 | 命令 | 说明 |
|---|---|---|
| 首次推送并建立关联 | git push -u origin main | 之后可直接用git push |
| 日常推送 | git push origin main | 推送到远程同名分支 |
| 推送并变基后强制推送 | git push --force-with-lease origin main | 更安全的强制推送 |
| 删除远程分支 | git push origin --delete feature | 删除远程分支 |
| 推送所有分支 | git push --all origin | 推送所有本地分支 |
| 模拟执行（预览） | git push --dry-run origin main | 查看将要推送的内容 |
一句话总结：git push是分享代码的命令，首次推送用-u建立关联。强制推送（-f）要极度谨慎，优先使用--force-with-lease。推送前建议先用git pull --rebase同步远程更新，避免推送被拒绝。**
参考文献
Git - git-push Documentation
