Git 的日常主线：clone、add、commit、pull、push 一次讲清

很多人学 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.py
• README.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

你就已经能完成大多数最基础的协作动作。

后面再继续补：

• branch
• merge
• rebase
• 冲突处理

会轻松很多。

十一、结尾

Git 真正让人变顺手的关键，不是背了多少命令，而是你脑子里有没有一条稳定主线。

只要你能把下面这句话顺下来：

我先把仓库 clone 下来，改完之后看 status，再 add、commit，先 pull 同步远程，最后 push 上去。

那 Git 对你来说就已经不再是一堆零散命令了。

下一篇我们继续讲：

Git 里的 branch、merge、rebase 到底怎么理解

因为日常提交通了之后，接下来最重要的，就是理解多人并行开发到底是怎么组织起来的。