Git工作流程与常用指令——从本地开发到远程协作
Git工作流程与常用指令——从本地开发到远程协作
作者：Ye Shun
日期：2026-04-22
一、前言
对于很多初学者来说，Git 最让人困惑的地方并不是“命令太多”，而是：
- 不知道代码现在在哪个阶段
- 不清楚什么时候该
add - 不明白
commit和push的区别 - 遇到多人协作、分支开发、上传项目时容易手忙脚乱
其实，Git 的核心工作流程并不复杂。
只要你先理解 Git 的“四个区域”，再结合几个常见工作场景去练习，很多命令就会自然串起来。
这篇文章会从以下几个方面系统介绍 Git：
- Git 的基本工作流程
- 工作区、暂存区、本地仓库、远程仓库的含义
- 常见核心命令的作用
- 本地项目首次上传到 GitHub/GitLab 的完整流程
- 已有项目的协作开发流程
stash、pull、fetch、merge等常见场景指令- 日常使用 Git 的实战建议
如果你想把 Git 理解成一句话，那就是：
修改代码，挑选要提交的改动，保存为历史版本，再同步到远程仓库。
二、一张图看懂 Git 工作流程
下面这张流程图展示了 Git 最核心的工作链路：
你也可以把它想象成“写作业并交给老师”的过程。
三、Git 的四个核心区域
1. 工作区（Working Directory）——你的书桌
这是你实际修改文件的地方。
你在这里：
- 写代码
- 新建文件
- 删除文件
- 修改配置
也就是说，只要你在项目目录里动了文件，这些变化首先都发生在工作区。
2. 暂存区（Staging Area）——你的待邮寄篮子
当你觉得某些改动已经准备好提交时，可以先把它们放进“暂存区”。
对应命令是：
gitadd文件名或者：
gitadd.这一步的意义不是“提交”，而是：
- 先告诉 Git，哪些改动要进入下一次提交
也正因为有暂存区，你可以做到：
- 一个文件改了很多内容，但只提交其中一部分
- 多个文件都改了，但只挑出这次真正相关的改动来提交
3. 本地仓库（Local Repository）——你的个人保险箱
当暂存区准备好之后，就可以正式提交：
gitcommit-m"提交说明"这一步会把当前暂存区里的内容保存成一个历史版本。
提交之后，你就拥有了一个可以回溯、比较、恢复的版本记录。
4. 远程仓库（Remote Repository）——老师的收件箱
远程仓库通常托管在：
- GitHub
- GitLab
- Gitee
- 公司内部 Git 服务
当你想把本地提交同步到远程时，可以使用：
gitpush它的意义包括：
- 备份代码
- 与团队共享进度
- 触发代码审查或 CI/CD 流程
四、Git 的核心工作流程
Git 最基础的日常流程可以概括为：
修改代码 -> git status -> git add -> git commit -> git push这几个动作的真实含义分别是：
- 修改代码：在工作区完成开发
git status：查看哪些文件变了、哪些文件已暂存git add：把要提交的改动放入暂存区git commit：把暂存区内容保存为本地版本git push：把本地版本上传到远程仓库
其中，git status虽然不是“流程图上的主角”，但它几乎是最值得养成习惯的命令。
建议在很多关键节点都执行一次：
- 改完代码后
add之前commit之前push失败后
五、常见 Git 命令速览
下面是日常开发最常见的一组 Git 命令。
| 命令 | 作用 | 常见场景 |
|---|---|---|
git clone | 克隆远程仓库到本地 | 参与已有项目 |
git init | 初始化本地 Git 仓库 | 本地项目首次接入 Git |
git status | 查看当前改动状态 | 日常必查 |
git add | 将改动加入暂存区 | 提交前准备 |
git commit | 提交到本地仓库 | 保存版本历史 |
git push | 推送到远程仓库 | 上传代码 |
git pull | 拉取并合并远程更新 | 同步团队代码 |
git fetch | 仅获取远程更新，不自动合并 | 想先看变化再决定 |
git merge | 合并分支 | 合并功能分支或远程更新 |
git branch | 查看或管理分支 | 多分支开发 |
git switch/git checkout | 切换分支 | 在不同任务间切换 |
git stash | 临时保存当前未提交改动 | 中途插入紧急任务 |
git log | 查看提交历史 | 回顾版本 |
git remote -v | 查看远程仓库地址 | 检查是否连接远程 |
六、场景一：参与一个已有的远程项目
如果你要加入一个已经存在的 GitHub 或 GitLab 项目，第一步通常是克隆仓库：
gitclone https://github.com/username/repo.gitcdrepo然后建议先看看当前分支和状态：
gitbranchgitstatus如果项目不允许直接在main或master上开发，通常会新建一个功能分支：
gitswitch-cnew-feature如果你的 Git 版本较老，也可以使用：
gitcheckout-bnew-feature接下来就是标准开发流程：
gitadd.gitcommit-m"Add new feature"gitpush-uorigin new-feature其中-u的作用是建立本地分支和远程分支的追踪关系，后续再推送时通常直接git push就行。
七、场景二：把本地已有项目第一次上传到 Git
这是很多人最常遇到的场景之一，比如：
- 你本地已经写好了一个课程作业项目
- 你有一个 Python、Java、前端项目想上传到 GitHub
- 你希望给项目做版本管理并分享给别人
完整流程如下。
1. 先在远程平台创建一个仓库
在 GitHub、GitLab 或 Gitee 上先新建一个仓库。
建议第一次上传时创建“空仓库”，也就是：
- 不自动添加 README
- 不自动添加
.gitignore - 不自动添加 License
这样可以避免本地仓库和远程仓库初始历史不一致的问题。
2. 进入本地项目目录并初始化 Git
cdyour-projectgitinit3. 检查哪些文件应该提交
正式提交前，建议先准备.gitignore，避免把不该上传的内容提交上去，例如：
node_modules/venv/.idea/dist/- 临时缓存文件
- 密钥、账号配置文件
一个简单示例如下：
node_modules/ venv/ __pycache__/ .idea/ .vscode/ .env dist/ build/然后查看状态：
gitstatus4. 提交第一次版本
gitadd.gitcommit-m"Initial commit"5. 绑定远程仓库
gitremoteaddorigin https://github.com/username/repo.git可以检查是否绑定成功：
gitremote-v6. 推送到远程主分支
如果你希望主分支叫main，可以执行：
gitbranch-Mmaingitpush-uorigin main到这里，本地项目就已经成功上传到远程仓库了。
7. 如果第一次推送失败怎么办
有一种常见情况是：
- 你在远程平台创建仓库时，顺手勾选了 README 或
.gitignore - 于是远程仓库已经先有了一次提交
- 这时本地首次
push可能会被拒绝
更稳妥的处理方式通常有两种：
做法 A：重新创建一个空仓库
这最适合初学者，流程最干净。
做法 B：先把远程内容拉下来再合并
gitpull origin main --allow-unrelated-historiesgitpush-uorigin main不过如果你是第一次接触 Git，更建议优先使用“空仓库 + 本地首次上传”的方式，减少额外复杂度。
8. 一个从零开始的最小示例：把本地Test文件夹上传到 GitHub
如果你是第一次练习 Git，可以直接照着下面这个最小流程操作一遍。
第 1 步：先在本地创建一个文件夹
例如先创建一个叫Test的文件夹。
你可以直接在资源管理器里新建，也可以在cmd中执行：
mkdirTest第 2 步：进入cmd，切换到目标目录
假设你的文件夹路径是D:\desktop\Test，那么可以执行：
cd/d D:\desktop\Test这里使用cd /d是因为在 Windows 的cmd中，如果涉及磁盘切换，写法会更稳妥。
第 3 步：初始化 Git 仓库
gitinit执行完成后，当前目录下会出现一个.git文件夹。
它通常是隐藏的，你需要开启“显示隐藏文件”才能看到。
第 4 步：在Test目录下创建一个测试文件
比如可以新建一个：
README.md你可以手动创建，也可以在cmd里用下面的方式快速生成：
echo# Test > README.md第 5 步：把所有文件加入暂存区
gitadd.这里的意思是：
- 把当前目录下所有需要纳入版本管理的改动一起加入暂存区
第 6 步：提交到本地仓库
gitcommit-m"初始化项目"这一步表示你已经把当前版本正式保存到了本地 Git 历史中。
第 7 步：在 GitHub 上创建一个新的远程仓库
接着打开 GitHub 官网，在个人仓库里新建一个仓库。
为了方便理解，建议：
- 远程仓库名和本地文件夹名保持一致
- 例如都叫
Test - 尽量创建为空仓库，不要勾选自动生成 README
第 8 步：把本地仓库和远程仓库关联起来
在cmd中执行：
gitremoteaddorigin https://github.com/xxxx/Test.git其中：
origin是远程仓库的默认别名https://github.com/xxxx/Test.git需要替换成你自己的 GitHub 仓库地址
第 9 步：把主分支统一命名为main
gitbranch-Mmain第 10 步：首次推送到 GitHub
gitpush-uorigin main这里的-u表示建立追踪关系。
之后如果你还在这个分支上继续提交，通常直接执行：
gitpush就可以了。
整个流程汇总
mkdirTestcd/d D:\desktop\Testgitinitecho# Test > README.mdgitadd.gitcommit-m"初始化项目"gitremoteaddorigin https://github.com/xxxx/Test.gitgitbranch-Mmaingitpush-uorigin main如果你能完整跑通这一套流程，就说明你已经掌握了“本地项目首次上传到 GitHub”的最基础版本。
八、场景三：日常开发中的标准分支工作流
在团队协作中，最推荐的方式通常不是直接在主分支开发，而是：
- 先更新主分支
- 从主分支切出新分支
- 在新分支完成开发
- 推送分支
- 创建 Pull Request（PR）或 Merge Request（MR）
一个典型流程如下：
1. 先切到主分支并同步最新代码
gitswitch maingitpull origin main2. 新建功能分支
gitswitch-cfeature/login-page3. 开发并提交
gitadd.gitcommit-m"Implement login page"4. 推送到远程
gitpush-uorigin feature/login-page5. 在平台上发起 PR / MR
通常在 GitHub 或 GitLab 页面上发起代码审查，邀请其他成员审核。
这样做的好处是：
- 不影响主分支稳定
- 便于代码审查
- 更容易追踪每个功能对应的提交历史
九、场景四：改了一半，突然要切去做别的任务
这是git stash最典型的使用场景。
假设你现在正在写一个功能，但还没写完，不适合提交；这时领导或同学让你紧急修一个线上 Bug。
如果你直接切分支，未提交改动可能会干扰新任务。
这时可以先把当前修改“藏起来”：
gitstash查看当前 stash 列表：
gitstash list修完紧急任务之后，再把之前的改动恢复出来：
gitstash pop如果你只是想恢复，但不删除 stash 记录，可以使用：
gitstash apply这个功能非常适合：
- 多任务切换
- 改动写到一半但不能提交
- 临时切回主分支处理其他问题
十、场景五：如何同步远程最新代码
多人协作时，你不能只顾着本地写代码，还要及时同步远程更新。
这里经常会出现三个容易混淆的命令：
git pullgit fetchgit merge
1.git pull：拉取并合并
gitpull origin main它相当于两步操作的组合：
- 先从远程获取最新内容
- 再自动尝试合并到当前分支
优点是方便，缺点是有时候你还没看清变更就已经开始合并了。
2.git fetch：先取回来，但不急着合并
gitfetch origin执行后，远程更新会被拉到本地，但不会直接改动你当前分支的工作内容。
这适合更稳妥的做法：
gitfetch origingitlog--oneline--graph--allgitmerge origin/main也就是说：
- 先看看远程更新了什么
- 确认没问题
- 再自己决定是否合并
3.git merge：把一个分支合并到当前分支
例如你现在在main分支，想把new-feature合并进来：
gitmerge new-feature这通常出现在：
- 本地分支合并
- 先
fetch再手动合并 - PR 合并后，同步远程主分支到本地
十一、场景六：PR 合并后，本地应该怎么处理
假设你在远程平台已经把feature/login-page合并到main，那么本地通常会做这几步：
1. 切回主分支并拉取最新代码
gitswitch maingitpull origin main2. 删除本地功能分支
gitbranch-dfeature/login-page3. 如果不再需要远程分支，也可以删除
gitpush origin--deletefeature/login-page这样能保持分支整洁，避免仓库里堆满历史功能分支。
十二、场景七：遇到合并冲突怎么办
合并冲突并不意味着仓库坏了，它只是说明：
- 你和别人改了同一个位置
- Git 无法自动判断该保留谁的内容
常见处理流程如下：
1. 先查看状态
gitstatusGit 会提示哪些文件存在冲突。
2. 打开冲突文件，手动修改
你会看到类似这样的标记：
<<<<<<< HEAD 当前分支内容 ======= 另一分支内容 >>>>>>> feature/login-page你需要手动决定：
- 保留哪一部分
- 是否合并两边内容
修改完成后，删除这些冲突标记。
3. 重新加入暂存区并提交
gitadd.gitcommit-m"Resolve merge conflict"十三、场景八：提交错了、加错了，怎么补救
Git 的一个好处就是大部分错误都能修。
1.add错文件了，撤回暂存
gitrestore--staged文件名如果想撤回所有已暂存内容：
gitrestore--staged.2. 提交信息写错了，修改最近一次提交说明
gitcommit--amend-m"新的提交说明"如果这次提交已经推送到远程，再修改要格外小心，因为可能影响别人协作。
3. 工作区改乱了，想恢复某个文件
gitrestore 文件名这会丢弃该文件在工作区中的未提交修改，所以执行前一定确认清楚。
十四、一个最常用的 Git 日常模板
如果你还没有形成肌肉记忆，可以先记住这一套最通用流程：
场景 A：已有仓库开发
gitpull origin maingitswitch-cfeature/xxx# 开发代码gitstatusgitadd.gitcommit-m"Finish xxx"gitpush-uorigin feature/xxx场景 B：本地项目首次上传
cdyour-projectgitinitgitadd.gitcommit-m"Initial commit"gitbranch-Mmaingitremoteaddorigin https://github.com/username/repo.gitgitpush-uorigin main场景 C：临时切任务
gitstashgitswitch main# 处理其他任务gitswitch 原来的分支名gitstash pop十五、实战中的几个建议
1. 先学会看git status
很多 Git 初学者的问题，本质上都可以先靠git status判断。
2. 不要把所有内容都无脑git add .
虽然git add .很方便，但在正式项目里，建议先确认一下：
- 有没有把临时文件带进去
- 有没有把密钥、配置、日志文件提交进去
3. 提交信息要写清楚
比起：
gitcommit-m"update"更推荐：
gitcommit-m"Fix login validation bug"或者：
gitcommit-m"Add course recommendation page"好的提交信息能帮助你和团队成员快速理解每次改动的目的。
4. 优先使用分支开发
不要把主分支当成“随便改”的试验场。
尤其在多人协作、课程项目、竞赛项目里，分支管理会大幅减少风险。
5. 上传前注意.gitignore
以下内容一般不建议提交：
- 依赖目录
- 编译产物
- 临时缓存
- 本地 IDE 配置
- 密钥文件和环境变量文件
十六、总结
Git 的核心工作流程其实可以压缩成一句话：
在工作区修改代码，用
git add放入暂存区，用git commit保存到本地仓库，再用git push同步到远程仓库。
而真正让人熟练掌握 Git 的关键，不是死记命令，而是理解每条命令所在的场景：
- 参与已有项目时，用
clone - 本地项目首次上传时，用
init + remote add + push - 日常开发时，用
branch + add + commit + push - 多任务切换时，用
stash - 同步团队进度时，用
pull或fetch + merge
只要把这些场景练熟，你就会发现 Git 并不是“很难的工具”，而是一个非常可靠的版本管理助手。
如果你想继续往下写，这篇后面还很适合继续扩展：
- Git 分支管理策略：Git Flow、GitHub Flow、Trunk-Based Development
rebase和merge的区别- GitHub Pull Request 协作流程详解
- 如何写规范的 Commit Message
- Git 常见报错与排查清单