包包和糖葫芦我见过太多人把 Git 用成了"网盘"：本地改完文件，网页端重新传一遍，或者靠复制整个文件夹来"备份版本"。这样当然也能活，但一旦想回滚到一周前的状态、想对比两次改动到底差在哪、想跟别人协作同一份代码，立刻就傻眼了。真正高效的用法，是本地建一个 Git 仓库管住所有改动，再把仓库推送到远程端，让本地和远程形成一套完整的版本流转闭环。这篇文章就把这条链路从头到尾拆开讲透，覆盖本地仓库初始化、首次提交、关联远程地址、第一次推送，以及推送过程中最容易出问题的几个节点。适合刚认真接触 Git 的人，也适合那些已经会敲几个命令但始终没搞懂底层逻辑的开发者。
1. 先想明白：本地仓库和远程仓库到底是什么关系
很多初学者把"本地仓库"理解成"我电脑上的文件夹"，把"远程仓库"理解成"服务器上的备份文件夹"，然后默认两者之间是同步关系。这个理解错得不算离谱，但它会直接导致后续一系列命令看得云里雾里。举个实际例子，你在本地新建了三个文件并且 commit 了，远程仓库上也有三个文件，但两者的提交记录完全不同。这时执行 git pull，大概率会冲突；执行 git push，大概率会被拒绝。如果是"网盘同步"的逻辑，这根本不该发生。所以第一步，先把模型纠正过来。
1.1 Git 的分布式模型：两个独立的仓库节点
Git 是分布式版本控制系统，意思是每一份克隆下来的仓库都拥有完整的提交历史，不依赖中央服务器才能工作。你的本地 .git 目录里，存着从项目第一个提交到当前最新提交的全部快照信息。远程仓库同样如此，它也是一个完整的 Git 仓库，不是挂在你电脑上的一个外接硬盘。
我用一个生活化的类比来解释：本地仓库就像是你的工作台，你在上面写写画画，每完成一个阶段，就把作品锁进工作台自带的抽屉（commit）。抽屉里的东西，只有你自己看得到。远程仓库是另一个房间里的文件柜，只有当你主动把抽屉里的成品搬过去（push），别人才能看到。注意，这个"搬"不是复制粘贴那么随意——文件柜有自己的台账（提交历史），你的每一次搬运都必须让台账对得上。
这个模型解释了为什么很多 Git 操作都是"先拉后推"。因为本地和远程是两个独立演进的仓库，push 前必须确认两者在同一个历史基线上。后面我们讲推送被拒绝时，还会回到这个模型。
1.2 一次完整操作的生命周期：init 到 push 的五个阶段
一次从零到远程仓库的完整流转，可以拆成五个阶段：
- 初始化：在项目目录执行
git init，生成.git目录，让文件夹变成 Git 仓库。 - 暂存：用
git add把文件的当前状态登记到暂存区，相当于告诉 Git"我准备把这些文件纳入版本管理"。 - 提交：用
git commit把暂存区内容固化成本地的一个提交记录，相当于在工作台抽屉里放进一个标记好日期的成品。 - 关联：用
git remote add把本地仓库和远程仓库关联起来，本质是给远程地址起一个本地可识别的名字。 - 推送：用
git push把本地提交上传到远程，让远程仓库的提交历史和本地对齐。
这五个阶段里，最常见的混淆点在第 2 和第 3 步。很多初学者以为 git add 和 git commit 是一件事，习惯连着敲 git add . && git commit -m "xxx"。这当然可以用，但容易错过暂存区这个关键设计。为什么 Git 非要拆两步？因为实际开发中你经常只想提交一部分文件，另一部分还在改。比如你同时改了登录模块和支付模块，逻辑上应该分成两次提交，这时候先 git add 登录相关文件，commit 一次，再 git add 支付相关文件，commit 一次，历史就非常清晰。如果一刀切全部 add 再 commit，两个不相关的改动就糊在一起了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本地仓库初始化：git init 背后的真实动作
初始化这一步看起来最简单，执行一条 git init 就结束了，但这条命令到底做了什么、什么时候该用哪种写法、初始化后能立刻做什么，很多人的认知是模糊的。我在实际带人时发现，大部分问题不是出在 push，而是出在 init 阶段就没有做对。
2.1 git init 创建了什么：一个隐藏目录的解剖
在项目根目录执行：
bash复制git init
Git 会在当前目录下创建一个 .git 目录。这个目录就是仓库的本体，里面至少包含这些关键部分：
objects/：存储所有提交的数据对象，包括文件内容快照和目录树结构。refs/heads/：存储本地分支引用，比如refs/heads/main指向当前 main 分支最新一次提交。HEAD：一个指针文件，指明当前检出在哪个分支上。index：暂存区的索引文件，记录已暂存文件的路径和对应的对象 ID。config：仓库级的配置文件，可以覆盖全局配置。
也就是说，git init 之后，你的普通文件夹才真正"长出了记忆"。你之后做的每一次提交、每一个分支切换，都在 .git 目录里留下痕迹。这也是为什么 Git 操作速度很快的一个原因——它不需要连接服务器，所有历史都在这一个隐藏目录里。
我在生产环境里见过一个典型的低级事故：有人把 .git 目录误删了，然后慌慌张张问我能不能找回提交记录。答案是几乎不可能。那个目录就是仓库的全部，删了它，历史就没了。所以在操作 .git 目录时务必谨慎，不要随便清理，也不要让编辑器或者构建工具把它加进忽略列表。