代码在本地仓库里改好了，但远程仓库那边纹丝不动？这确实是团队协作中一个常见的“断点”。

你的改动如果只停留在本地，团队成员是看不到也无法集成的。别担心，把本地提交同步到远程仓库，方法其实很灵活。

下面就来梳理几种最常用的操作路径，你可以根据实际场景对号入座。

一、基础推送：指定远程主机与分支

这是最直接、也最能体现控制意图的方法。当你需要明确指定将代码推送到哪个远程仓库的哪个分支时，它就派上用场了。

整个过程清晰明了，一步到位。

操作步骤如下：

• 添加远程仓库：如果还没配置，执行 git remote add origin <远程仓库URL>。
• 验证配置：运行 git remote -v，确认 `origin` 指向你的目标仓库。
• 执行推送：输入 git push origin main，将本地 `main` 分支推送到远程同名分支。

二、简化推送：仅使用远程主机名

如果你已经为本地分支建立了追踪关系，那么每次推送都打一长串分支名就显得有点啰嗦了。

这时候，可以试试更简洁的写法。

操作步骤如下：

• 切换到目标分支：例如 git checkout main 或 git switch main。
• 执行简化推送：直接运行 git push origin。Git 会根据当前分支的追踪关系，自动找到对应的上游远程分支进行推送。

这不仅能减少输入，也降低了因手误输错分支名的概率。

三、首次推送并设置上游分支

当你新建了一个本地分支，并且打算把它推送到远程仓库长期维护时，这个方法就非常高效。

它能在推送的同时，建立起本地分支与远程分支的“绑定”关系。

操作步骤如下：

• 切换到新分支：例如 git checkout feature/login。
• 推送并建立关联：执行 git push -u origin feature/login。这里的 `-u` 参数（`--set-upstream` 的简写）就是用来建立追踪关系的。
• 验证关联：运行 git branch -vv，在分支列表里，你就能看到它关联的远程追踪分支信息。

这样一来，以后在这个分支上，直接执行 `git push` 或 `git pull` 就不用再指定远程和分支了，省心不少。

四、强制推送覆盖远程历史

这是一个需要谨慎使用的“强力工具”。

什么情况下会用到它呢？比如，你在本地用 `git rebase` 整理了提交历史，或者用 `git commit --amend` 修改了最新的提交。这些操作本质上重写了提交历史，导致你的本地分支和远程分支的历史走向出现了分叉。

当你尝试常规推送时，Git 会友好地拒绝，并提示 `non-fast-forward` 错误。这意思是，你的推送无法通过“快进”的方式合并。

这时，就需要强制推送了：

• 使用命令 git push --force origin main。这个命令会用你的本地分支历史，直接覆盖掉远程分支的历史。

重要提醒：

强制推送有风险，尤其是在多人协作的分支上，可能会覆盖掉别人已经推上去的新提交。

因此，一个更安全的替代方案是使用 git push --force-with-lease origin main。这个命令会先检查远程分支是否在你上次拉取之后有更新，如果没有，才执行强制推送，相当于加了一把安全锁。

五、推送所有本地分支

有时候，你可能想一次性把所有本地分支都推送到远程仓库。

比如在初始化一个协作环境，或者需要批量同步多个功能分支的时候。

操作步骤如下：

• 查看本地分支：先运行 git branch 确认一下有哪些本地分支。
• 推送所有分支：执行 git push --all origin。所有本地分支都会被推送到远程仓库，并且远程仓库会创建同名的分支来接收它们。

请注意： `--all` 选项只推送分支，不包含标签。如果你的项目也需要同步标签，那么推送完分支后，还需要额外执行 git push --tags origin 命令。

《夸克》非常好用的免费AI浏览器

下载APP查看