软件开发新手必学版本控制工具入门指南
第三章 Git 基础操作 —— 单人开发的核心命令
版本控制的核心流程始终围绕“仓库”的生命周期展开。接手一个新项目时，第一步就是让Git正式接管代码目录。
创建仓库与首次提交
先看本地初始化场景。这相当于在项目根目录埋下一颗“版本种子”——Git会生成隐藏的.git文件夹，后续所有变更历史都存储于此。
操作极其直接：新建目录，切换进去，执行git init。用git status查看状态——全新仓库会提示“No commits yet”，并列出一堆未跟踪文件（Untracked files）。
另一种方式是克隆远程仓库，具体用法会在协作章节深入。简要来说，git clone 仓库地址就能把远程的完整项目连带所有历史提交拉取到本地。
有了空仓库，如何将代码纳入版本管理？以一个简单的Python项目为例：创建README.md和hello.py后，git status显示红色文件名，表示“未跟踪”。运行git add将文件移入暂存区，状态变为绿色。最后执行git commit -m "Initial commit: add README and hello.py"，完成首次提交。注意：提交信息务必简明扼要，日后回溯时会大幅提升效率。
使用git log查看，输出格式如下：
commit 3a7c8f9d2e1b4c5a6d7e8f9a0b1c2d3e4f5a6b7c (HEAD -> master)
Author: Your Name
每个commit拥有唯一的SHA-1哈希值，这是Git世界里每条历史记录的身份证。
文件的三种状态转换
Git的基础模型很清晰：文件在任一时刻，必然处于“已修改”、“已暂存”或“已提交”三种状态之一。掌握这三者之间的转换逻辑，就抓住了单人开发的核心操作。
git add将文件从“已修改”推入“已暂存”，相当于告诉Git“这些改动我打算纳入下一次提交”。git commit则把暂存区的所有改动正式写入仓库历史。如果想提速，直接用git commit -a -m "message"可跳过暂存环节，直接提交所有已跟踪文件的修改。
反向操作同样常用：git reset HEAD （或新版git restore --staged ）将暂存区的文件“撤回”，但保留工作区实际修改。而git checkout -- （或新版git restore ）会彻底丢弃工作区的改动——此操作不可撤销，务必确认后再执行。
git status 深入解析
这是每天调用频率最高的命令之一，但其输出信息远比表面丰富。典型输出如下：
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git restore --staged
它不仅清晰标明当前所在分支、是否与远程同步，还按状态将文件分为三组：已暂存待提交、已修改未暂存、完全未跟踪的新文件。每组下方附有操作提示命令，新手按提示执行即可完成对应操作。
git diff —— 查看修改细节
想精确了解每一行代码的变化？git diff是日常调试的必备命令。它有几个常用变体：
git diff比较的是工作区与暂存区之间的差异，即那些已修改但尚未git add的内容。
git diff --staged（或--cached）比较的是暂存区与最新提交的差异，即即将被提交的内容。
git diff HEAD则直接对比工作区与最新提交的差异。
更精细的场景——比如只看hello.py文件在两个版本前的改动：git diff HEAD~2 -- hello.py。输出会清晰标记增减行，例如：
diff --git a/hello.py b/hello.py
index 7c6a5b8..7f3e9c1 100644
--- a/hello.py
+++ b/hello.py
@@ -1,2 +1,3 @@
print('Hello World')
+print('Welcome to Git')
多出来的+号行，就是新增的代码。处理复杂项目时，还能用git difftool调用图形化对比工具，视觉上更直观。
git log —— 查看历史
git log是整个项目的编年史。最基础的用法就是直接敲，按时间倒序列出所有提交。不过实战中很少翻阅完整输出，以下几个参数更实用：
只显示一行摘要：git log --oneline
可视化分支拓扑：git log --graph --oneline --decorate --all
只看最近5条记录：git log -5
按作者筛选：git log --author="Your Name"
按提交信息关键词搜索：git log --grep="fix bug"
追踪单个文件的完整变更史：git log --follow hello.py
自定义输出格式，例如git log --pretty=format:"%h - %an, %ar : %s"，可展示短哈希、作者名、相对时间和提交信息，信息密度极高。
撤销与回退 —— 那些“后悔药”
Git的灵活性很大程度上源于丰富的“反悔”机制。以下几个高频场景，记住即可覆盖绝大多数单人开发需求。
场景一：提交后发现漏了文件或写错了说明。不必慌张，先git add forgotten_file添加遗漏文件，然后执行git commit --amend --no-edit，即可保留原有提交信息，将新文件追加进去。如需修改提交信息，使用git commit --amend -m "新的提交信息"。
场景二：想回退到某个历史版本。先用git log --oneline找到目标commit的哈希值，再根据需求选择模式：
--soft：仅移动HEAD指针，暂存区和工作区全部保留，仿佛从未发生过提交。--mixed（默认）：保留工作区修改，但清空暂存区，文件状态变为已修改。--hard：最激进的方式，直接丢弃后续所有修改（不可恢复，慎用！）。
例如回退到前两个提交：git reset --hard HEAD~2。
场景三：文件已经git add但后悔了。使用git reset HEAD 或新版git restore --staged 。
场景四：工作区修改了一半，想还原到原始内容。使用git checkout -- 或新版git restore 。
场景五：误删了提交或分支，但尚未彻底走远。Git提供“万能后悔药”——git reflog，它会记录你所有HEAD移动的历史。找到对应哈希值，然后git checkout 即可回到那个状态，或者用git branch recover-branch 创建一个新分支指向那个commit。
基础操作捋顺后，单人开发中的绝大多数场景都能应对自如。