4 初始化力场仓库
万事开头难。但仓库初始化这事儿，说难也难，说简单也简单。我自己带团队的时候，经常发现新人第一步就栽在「到底用 init 还是 clone」上。咱们今天就把这个坎儿迈过去，顺便把最核心的那个三区域模型刻在脑子里。
4.1 两把钥匙：git init 与 git clone
初始化一个力场仓库，有两种方式：
- 从零开始 —— 用
git init把当前目录变成仓库 - 从远程复制 —— 用
git clone把别人建好的仓库搬下来
我个人习惯，如果是全新项目，绝对首选 git init。为什么呢？因为干净。没有历史包袱，commit 记录完全由自己掌控。我记得刚转行做版本管理那会儿，老想着偷懒，直接 clone 别人的模板仓库，结果里面一堆莫名其妙的分支和 tag，清理花了一个下午。
| 维度 | git init | git clone |
|---|---|---|
| 适用场景 | 新建本地项目 | 需要现有远程仓库 |
| 是否要求远程 | 不需要 | 必须提供 URL |
| 创建后目录 | 空工作区 + .git | 已有文件 + .git |
| 远程关联 | 需手动 git remote add | 自动关联 origin |
实际操作很简单。打开终端，进到你的力场文件目录：
mkdir my-force-field
cd my-force-field
git init执行完你会看到类似 Initialized empty Git repository in /path/to/my-force-field/.git/。这就代表仓库骨架搭好了。嗯，这里要注意：.git 目录就是仓库的命根子，里面存着所有版本快照、配置、引用。没事别手痒去删它，删了等于仓库连根拔起。
那 git clone 什么时候用呢？说白了，就是你想参与别人的力场项目，或者从公司服务器同步一份代码。举个例子：
git clone https://github.com/example/force-field-toolkit.git这命令会做两件事：第一，在当前目录下创建一个 force-field-toolkit 文件夹；第二，把远程所有历史拉下来，自动配好 origin。我曾经犯过一个错：clone 之后直接修改文件，忘了先建分支，结果把 master 的提交搞乱了。避坑指南：git clone 后第一件事，git checkout -b my-feature。
4.2 三区域模型——你必须要看清的地图
搞初始化仓库，不搞懂工作目录、暂存区、仓库这三个区域的关系，后面绝对会迷路。我刚开始接触 Git 的时候，以为只有工作目录和仓库两层，结果 add 和 commit 傻傻分不清，丢了好几次改动。
来看看这个三区模型：
你想想看，工作目录就是你电脑上能看到的文件，随便改。暂存区像一个中转站，你把改好的文件用 git add 放进去。仓库是最终存档位置，只有跑到仓库里的内容，才算真正被版本管理了。
为什么会分三个区？直接一个区不行吗？我第一次也这么想。后来在项目中遇到过这么个事：我同时改了三个力场文件，但只想把前两个提交，第三个还没改完。没有暂存区的话，要么全提交要么全不提交，太死板。暂存区给了你「挑着提交」的自由。
4.3 第一个力场文件提交
理论讲完，咱们实战走一遍。假设你刚建了一个力场项目，里面有个核心文件 force_field.cfg。第一件事，看看仓库状态：
git status你会看到类似：
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
force_field.cfg文件是「未跟踪」状态。好，把它添加到暂存区：
git add force_field.cfg
git status这时输出会变成：
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: force_field.cfg看到「Changes to be committed」了吗？文件已经躺在暂存区了。接下来提交：
git commit -m "初始提交：添加力场配置文件"执行后，Git 会告诉你：
[master (root-commit) a1b2c3d] 初始提交：添加力场配置文件
1 file changed, 12 insertions(+)
create mode 100644 force_field.cfg恭喜，第一个提交完成了。这里面有个细节：-m 后面的提交信息必须写清楚「为什么改」，而不是「改了什么」。我记得有一次紧急修复，只写了「fix bug」，过了两个月看日志完全想不起 fix 了啥。从此我要求团队所有提交信息必须包含动机。
.gitignore 文件，把编译产物、临时文件排除在外。否则一不小心把几百 MB 的中间文件加进来，后悔都来不及。
git add . 一股脑全加。先 git status 看看哪些文件不该进版本控制，比如 *.log、node_modules/、__pycache__ 等。我曾经把一个带密码的配置文件直接 add 进去了，结果推上远程才发现，只能重新生成密钥。
回到三区模型，你可以用 git log 看看刚产生的提交：
git log --oneline输出：
a1b2c3d (HEAD -> master) 初始提交：添加力场配置文件至此，整个「初始化 — 暂存 — 提交」的闭环就走通了。往后每改一次力场文件，都重复这个流程：edit → add → commit。你想想看，是不是比想象中简单？但千万别小看这第一步，很多团队在初始化阶段没统一规范，后面 merge 冲突、丢失改动全来了。
嗯，今天就到这。拿着这个三区模型去多练练，闭着眼也能说清楚「工作目录、暂存区、仓库」的关系。