企业官网建设流程全解析

不知道你有没有经历过这种时刻：辛辛苦苦改了一个上午的代码，加了一堆新功能，结果下午发现思路全错了，想退回早上那个版本——但文件已经被覆盖，Ctrl+Z 也救不了你。又或者，你熬夜写论文，改了一版又一版，最后文件名变成了《毕业论文_最终版_再也不改_真的不改_3.0.docx》。这种“手动版本管理”的滋味，凡是经历过的人都懂。

Git 就是来解决这个问题的。它是目前全世界使用最广泛的分布式版本控制系统，由 Linux 之父 Linus Torvalds 在 2005 年为了管理 Linux 内核源码而开发。用大白话说，它就是一个“会拍照的文档管家”：你每完成一个阶段的工作，它就帮你拍一张快照（commit），之后无论你把文件改得多乱，都能随时回到任意一张快照的时刻，还能对比任意两次快照之间的差异。系统崩了、文件误删、功能改崩，统统有后悔药吃。

这篇文章写给 Linux 下的 Git 初学者，也适合那些已经会用 add、commit、push 三板斧、但心里对 Git 原理还是一团浆糊的同学。我会把 Git 的核心逻辑讲透，再给你一套能直接照抄的命令流，最后把我这些年踩过的坑全摆出来。放心，里面没有那么多高深莫测的东西，你把“拍照”这两个字记牢，就成功了一半。

1. 先把“会拍照的文档管家”这个比喻讲透

1.1 工作区、暂存区、版本库：三个抽屉的故事

很多教程一上来就让背三个名词：工作区（Working Directory）、暂存区（Staging Area / Index）、版本库（Repository）。听起来抽象，其实对应到“拍照管家”的比喻里特别清楚。

• 工作区：就是你电脑里能看到的那个项目文件夹。你正在写的代码、正在改的文档，都摊在这里。
• 暂存区：可以理解为“拍照前的摆姿势区”。你觉得某个改动改得差不多了，先把它放进暂存区，但还没真正按下快门。
• 版本库：就是管家手里的相册。每一张照片（commit）都保存在这里，永久可查，里面还有各种索引信息。

为什么要多出“暂存区”这一层？这是 Git 设计里非常聪明的一点。比如你同时改了三个文件，其中两个已经改完想记录，还有一个改到一半、思路还没理顺。如果拍照时所有文件必须一锅端存进去，那这个半成品就被迫入册了，以后回看的时候全是脏数据。有了暂存区，你就可以只把改好的两个文件“摆好姿势”，把第三个留在工作区继续改。说白了，暂存区就是“精确选人入镜”的机制。

还有一个关键概念叫 HEAD。你可以把它理解成管家手里那只“当前正在看哪张照片”的手指，它指向你在版本库里当前所处的位置。每当你切换分支、回退版本，其实都在挪动这个“手指”。后面讲 reset 的时候，你会反复和它打交道。

1.2 快照模型：Git 和 SVN 最本质的区别

老一辈的版本控制器（比如 SVN、CVS）用的是“差异文件”模型。什么意思呢？它们只记录每次提交时“改了哪个文件的哪几行”，你拿到的是一份补丁列表。要还原某个历史版本，需要从最早的那个版本开始，把一串补丁逐个打上去，速度慢且容易出错。

Git 不一样，它用的是“快照”模型。每次 commit，Git 都会把当前所有文件的状态完整地拍一张照——注意是“所有文件”，而不是只记录差异。你可以把 SVN 理解成记日记：“某天某页第3行改成了别的字”；而 Git 是每天给整个文件柜拍一张全景照片。所以 Git 的每次操作几乎都在本地完成，速度飞快，离线也能用，这是它后来打败 SVN 的根本原因。

也有人会担心：每次提交都做全量快照，硬盘不得爆了？Git 内部其实做了很多优化，比如对象压缩、仅保存文件未变时只存一个引用指针等。实际用下来，仓库体积增长是非常可控的。具体到 .git 目录内部还会讲。

1.3 .git 目录：管家的账本长什么样

当你运行git init之后，项目目录下会多出一个隐藏文件夹.git，这就是管家放账本和相册的地方。新手别去手动翻改里面文件，但了解结构有助于理解 Git。

• HEAD：一个指针文件，记录当前所在的分支或提交。
• config：当前仓库的配置文件，仓库级别的配置就存在这里。
• objects/：真正的“相册底片”，提交数据、文件快照都压缩存储在这里。
• refs/：分支、标签等命名指针的所在地。
• index：暂存区的实体文件，临时记录你“摆好姿势”的内容。
• logs/：操作历史日志，很多命令的“后悔药”就靠它。

我之前遇到过一个非常典型的崩溃现场：有个同事图省事，直接把.git整个文件夹复制到另一台机器，然后在那台机器上乱改，导致两个仓库的引用错乱，最后只能靠reflog手动找回了一部分提交。所以记住两件事：第一，.git目录不要手动改；第二，真要备份，用git clone或者git push，别用文件复制。

2. 在 Linux 上装好 Git，不同发行版各有姿势

2.1 官方软件源安装：90% 场景的首选

Linux 下安装 Git 很简单，绝大多数发行版都可以直接从官方软件源装，一条命令搞定：

• Debian / Ubuntu / 基于 Debian 的发行版

  sudo apt update sudo apt install git

• CentOS / RHEL / Rocky Linux / AlmaLinux

  sudo yum install git # 新版系统用 dnf 也可以 sudo dnf install git

• Arch Linux / Manjaro

  sudo pacman -S git

• openSUSE

  sudo zypper install git

有同学总是纠结“软件源里的版本太旧”。其实对于日常开发和写文档来说，软件源里的 Git 版本完全够用。比如 Ubuntu LTS 自带的 Git 也许不是最新版，但稳定、安全补丁会跟进，对你并不构成实际障碍。我最初在 CentOS 7 上用yum install git装出来的版本是 1.8.x，就这么用了两年多，也没有遇到解决不了的问题。如果你真的需要新特性（比如更快的 partial clone），再考虑编译安装。

2.2 编译安装最新版：想尝鲜可以这么干

如果你非要最新版，Git 官网提供了源码包，编译安装也不算复杂。大致步骤：

# 先安装编译依赖，这里以 Debian/Ubuntu 为例 sudo apt install make gcc libssl-dev libcurl4-gnutls-dev zlib1g-dev autoconf # 下载源码，可以从 Git 官方仓库克隆，也可以下载 tar 包 git clone https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.47.0.tar.gz # 或者 wget 下来，具体版本以官网为准 tar -xzf git-2.47.0.tar.gz cd git-2.47.0 ./configure --prefix=/usr/local make -j$(nproc) sudo make install

编译过程中最容易踩的坑是缺依赖，报错信息类似于fatal error: openssl/ssl.h: No such file or directory。解决办法就是把对应库的开发包装上，Debian/Ubuntu 下是libssl-dev，CentOS/RHEL 下是openssl-devel，其他依赖同理。装完之后再看一眼版本：

git --version

如果显示的还是旧版本，先检查一下命令行里实际调到了哪个路径的 git：

which git

有可能/usr/local/bin/git存在，但你的系统 PATH 优先级里/usr/bin排在前面，这时候要么调整 PATH，要么直接软链接处理。我的建议是：非必要不编译，编译前先想清楚你到底缺了哪个功能。

2.3 装完之后的第一件事：验证一下

装完 Git，先别急着建仓库，跑几个基础命令确认环境没问题：

git --version git help # 简单看一下帮助 git help tutorial # 官方入门教程，本地就能看

如果git --version能正常输出版本号，说明安装成功。另外建议顺手把vim、nano等编辑器装好，因为后面提交代码时要写 commit message，没有编辑器会比较痛苦。我个人习惯git config --global core.editor "vim"，直接用 Vim 写提交说明，效率很高。

3. 第一次“拍照”之前，这些配置必须先做好

3.1 身份信息：让每一张照片知道是谁拍的

装完 Git 的第一件事，是告诉它你是谁。这相当于给每张快照盖上姓名章，方便团队协作时追溯作者。配置命令：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这里有两个容易忽视的点。

第一，--global表示全局配置，写在用户主目录下的~/.gitconfig文件里；如果你删掉--global，则只会写入当前仓库的.git/config，优先级高于全局配置。团队项目里，公司和个人的邮箱可能不同，这种按仓库区分配置的做法非常实用。

第二，邮箱一定要填真实有效的。很多人随便填一个123456@qq.com之类的，后来离职了别人想联系这个人却发现邮箱根本不存在，代码注释里又写不清是谁干的活，那个酸爽，维护过老项目的人都懂。

验证配置是否生效：

git config --list

也可以只看某一项：

git config user.name git config user.email

3.2 SSH 免密登录：告别每次输密码

如果你要用 Git 连接 GitHub、GitLab、Gitee 这些远程托管平台，强烈建议配置 SSH 密钥，省得每次 push、pull 都要输账号密码（现在很多平台也直接禁用了 HTTPS 密码方式）。生成密钥的方法：

ssh-keygen -t ed25519 -C "你的邮箱或备注"

一路回车默认会在~/.ssh/下生成id_ed25519（私钥）和id_ed25519.pub（公钥）。注意，出厂默认使用的加密算法各家不一，ed25519是目前兼顾安全和速度的推荐选择；如果是特别老的服务器上，改用rsa也可以。

然后查看公钥内容：

cat ~/.ssh/id_ed25519.pub

把这串公钥复制到 GitLab / GitHub / Gitee 后台的 SSH Keys 设置里。测试连接：

ssh -T git@github.com # 或 ssh -T git@gitlab.com

如果返回类似Hi username! You've successfully authenticated，就说明密钥配置成功了。

我踩过的一个坑是：密钥文件权限太开放，SSH 会直接拒绝加载。表现为明明公钥已经添加，但ssh -T仍然报Permission denied (publickey)。解决办法：

chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519 chmod 644 ~/.ssh/id_ed25519.pub

顺便说一句：不要随手把私钥发给任何人，私钥丢了就等于把仓库的钥匙丢了。如果怀疑私钥泄露，重新生成一对密钥并在托管平台删掉旧公钥即可。

3.3 换行符和文件名的两个坑

Linux 下配置 Git 还有两个非常常见的坑：换行符和中文文件名。

换行符问题在跨平台协作时特别突出。Windows 默认CRLF，Linux/Mac 默认LF。如果不处理，一个文件在 Windows 上被编辑保存后，提交到 Git 里会产生大量“假差异”，严重影响 diff 查看和 rebase。比较稳妥的方式：

git config --global core.autocrlf input

input的含义是：提交到 Git 时把CRLF转成LF，但检出时不主动转换。这比较符合 Linux/Mac 用户的习惯。Windows 用户用的是core.autocrlf true，会自动在检出时转成CRLF、提交时转回LF。

中文文件名问题也困扰着不少人。默认情况下 Git 会把非 ASCII 文件名转成八进制转义序列显示，比如"\346\265\213\350\257\225.txt"，看的人一脸懵。解决办法是设置：

git config --global core.quotepath false

这样就能直接看到测试.txt这样的中文文件名了。另外我还会顺手打开颜色显示：

git config --global color.ui auto

这几个配置做完，基本就可以安心开工了。

4. 日常“拍照”实操：一套命令搞定版本管理

4.1 git init + git add：把改动请进“待拍区”

假设你有一个项目文件夹my-project，想用 Git 管起来，只需要进去执行：

cd my-project git init

这样，当前目录就被初始化成了一个 Git 仓库，生成了上面提到的.git目录。接下来你写了一个新文件hello.py，用git status看一下：

git status

会看到它出现在“Untracked files”里，意思是管家还不认识这个文件。这时候把它加入暂存区：

git add hello.py

git add的几种常见用法：

git add . # 添加当前目录下所有改动，慎用，会把不该加的都加进来 git add src/main.py # 添加指定文件 git add src/ # 添加目录下所有改动 git add -p # 交互式按块（hunk）添加，挑着加，强烈推荐

git add -p是我最常用的命令之一。它可以让你把同一份文件里的多个改动分成几批加入暂存区，便于把不同逻辑的改动拆到不同 commit。比如我可能在一个文件里既改了 A 函数的 bug，又顺手改了 B 函数的注释，用-p就能把这两部分分开提交，以后回看历史时每一条提交都干净利落。

还需要一个.gitignore文件。这个文件的作用是告诉 Git“哪些文件不需要纳入版本控制”。比如 Python 项目里的__pycache__、venv，Node 项目里的node_modules，IDE 配置文件等。如果一开始没写，之后误提交了大量无关文件，处理起来非常麻烦。一个简单的示例：

__pycache__/ *.pyc node_modules/ .DS_Store .idea/ .vscode/ *.log

4.2 git commit：按下快门，存进相册

暂存区里准备好了，就该真正“按下快门”了：

git commit -m "feat: 新增用户登录功能"

-m参数后面就是提交信息，对应“这张照片的说明”。提交信息最忌讳写“update”或者“修改了一些东西”这种毫无信息量的话。比较好的习惯是简洁描述“做了什么”，推荐遵循业界常见的提交格式：

<type>: <subject> 例如： feat: 新增用户注册接口 fix: 修复订单金额溢出问题 docs: 更新 README 说明 refactor: 重构登录模块代码结构

我个人的习惯是“一次提交只做一件事”，一个功能一个提交，一个 bug 修复一个提交。这么做的价值在写git log回看历史时体会特别深，每一条提交都清晰可读，定位问题就像翻一本目录整洁的相册一样方便。

如果你有文件漏加了，或者提交信息写错了，可以用：

git commit --amend

这个命令会修改“最近一次提交”，相当于把刚才那张照片重新补拍了一次。注意它只适合改还没推送到远程的本地提交，如果是已经 push 出去的历史提交，--amend会导致历史重写，和队友协作时可能会造成混乱。

4.3 git status / git log / git diff：随时翻看和对比

日常用得最多的三个“查看类”命令，必须把它们之间的区别搞清楚。

git status查看当前工作区的状态：哪些文件被改了，哪些文件在暂存区，哪些冲突还没解决。

git log查看提交历史，也就是翻相册。常用参数：

git log --oneline # 简洁版，一行一次提交 git log --graph # 图形化显示分支结构 git log --all # 所有分支的历史 git log -n 5 # 只看最近 5 条 git log --author="name" # 按作者过滤 git log --oneline --graph --all # 我几乎每天都会用

git diff查看差异，它有好几种组合：

git diff # 工作区 vs 暂存区（你改了但没 add 的内容） git diff --staged # 暂存区 vs 最近一次提交（你 add 了但还没 commit 的内容） git diff HEAD # 工作区 vs 最近一次提交（工作区所有改动） git diff HEAD~2 HEAD # 对比最近两次提交之间的差异 git diff a.txt # 只看某个文件的差异

用一个生活场景帮助理解：git diff像是管家拿着放大镜对比“你眼前的文件和照片里”的差别，git diff --staged是检查“已经摆好姿势的人”和上一张照片的差别，git diff HEAD则是把工作区所有变化一次性全给你列出来。

5. 从单机到协作：分支、合并与远程仓库

5.1 分支：平行世界的快乐与烦恼

分支是 Git 最强大的功能之一，理解它的核心其实就一句话：分支本质上只是指向某个提交的“移动指针”。创建分支的成本极低，因为不复制文件、不占额外空间，只是建了一个新的引用。这也是为什么 Git 鼓励你大胆开分支。

常用操作：

git branch dev # 创建分支 dev（但不会切过去） git branch # 查看本地分支列表，当前分支前面带 * git branch -a # 查看所有分支，包括远程分支 git switch dev # 切换到 dev 分支（新式命令） git switch -c feature/login # 创建并切换到新分支（写代码最常用） git branch -d dev # 删除分支（-D 强制删除）

老一点的教程都推荐git checkout -b dev，新写法是git switch -c dev。两者都可以，我个人更习惯switch，因为它职责更单一，不容易和“撤销文件修改”混淆。

开分支最大的好处是：你把当前这个“平行世界”随便造，哪怕所有功能都写崩了，也不会影响主线。等你确定功能稳定了，再合并回主干。这比上来就直接在 main 分支上改要安全得多。

5.2 merge 与 rebase：两种合并思路怎么选

分支工作完了，怎么把成果并回主分支？Git 提供了两种主流方式：merge 和 rebase。

merge 的流程：

git switch main git merge feature/login

merge 会创建一个新的“合并提交”，历史会出现分叉再交会的形状，用git log --graph看会有一条明显的“^”字结构。它的优点是保留了你实际开发的时间线和上下文，缺点就是历史看起来比较“花”。

rebase 的流程：

git switch feature/login git rebase main git switch main git merge feature/login

rebase 的效果是把 feature 分支上的提交“变基”到 main 分支的最新提交之后，最后合并出来的历史是线性的，非常干净。它的本质是把你分支上的每个提交“重新演一遍”，相当于复制粘贴到新位置，所以提交的 hash 会改变。

选择建议很简单：你自己的功能分支随便 rebase，怎么顺怎么来；但公共分支（比如大家共用的 main、develop）上绝对不要随便 rebase，否则会把历史重写，其他人拉取时会遭遇一堆冲突。团队协作时，合并公共分支优先用 merge，个人清理历史时用 rebase。还有一句话我记了很多年：“rebase 是把别人的基础变成你的基础，merge 是把你和别人放在同一个交汇点。”

5.3 远程仓库：把相册备份到云端并与人共享

本地仓库只能自己看，想要多人协作或者跨设备同步，就要有一个“云相册”——也就是远程仓库。常见的托管平台有 GitHub、GitLab、Gitee 等。操作流程：

# 关联远程仓库 git remote add origin git@github.com:username/my-project.git # 查看远程仓库配置 git remote -v # 推送本地 main 分支到远程 git push -u origin main # 拉取远程仓库到本地 git clone git@github.com:username/my-project.git # 从远程拉取最新改动（相当于 fetch + merge） git pull

-u参数的作用是设置上游分支，此后直接git push或git pull就能自动匹配到origin/main。日常开发中我的标准流程是：先git pull同步最新代码，再开始干活，干完git status检查改动、git add、git commit、最后git push。这套流程简单可靠，几乎可以覆盖日常工作的大多数场景。

还要注意git pull和git fetch的区别。git fetch只是把远程的最新提交“下载”到本地引用，不会改动你当前的工作区；git pull则是先 fetch 再自动 merge，会直接修改工作区。如果你暂时不想合并远程代码，只想看看对方改了什么，用git fetch，然后git log HEAD..origin/main查看差异，之后再手动决定要不要合并。这个习惯在多人协作时能避免许多不必要的冲突。

5.4 冲突处理：当两个人都改了同一段代码

多人协作最头疼的就是冲突（conflict）。本质上，两个人同时改了同一文件的同一区域，Git 合并时不知道哪份是对的，就把决定权交还给你。冲突发生时会看到类似这样的标记：

<<<<<<< HEAD 现在的代码内容 ======= 你正在合并的分支上的代码内容 >>>>>>> feature/login

处理步骤：

1. 打开冲突文件，逐段查看<<<<<<<、=======、>>>>>>>标记之间的内容。
2. 保留你想要的代码，删掉冲突标记。如果两边功能都要保留，就手动整合成一段新代码。
3. 处理完所有冲突后，git add该文件。
4. 最后git commit完成合并。

如果处理到一半发现太乱了，想放弃这次合并，执行：

git merge --abort

就能回到合并前的状态。这个命令就是后悔药，团队新人在学习合并时完全可以大胆试错。

减少冲突的核心经验是：第一，尽量小步提交、频繁拉取，别憋几天不 pull，最后一次性合并上千行改动；第二，不同模块放在不同文件里，降低改到同一文件的概率；第三，公共配置文件的改动要格外谨慎，最好由一个人统一牵头改，其他人不要频繁动。

6. 真实项目中踩过的坑：常见问题与排查

6.1 高频报错速查表

整理了一份我在日常使用中经常遇到的报错和解决方案，遇到问题先对照这里看。

下面挑几个重点展开说一下。

第一个是refusing to merge unrelated histories。这个通常发生在你本地仓库和远程仓库是从两个不同源头初始化、没有任何共同祖先的情况下。比如你新建了一个仓库，然后在远程也新建了一个带 README 的仓库，把两者关联后直接 push，就会报这个错。如果你确认两边确实是想合并的，可以执行：

git pull origin main --allow-unrelated-histories

但请谨慎使用，它把两组互不相干的历史强行揉在一起，之后看git log会比较奇怪。

第二个是failed to push some refs。这是团队协作中出现频率最高的报错，本质是“你推代码之前，远程已经有人先推过了”。解决办法很简单：先git pull，解决可能的冲突，再重新 push。在 pull 时如果不想自动生成合并提交，可以git pull --rebase，把本地提交变基到远程最新提交之后，历史更干净。

第三个是误提交大文件。很多项目教训：有人把几百 MB 的压缩包或模型文件直接提交进 Git 仓库，导致仓库体积爆炸，克隆一次都要等很久。解决办法是：先用.gitignore把这类文件忽略掉，再用git rm --cached huge_file.zip把它从版本控制中移除（保留本地文件）。注意，git rm --cached只影响“未来不再跟踪”，已经存在于历史里的文件还是在对象库里——如果确实需要把历史里的也清掉，要借助git filter-repo这类工具重写历史，但这是高风险操作，社区分享的准则一般是：重写历史要非常慎重，且团队成员必须同步配合。

6.2 一个完整的“误操作急救”案例

举个例子。某次我改代码，越改越乱，最后想从干净状态重新开始改。这时候工作区已经很脏了，我并不知道哪个文件被我改成了什么样。正确的急救步骤是：

# 第一步：看一下所有改动 git status # 第二步：对比工作区和最近一次提交的差异 git diff # 第三步：确认这些改动都不要了，直接丢弃工作区改动 git checkout -- 文件名 # 或者新版习惯用 git restore 文件名 # 如果要把暂存区里的改动也回退，先取消暂存 git restore --staged 文件名 # 如果 commit 已经提交了，但想撤销这几次 commit 但保留改动 git reset --soft HEAD~1 # 撤销最近一次提交，改动回到暂存区 # 如果想彻底回到上一个干净版本，工作区改动也全部丢弃 git reset --hard HEAD~1 # 慎用！这条命令会丢掉工作区未提交的全部改动

这里着重讲一下git reset的三个模式，面试也爱考：

• git reset --soft：只移动 HEAD 指针，暂存区和工作区都不变。用于“提交后发现 message 写错了，或者想重新合并几个提交”。
• git reset --mixed（默认）：移动 HEAD 指针，并把暂存区重置，但工作区不变。用于“撤销暂存但保留修改”。
• git reset --hard：三者全部重置，工作区的改动直接消失。这条命令等于“把相册撕回到某一张，并且把桌上所有待处理的草稿也扔掉”，一定要慎用。

还有一个我强烈建议每个人养成的习惯：在动手大改之前，先打个标签或开个分支。哪怕你现在在 main 分支上，也可以先git switch -c wip/xxx，然后在临时分支上折腾，改崩了直接切回main即可，一点心理负担都没有。“分支便宜”这件事，真用起来才知道有多香。

6.3 小技巧：让 Git 好用一倍

书单列完了，再分享几个真正能提升日常效率的小技巧。

第一个是git stash，临时存放工作区改动。比如你写到一半，突然线上有个 bug 要立刻切分支处理，但又不想把写到一半的代码提交，就可以：

git stash # 把当前改动暂存起来，工作区瞬间干净 git switch main # 切分支去处理线上问题 # 处理完之后回到原来的分支 git switch 原分支 git stash pop # 把暂存起来的工作区改动恢复出来

第二个是自定义别名。Git 支持给命令设置别名，能显著缩短日常敲命令的时间：

git config --global alias.st status git config --global alias.ci commit git config --global alias.br branch git config --global alias.co checkout git config --global alias.lg "log --oneline --graph --all --decorate"

配置完以后，git st就是git status，git lg就是一排漂亮的历史图形。这个习惯我已经坚持了好几年，效率提升非常明显。

第三个是git cherry-pick，把另一个分支上的某个提交单独拿过来：

git cherry-pick <commit-hash>

比如你在开发分支上修了一个 bug，但懒得把整个分支合并到 main，只把这个修复提交挑到 main 即可。这种“精准搬运”在走发布流程时非常实用。

第四个是git blame，定位某一行代码是谁、什么时候、哪次提交引入的：

git blame src/main.py

追查线上问题的“锅”是谁的，或者理解一个没人注释的奇怪逻辑时，全靠它。不过用的时候心态放平，代码有问题不代表人有问题，重点是把逻辑理清楚。

7. 再聊几句心里话

文章快结束的时候，想分享一点我个人的感受。我做程序员这些年，亲眼看着 Git 从“Linux 社区专用的工具”变成了几乎所有技术团队默认的基础设施。它确实是那种“早学早享受、越用越顺手”的工具。

我觉得学会 Git 的关键不在背命令，而在于建立“版本管理”的心智模型。你始终要知道自己正在哪个工作区、改了哪些东西、哪些进了暂存区、最近一次提交长什么样、当前分支指向哪个提交。把这些位置关系理顺了，绝大多数操作都是顺水推舟的事。

最后再送大家一个很实用的建议：每天下班前，不管代码写到什么程度，尽量提交一次，或者至少git stash把现场收干净。别小看这个习惯，它能在第二天早上给你一个极其干净清爽的起点。有人担心“写到一半的代码提交上去太丢人”，其实 Git 的分支和本地提交本来就是给你自己用的，放心大胆地写，后续你随时可以在提交历史里找回任意一个瞬间的自己——这就是“会拍照的文档管家”最浪漫的地方。