很多人学 Git 的时候，最大的痛苦不是命令太难，而是：
每条命令都见过，但连不成一条完整主线。
比如：
clone到底是在做什么；add和commit为什么不是一回事；- 我明明已经
commit了，为什么远程仓库里还是看不到； - 为什么有时候要先
pull，再push。
如果这些关系没理顺，Git 就会一直像一堆零散动作。
所以这篇文章只做一件事：
把最常用的一条 Git 日常工作流讲清楚。
先给出整条主线：
git clone -> 修改文件 -> git status -> git add -> git commit -> git pull -> git push如果你是第一次真正开始用 Git，那么先把这条线跑顺，就已经能覆盖大量日常场景了。
一、先记住 Git 里的 4 个位置
在讲命令之前，先记住 Git 最核心的 4 个位置：
工作区 -> 暂存区 -> 本地仓库 -> 远程仓库1. 工作区
工作区就是你现在眼前正在改的文件目录。
比如你在 VS Code 里改train.py、README.md，这些实际文件所在的位置，就是工作区。
2. 暂存区
暂存区可以理解成“下一次提交前的待打包清单”。
你可能改了很多文件，但不一定都想一起提交。
你可以先挑出这次准备提交的那部分，放进暂存区。
3. 本地仓库
本地仓库就是你电脑上的 Git 历史。
当你commit的时候，本质上是在往本地仓库里新增一个历史节点。
4. 远程仓库
远程仓库是团队共享的同步中心，比如 GitHub、GitLab、Gitee，或者实验室自己的代码服务器。
它的作用不是代替你的本地仓库，而是让不同人的本地历史能够彼此同步。
理解了这 4 个位置之后，下面这些命令就不再是零散动作，而是在这些位置之间搬运内容。
二、git clone：先把远程仓库拿到本地
如果一个项目已经在远程仓库里了，最常见的第一步是：
gitclone 仓库地址这条命令的作用不是简单“下载代码”，而是：
把一个完整的远程仓库克隆到本地。
它带下来的东西通常包括：
- 当前代码；
- 提交历史；
- 分支信息；
- 和远程仓库的关联关系。
也就是说，clone完之后，你本地拿到的不只是文件，而是一整套 Git 仓库。
三、修改文件之后，先git status
项目克隆下来之后，你就会开始改代码。
比如你修改了：
train.pyREADME.md
这时候我最推荐你养成的习惯，就是先看状态：
gitstatus这条命令会告诉你：
- 哪些文件被改了；
- 哪些文件还没被暂存；
- 哪些文件已经进了暂存区；
- 当前分支状态如何。
很多人 Git 出问题时第一反应是乱试命令，但更稳的习惯应该是：
先看 status，再决定下一步。
四、git add：把这次准备提交的改动放进暂存区
如果你确定某些修改准备进入下一次提交，就可以执行：
gitadd文件名比如：
gitaddtrain.pygitaddREADME.md如果你想一次把当前目录下所有改动都加入暂存区，也可以写：
gitadd.但这里要提醒一句：
git add .虽然方便，但也容易把一些你暂时不想提交的文件一起加进去。
所以初学阶段，尽量先知道自己到底加了什么。
1. 为什么add很重要
很多新手会疑惑：
“我都改完文件了，为什么还要再 add 一次？”
因为 Git 允许你把“工作区里的全部改动”和“这次真正想提交的改动”分开。
这让提交可以更清晰、更有边界。
比如你今天既改了一个 bug，又顺手改了文档。
你完全可以只先addbug 修复相关文件，把文档留到下一次提交。
这也是 Git 不只是“存文件”，而是在帮助你组织变化。
五、git commit：把暂存区内容正式记录到本地仓库
当你已经把本次要提交的内容放进暂存区之后，就可以执行：
gitcommit-m"修复训练脚本中的路径错误"这条命令的本质是：
把暂存区里的改动，正式记录成一个本地历史节点。
这里有一个非常关键的点：
commit 是本地动作，不是上传动作。
也就是说，即使你已经commit了，远程仓库里也不一定立刻能看到。
1. 提交说明为什么重要
-m后面的内容，就是这次提交的说明。
比如：
修复训练脚本中的路径错误补充 README 中的运行说明新增分类模型的验证逻辑
好的提交说明能让未来的你快速看懂：
- 这次改动在干什么；
- 为什么改；
- 以后如果出问题，可以先回看哪次提交。
所以 Git 不只是帮你保存历史，也在逼你给历史加说明。
六、git pull：先把远程更新拉下来
如果你不是一个人写这个项目，或者你有多台设备在同步代码，那么在准备推送之前，通常建议先执行：
gitpull它的作用可以简单理解成：
把远程仓库里的新更新拉回本地，并尝试合并。
为什么这一步重要？
因为远程仓库里可能已经有别人提交的新内容。
如果你本地不先同步，直接push，很可能会被拒绝。
所以一个很常见的习惯是：
先 pull，再 push。
当然，如果你确定远程没有别人的更新，这一步有时不会有变化，但在多人协作场景下，它是个很好的习惯。
七、git push：把本地提交同步到远程仓库
当你已经完成本地提交，并且确认远程更新也同步好了，就可以执行：
gitpush它的作用是：
把你本地仓库里已经 commit 的历史，同步到远程仓库。
这里一定要把几个动作分开：
git add：挑出准备提交的改动；git commit：把这些改动记录进本地历史；git push：把本地历史同步到远程。
很多新手最容易混淆的就是这里。
明明已经commit了，却发现远程还没有更新，本质原因就是：
commit 只发生在本地，push 才会把它送到远程。
八、把整条流程放进一个真实例子里
假设你接手了一个实验项目，现在要修改训练脚本并把改动同步到远程仓库。
你的过程大概会是这样：
第一步：克隆项目
gitclone 仓库地址第二步：进入项目目录并修改文件
你改了train.py和README.md。
第三步：查看状态
gitstatus你会看到哪些文件被修改了。
第四步：把本次要提交的内容加入暂存区
gitaddtrain.pygitaddREADME.md第五步：提交到本地仓库
gitcommit-m"修复训练路径并补充运行说明"第六步：先拉一下远程更新
gitpull第七步：推送到远程仓库
gitpush如果这一整套动作你已经能顺畅走下来，那么你就已经具备了最基础的 Git 日常使用能力。
九、新手最容易混淆的几个点
1.add不等于commit
add只是把改动放进暂存区。
真正形成历史记录的是commit。
2.commit不等于push
commit只是在本地记录历史。push才是同步到远程。
3. 不确定的时候，先status
很多 Git 问题，第一步都不是乱试命令，而是先看当前状态。
4. 多人协作时，先pull往往更稳
先把远程更新同步下来，再推自己的内容，可以减少很多不必要的问题。
十、第一阶段先掌握这条线就够了
如果你是初学者，真的不用一开始就学完所有 Git 命令。
先把这条线跑顺：
clone -> status -> add -> commit -> pull -> push你就已经能完成大多数最基础的协作动作。
后面再继续补：
branchmergerebase- 冲突处理
会轻松很多。
十一、结尾
Git 真正让人变顺手的关键，不是背了多少命令，而是你脑子里有没有一条稳定主线。
只要你能把下面这句话顺下来：
我先把仓库 clone 下来，改完之后看 status，再 add、commit，先 pull 同步远程，最后 push 上去。
那 Git 对你来说就已经不再是一堆零散命令了。
下一篇我们继续讲：
Git 里的 branch、merge、rebase 到底怎么理解
因为日常提交通了之后，接下来最重要的，就是理解多人并行开发到底是怎么组织起来的。