013、推送与拉取：git push与git pull的协作流程

上周排查一个线上问题，发现测试环境代码和仓库主干差了三个提交。问了一圈，原来是有同事本地改了代码直接下班走人，既没推也没拉。团队协作里这种事儿太常见了------你以为同步了，其实各自为政。今天咱们就掰扯清楚 git push 和 git pull 这对兄弟到底该怎么用。

先搞明白推送是往哪儿推

很多人以为 git push 就是把代码"传到网上"，其实不对。推送的本质是把本地分支的提交记录同步到远程仓库的对应分支。你本地仓库里那些 .git 目录下的对象，通过 push 操作在远程仓库里复制了一份。

bash 复制代码

# 最常用的推送命令
git push origin main

# 这个命令拆开看：
# origin 是你给远程仓库起的别名（默认就有）
# main 是你要推送的本地分支名
# 意思是：把本地 main 分支推送到 origin 仓库的 main 分支

这里有个坑：如果远程分支名和本地不一样，得明确指定。比如你本地分支叫 dev，远程想推送到 main，得用 git push origin dev:main。别直接 git push 就完事儿，容易推错分支。

拉取之前先看看别人动了什么

直接 git pull 是新手最容易翻车的操作。特别是团队协作时，你不清楚上游有什么改动，一拉可能就把冲突带进来了，而且合并得莫名其妙。

bash 复制代码

# 先看看远程有啥新东西
git fetch origin

# 查看远程分支更新情况
git log origin/main --oneline

# 确认没问题再合并
git merge origin/main

# 上面两条命令合起来就是 git pull
# 但分开操作更安全，心里有数

我习惯先 fetch 再 diff，看看别人改了哪些文件。有时候同事提交了大型配置文件或者生成文件，我得先决定要不要这些改动，再决定怎么合并。

推送被拒绝？多半是历史分叉了

当你兴冲冲地 git push，却看到 "rejected" 错误时，别慌。这通常是因为远程分支有你没有的新提交，Git 怕你覆盖别人的工作。

bash 复制代码

# 典型错误信息
! [rejected]        main -> main (non-fast-forward)

# 意思是远程分支比你本地领先了
# 这时候别强制推（-f），除非你确定要覆盖
# 正确做法是先拉取合并
git pull --rebase origin main
git push origin main

用 --rebase 选项可以把你的提交"挪到"远程最新提交之后，保持线性历史。不过要注意，如果已经推送过的提交就别 rebase 了，会扰乱团队其他人的历史记录。

配置上游分支省点力气

每次 push 都要打 origin main 挺烦的。其实可以设置上游关联：

bash 复制代码

# 推送同时设置上游
git push -u origin main

# 之后直接 git push 就行
# Git 知道你要推到哪里

用 git branch -vv 能看到本地分支跟踪的远程分支。这个设置特别适合长期开发的功能分支，一劳永逸。

个人经验：养成推送前的好习惯

我在团队里定了个规矩：推送前必须做三件事。一是 git status 看看有没有不该提交的文件，二是 git diff 确认改动内容，三是 git fetch 检查远程动态。这套流程坚持下来，能避免 80% 的合并冲突。

还有个细节：提交信息写清楚。别用"修复""更新"这种模糊描述，至少说明改了哪个模块、为什么改。半年后回看历史记录，你会感谢自己的。

最后说说 git pull 的两种方式：git pull 默认是 fetch + merge，会生成合并提交；git pull --rebase 是 fetch + rebase，保持线性历史。团队项目建议统一用同一种方式，不然历史记录会很难看。

协作开发就像多人共舞，push 和 pull 是基本步法。步子乱了不怕，Git 能帮你找回节奏，但前提是你得听懂它的提示。下次推送前，多看一眼终端里的信息，那都是 Git 在跟你说话。