Git 入门工作流：add、commit、pull、push

如果你只想把 Git 用稳，先记住一件事：大多数日常操作都围绕四个位置展开，分别是工作区、暂存区、本地仓库和远端仓库。git add 是把改动放进暂存区，git commit 是把暂存内容写进本地仓库，git push 才会把提交发到远端。

目录

• 先理解四个位置
• 一个最小日常流程
• 初始化、克隆与查看状态
  • git init
  • git clone
  • git status
• add 与 commit：为什么要分两步
  • git add
  • git commit
• fetch、pull、push 的区别
  • git fetch
  • git pull
  • git push
• 分支该怎么用
• 撤销常见场景
  • 取消暂存
  • 丢弃工作区未提交修改
  • 恢复删除文件
• 一个更贴近真实开发的流程
• 新手最常见的误区
• 结论
• 参考资料

先理解四个位置

工作区 -> 暂存区 -> 本地仓库 -> 远端仓库
         add       commit      push

• 工作区：你正在编辑的文件。
• 暂存区：这次提交准备带上的改动清单。
• 本地仓库：已经在本机保存的提交历史。
• 远端仓库：GitHub、GitLab 之类团队共享仓库。

很多“Git 看起来很乱”的问题，本质上都是没分清改动现在在哪一层。先跑一遍 git status，通常就知道下一步该做什么。

一个最小日常流程

git status
git add src/app/page.tsx
git commit -m "fix: correct homepage copy"
git push origin main

如果你还没准备提交全部改动，就不要先写 git add .。先选文件，再提交，回滚和 code review 都会轻松很多。

初始化、克隆与查看状态

git init

在一个新目录里创建本地仓库：

git init

适合从零开始的新项目。若项目已经在 GitHub 上，通常直接 clone，不要先 init 再手工连远端。

git clone

把远端仓库拉到本地：

git clone git@github.com:example/project.git

如果你经常提交代码，优先 SSH；如果只是只读拉取，HTTPS 也可以。你前面问过“是不是应该用 ssh”，对于长期开发仓库，答案通常是“是”。

git status

最常用的安全命令：

git status

它会告诉你：

• 当前在哪个分支
• 哪些文件已修改但未暂存
• 哪些文件已暂存
• 是否领先或落后远端

add 与 commit：为什么要分两步

git add

git add src/lib/posts.ts

git add 不是“提交”，只是把文件加入下一次提交的候选集合。它存在的意义是让你把一次改动拆成清晰的提交，而不是把一整天的变化糊成一个大包。

git commit

git commit -m "feat: add related content recommendations"

提交只会带上已经暂存的内容。提交信息最好回答两个问题：

• 这次改了什么
• 为什么值得单独成为一次提交

团队规范、提交格式和钩子可以再配合 Husky 与 Commitlint 实践。

fetch、pull、push 的区别

git fetch

git fetch origin

只下载远端最新提交，不自动合并到当前分支。适合你想先看远端发生了什么，再决定怎么处理。

git pull

git pull origin main

通常等于“先 fetch，再把远端分支合并或变基到当前分支”。它更省事，但也更容易在你没看清差异时直接把冲突带进工作树。

git push

git push origin feature/seo

把本地提交发到远端。注意只有已经 commit 的内容才能 push，工作区未提交的文件不会被带上。

分支该怎么用

查看本地分支：

git branch

新建并切换分支：

git switch -c feature/seo

相比旧写法 git checkout -b，git switch 更明确。一个稳定的团队习惯是：

• main 保持可发布
• 新需求或修复走独立分支
• 合并前做 review

如果你同时维护多套改动，又不想频繁 stash，可以考虑 git worktree。这和多分支协作配合更顺手，相关主题可见 Git worktree 与 stash 指南。

撤销常见场景

取消暂存

git restore --staged src/app/page.tsx

文件还在，只是从暂存区拿掉。

丢弃工作区未提交修改

git restore src/app/page.tsx

这会覆盖当前文件的未提交改动。执行前要确定你真的不再需要这些修改。

恢复删除文件

git restore README.md

前提是这个文件之前已经被 Git 跟踪。

一个更贴近真实开发的流程

git switch -c fix/build-warning
git status
git add src/app/layout.tsx
git commit -m "fix: remove deprecated middleware usage"
git fetch origin
git push origin fix/build-warning

这个流程比“直接在 main 上改完就 push”更稳，因为它更容易：

• 回滚
• review
• 拆分问题
• 避免多人直接改主分支

新手最常见的误区

• 以为 git add 就是提交。
• 修改完没 commit 就想 push。
• 不看 git status，靠感觉操作。
• 所有改动都 git add .，导致一次提交混入不相关内容。
• 在 main 上直接长期开发，最后历史和回滚都很痛苦。

结论

• Git 日常最核心的是理解四层状态流转。
• 先 status，再决定 add、commit、pull 还是 push。
• fetch 更安全，pull 更省事，是否直接用取决于你想不想先审差异。
• 分支、清晰提交和最小改动集，比背几十条命令更重要。

如果你接下来是要配团队提交规范，继续看 Husky 与 Commitlint 实践。如果你是在配置 Node、环境变量和忽略文件，也可以顺着看 前端项目配置文件指南。

参考资料

• Git 官方文档
• Git Book