Git工作流程与常用指令——从本地开发到远程协作

Git工作流程与常用指令------从本地开发到远程协作

作者：Ye Shun

日期：2026-04-22

一、前言

对于很多初学者来说，Git 最让人困惑的地方并不是"命令太多"，而是：

• 不知道代码现在在哪个阶段
• 不清楚什么时候该 add
• 不明白 commit 和 push 的区别
• 遇到多人协作、分支开发、上传项目时容易手忙脚乱

其实，Git 的核心工作流程并不复杂。

只要你先理解 Git 的"四个区域"，再结合几个常见工作场景去练习，很多命令就会自然串起来。

这篇文章会从以下几个方面系统介绍 Git：

1. Git 的基本工作流程
2. 工作区、暂存区、本地仓库、远程仓库的含义
3. 常见核心命令的作用
4. 本地项目首次上传到 GitHub/GitLab 的完整流程
5. 已有项目的协作开发流程
6. stash、pull、fetch、merge 等常见场景指令
7. 日常使用 Git 的实战建议

如果你想把 Git 理解成一句话，那就是：

修改代码，挑选要提交的改动，保存为历史版本，再同步到远程仓库。

二、一张图看懂 Git 工作流程

下面这张流程图展示了 Git 最核心的工作链路：
git add
git commit
git push
git pull / git fetch
工作区 Working Directory
暂存区 Staging Area
本地仓库 Local Repository
远程仓库 Remote Repository

你也可以把它想象成"写作业并交给老师"的过程。

三、Git 的四个核心区域

1. 工作区（Working Directory）------你的书桌

这是你实际修改文件的地方。

你在这里：

• 写代码
• 新建文件
• 删除文件
• 修改配置

也就是说，只要你在项目目录里动了文件，这些变化首先都发生在工作区。

2. 暂存区（Staging Area）------你的待邮寄篮子

当你觉得某些改动已经准备好提交时，可以先把它们放进"暂存区"。

对应命令是：

git add 文件名

或者：

git add .

这一步的意义不是"提交"，而是：

• 先告诉 Git，哪些改动要进入下一次提交

也正因为有暂存区，你可以做到：

• 一个文件改了很多内容，但只提交其中一部分
• 多个文件都改了，但只挑出这次真正相关的改动来提交

3. 本地仓库（Local Repository）------你的个人保险箱

当暂存区准备好之后，就可以正式提交：

git commit -m "提交说明"

这一步会把当前暂存区里的内容保存成一个历史版本。

提交之后，你就拥有了一个可以回溯、比较、恢复的版本记录。

4. 远程仓库（Remote Repository）------老师的收件箱

远程仓库通常托管在：

• GitHub
• GitLab
• Gitee
• 公司内部 Git 服务

当你想把本地提交同步到远程时，可以使用：

git push

它的意义包括：

• 备份代码
• 与团队共享进度
• 触发代码审查或 CI/CD 流程

四、Git 的核心工作流程

Git 最基础的日常流程可以概括为：

修改代码 -> git status -> git add -> git commit -> git push

这几个动作的真实含义分别是：

1. 修改代码：在工作区完成开发
2. git status：查看哪些文件变了、哪些文件已暂存
3. git add：把要提交的改动放入暂存区
4. git commit：把暂存区内容保存为本地版本
5. 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 项目，第一步通常是克隆仓库：

git clone https://github.com/username/repo.git
cd repo

然后建议先看看当前分支和状态：

git branch
git status

如果项目不允许直接在 main 或 master 上开发，通常会新建一个功能分支：

git switch -c new-feature

如果你的 Git 版本较老，也可以使用：

git checkout -b new-feature

接下来就是标准开发流程：

git add .
git commit -m "Add new feature"
git push -u origin new-feature

其中 -u 的作用是建立本地分支和远程分支的追踪关系，后续再推送时通常直接 git push 就行。

七、场景二：把本地已有项目第一次上传到 Git

这是很多人最常遇到的场景之一，比如：

• 你本地已经写好了一个课程作业项目
• 你有一个 Python、Java、前端项目想上传到 GitHub
• 你希望给项目做版本管理并分享给别人

完整流程如下。

1. 先在远程平台创建一个仓库

在 GitHub、GitLab 或 Gitee 上先新建一个仓库。

建议第一次上传时创建"空仓库"，也就是：

• 不自动添加 README
• 不自动添加 .gitignore
• 不自动添加 License

这样可以避免本地仓库和远程仓库初始历史不一致的问题。

2. 进入本地项目目录并初始化 Git

cd your-project
git init

3. 检查哪些文件应该提交

正式提交前，建议先准备 .gitignore，避免把不该上传的内容提交上去，例如：

• node_modules/
• venv/
• .idea/
• dist/
• 临时缓存文件
• 密钥、账号配置文件

一个简单示例如下：

node_modules/
venv/
__pycache__/
.idea/
.vscode/
.env
dist/
build/

然后查看状态：

git status

4. 提交第一次版本

git add .
git commit -m "Initial commit"

5. 绑定远程仓库

git remote add origin https://github.com/username/repo.git

可以检查是否绑定成功：

git remote -v

6. 推送到远程主分支

如果你希望主分支叫 main，可以执行：

git branch -M main
git push -u origin main

到这里，本地项目就已经成功上传到远程仓库了。

7. 如果第一次推送失败怎么办

有一种常见情况是：

• 你在远程平台创建仓库时，顺手勾选了 README 或 .gitignore
• 于是远程仓库已经先有了一次提交
• 这时本地首次 push 可能会被拒绝

更稳妥的处理方式通常有两种：

做法 A：重新创建一个空仓库

这最适合初学者，流程最干净。

做法 B：先把远程内容拉下来再合并

git pull origin main --allow-unrelated-histories
git push -u origin main

不过如果你是第一次接触 Git，更建议优先使用"空仓库 + 本地首次上传"的方式，减少额外复杂度。

8. 一个从零开始的最小示例：把本地 Test 文件夹上传到 GitHub

如果你是第一次练习 Git，可以直接照着下面这个最小流程操作一遍。

第 1 步：先在本地创建一个文件夹

例如先创建一个叫 Test 的文件夹。

你可以直接在资源管理器里新建，也可以在 cmd 中执行：

mkdir Test

第 2 步：进入 cmd，切换到目标目录

假设你的文件夹路径是 D:\desktop\Test，那么可以执行：

cd /d D:\desktop\Test

这里使用 cd /d 是因为在 Windows 的 cmd 中，如果涉及磁盘切换，写法会更稳妥。

第 3 步：初始化 Git 仓库

git init

执行完成后，当前目录下会出现一个 .git 文件夹。

它通常是隐藏的，你需要开启"显示隐藏文件"才能看到。

第 4 步：在 Test 目录下创建一个测试文件

比如可以新建一个：

README.md

你可以手动创建，也可以在 cmd 里用下面的方式快速生成：

echo # Test > README.md

第 5 步：把所有文件加入暂存区

git add .

这里的意思是：

• 把当前目录下所有需要纳入版本管理的改动一起加入暂存区

第 6 步：提交到本地仓库

git commit -m "初始化项目"

这一步表示你已经把当前版本正式保存到了本地 Git 历史中。

第 7 步：在 GitHub 上创建一个新的远程仓库

接着打开 GitHub 官网，在个人仓库里新建一个仓库。

为了方便理解，建议：

• 远程仓库名和本地文件夹名保持一致
• 例如都叫 Test
• 尽量创建为空仓库，不要勾选自动生成 README

第 8 步：把本地仓库和远程仓库关联起来

在 cmd 中执行：

git remote add origin https://github.com/xxxx/Test.git

其中：

• origin 是远程仓库的默认别名
• https://github.com/xxxx/Test.git 需要替换成你自己的 GitHub 仓库地址

第 9 步：把主分支统一命名为 main

git branch -M main

第 10 步：首次推送到 GitHub

git push -u origin main

这里的 -u 表示建立追踪关系。

之后如果你还在这个分支上继续提交，通常直接执行：

git push

就可以了。

整个流程汇总

mkdir Test
cd /d D:\desktop\Test
git init
echo # Test > README.md
git add .
git commit -m "初始化项目"
git remote add origin https://github.com/xxxx/Test.git
git branch -M main
git push -u origin main

如果你能完整跑通这一套流程，就说明你已经掌握了"本地项目首次上传到 GitHub"的最基础版本。

八、场景三：日常开发中的标准分支工作流

在团队协作中，最推荐的方式通常不是直接在主分支开发，而是：

1. 先更新主分支
2. 从主分支切出新分支
3. 在新分支完成开发
4. 推送分支
5. 创建 Pull Request（PR）或 Merge Request（MR）

一个典型流程如下：

1. 先切到主分支并同步最新代码

git switch main
git pull origin main

2. 新建功能分支

git switch -c feature/login-page

3. 开发并提交

git add .
git commit -m "Implement login page"

4. 推送到远程

git push -u origin feature/login-page

5. 在平台上发起 PR / MR

通常在 GitHub 或 GitLab 页面上发起代码审查，邀请其他成员审核。

这样做的好处是：

• 不影响主分支稳定
• 便于代码审查
• 更容易追踪每个功能对应的提交历史

九、场景四：改了一半，突然要切去做别的任务

这是 git stash 最典型的使用场景。

假设你现在正在写一个功能，但还没写完，不适合提交；这时领导或同学让你紧急修一个线上 Bug。

如果你直接切分支，未提交改动可能会干扰新任务。

这时可以先把当前修改"藏起来"：

git stash

查看当前 stash 列表：

git stash list

修完紧急任务之后，再把之前的改动恢复出来：

git stash pop

如果你只是想恢复，但不删除 stash 记录，可以使用：

git stash apply

这个功能非常适合：

• 多任务切换
• 改动写到一半但不能提交
• 临时切回主分支处理其他问题

十、场景五：如何同步远程最新代码

多人协作时，你不能只顾着本地写代码，还要及时同步远程更新。

这里经常会出现三个容易混淆的命令：

• git pull
• git fetch
• git merge

1. git pull：拉取并合并

git pull origin main

它相当于两步操作的组合：

1. 先从远程获取最新内容
2. 再自动尝试合并到当前分支

优点是方便，缺点是有时候你还没看清变更就已经开始合并了。

2. git fetch：先取回来，但不急着合并

git fetch origin

执行后，远程更新会被拉到本地，但不会直接改动你当前分支的工作内容。

这适合更稳妥的做法：

git fetch origin
git log --oneline --graph --all
git merge origin/main

也就是说：

• 先看看远程更新了什么
• 确认没问题
• 再自己决定是否合并

3. git merge：把一个分支合并到当前分支

例如你现在在 main 分支，想把 new-feature 合并进来：

git merge new-feature

这通常出现在：

• 本地分支合并
• 先 fetch 再手动合并
• PR 合并后，同步远程主分支到本地

十一、场景六：PR 合并后，本地应该怎么处理

假设你在远程平台已经把 feature/login-page 合并到 main，那么本地通常会做这几步：

1. 切回主分支并拉取最新代码

git switch main
git pull origin main

2. 删除本地功能分支

git branch -d feature/login-page

3. 如果不再需要远程分支，也可以删除

git push origin --delete feature/login-page

这样能保持分支整洁，避免仓库里堆满历史功能分支。

十二、场景七：遇到合并冲突怎么办

合并冲突并不意味着仓库坏了，它只是说明：

• 你和别人改了同一个位置
• Git 无法自动判断该保留谁的内容

常见处理流程如下：

1. 先查看状态

git status

Git 会提示哪些文件存在冲突。

2. 打开冲突文件，手动修改

你会看到类似这样的标记：

<<<<<<< HEAD
当前分支内容
=======
另一分支内容
>>>>>>> feature/login-page

你需要手动决定：

• 保留哪一部分
• 是否合并两边内容

修改完成后，删除这些冲突标记。

3. 重新加入暂存区并提交

git add .
git commit -m "Resolve merge conflict"

十三、场景八：提交错了、加错了，怎么补救

Git 的一个好处就是大部分错误都能修。

1. add 错文件了，撤回暂存

git restore --staged 文件名

如果想撤回所有已暂存内容：

git restore --staged .

2. 提交信息写错了，修改最近一次提交说明

git commit --amend -m "新的提交说明"

如果这次提交已经推送到远程，再修改要格外小心，因为可能影响别人协作。

3. 工作区改乱了，想恢复某个文件

git restore 文件名

这会丢弃该文件在工作区中的未提交修改，所以执行前一定确认清楚。

十四、一个最常用的 Git 日常模板

如果你还没有形成肌肉记忆，可以先记住这一套最通用流程：

场景 A：已有仓库开发

git pull origin main
git switch -c feature/xxx

# 开发代码

git status
git add .
git commit -m "Finish xxx"
git push -u origin feature/xxx

场景 B：本地项目首次上传

cd your-project
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/username/repo.git
git push -u origin main

场景 C：临时切任务

git stash
git switch main

# 处理其他任务

git switch 原来的分支名
git stash pop

十五、实战中的几个建议

1. 先学会看 git status

很多 Git 初学者的问题，本质上都可以先靠 git status 判断。

2. 不要把所有内容都无脑 git add .

虽然 git add . 很方便，但在正式项目里，建议先确认一下：

• 有没有把临时文件带进去
• 有没有把密钥、配置、日志文件提交进去

3. 提交信息要写清楚

比起：

git commit -m "update"

更推荐：

git commit -m "Fix login validation bug"

或者：

git commit -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 并不是"很难的工具"，而是一个非常可靠的版本管理助手。

如果你想继续往下写，这篇后面还很适合继续扩展：

1. Git 分支管理策略：Git Flow、GitHub Flow、Trunk-Based Development
2. rebase 和 merge 的区别
3. GitHub Pull Request 协作流程详解
4. 如何写规范的 Commit Message
5. Git 常见报错与排查清单