在平时的开发中，Git 是我们不可或缺的版本控制工具。这篇博客将结合我的实际终端操作，带你从零开始，深入掌握 Git 的文件追踪、版本回滚、分支管理以及最让人头疼的冲突解决。
一、 基础环境与仓库初始化
首先，如果你还没有安装 Git，可以前往 Git 官网下载最新的安装包：https://git-scm.com/download/win
https://git-scm.com/download/win 安装完成后，第一步需要做的就是设定你的用户名和邮箱，这相当于你在代码提交历史中的"身份证"，用来区分不同的用户，配置全局用户名和邮箱：
bash
git config --global user.name "Your Name" # 设置你的用户名 [cite: 303]
git config --global user.email "email@example.com" # 设置你的邮箱 [cite: 304]接着，我们可以将任意一个文件夹转化为 Git 仓库。进入目标文件夹，执行：
bash
git init执行后，会自动生成一个 .git 隐藏目录，这就是 Git 用来记录版本变化的核心文件夹，而当前目录就是我们的工作目录 。
创建成功后，我们可以查看一下当前的一个状态，输入：
bash
git status如果已经成功配置为Git本地仓库，那么输入后可以看到：
bash
On branch master
No commits yet这表示我们还没有向仓库中提交任何内容，也就是一个空的状态。
二、 文件的追踪、提交与忽略
1. 文件的状态转换 (Untracked -> Staged -> Committed)
当我们在目录中新建一个文件（例如 hello.txt），输入 git status，会看到它处于 Untracked files（未追踪状态）。这意味着 Git 目前不会记录它的任何变化 。
我们需要将其放入暂存区并提交：
添加暂存区：执行 git add hello.txt（如果文件多，可以用" git add . " 一次性添加全部）。此时文件变绿，变为 Changes to be committed 。
正式提交：执行 git commit -m 'Hello World' 将其提交到本地仓库，-m 后面必须跟着此次提交的描述 。
快捷提交修改 ：对于已经追踪过的文件，如果后续发生了修改，可以直接使用 git commit -a -m '提交描述' ，这会自动将已修改的文件放入暂存区并完成提交，省去手动 add 的步骤
2. 配置 .gitignore 忽略规则
开发中有些文件不需要提交（如日志、缓存文件）。我们可以创建一个 .gitignore 文件来配置忽略列表，只要文件没有被追踪过，Git 就会完全无视它们 。常用的匹配规则如下：
bash
*.txt # 匹配所有以 txt 结尾的文件 [cite: 351, 352]
!666.txt # 虽然上面排除了所有 txt，但这个 666.txt 不排除 [cite: 353, 354]
test/ # 忽略整个 test 文件夹下的所有内容 [cite: 355, 356]
xxx/*.txt # 忽略 xxx 目录中所有以 txt 结尾的文件，但不包括其子目录 [cite: 357, 358]
xxx/**/*.txt # 忽略 xxx 目录中所有以 txt 结尾的文件，包括所有子目录 [cite: 359, 360]三、 日志与回滚
1. 查看日志
想要理清各个分支和提交的关系，推荐使用这个组合命令：
bash
git log --all --graph --oneline这会以图形化、极其简洁的格式（仅显示 commit ID 前 7 位和描述）展示所有分支的提交历史，方便我们确认分支的分叉结构 。
2. 回滚 (Reset) 与反悔 (Reflog)
当我们想要回退到过去的某个版本时，可以执行硬重置：
git reset --hard commitID例如：git reset --hard bb64a15 命令执行后工作空间会直接恢复到那个提交时的状态，且之后的提交日志会消失 。
排坑要点： 如果你回滚后又后悔了怎么办？使用 git log 已经找不到未来的 ID 了。这时请使用 git reflog，它记录了你本地的所有操作记录（包括 reset 操作），你可以从中找到丢失的 commit ID，再次 reset 回去 。
四、 分支实战：创建、合并与冲突解决
分支就像树枝，可能一开始是同一根，但为了开发不同方向的项目(比如一个做 Web，一个做游戏服务端)，就会分叉，在不同分支下修改文件内容是相互隔离的，默认主干是master分支 。
1. 分支基础操作
创建新分支 ：
git branch test，我这里的test为分支名查看分支 ：
git branch，带*标记的即为当前所在分支切换分支 ：
git checkout test，我这里的test为分支名删除分支 ：
git branch -d test，我这里的test为分支名
2. 分支合并 (Merge) 与冲突修复
当我们在 test 分支上开发完毕（比如执行了 git commit -a -m 'Modify on test' ），需要将其合并到主干 master。
-
切换回合并目标分支：git checkout master 。
-
执行合并：git merge test 。
如果两个分支恰好修改了同一个文件的同一行代码，Git 会提示自动合并失败：
bash
Auto-merging hello.txt
CONFLICT (content): Merge conflict in hello.txt
Automatic merge failed; fix conflicts and then commit the result.这说明产生了冲突 。
如何手动解决冲突？
打开产生冲突的文件（如
hello.txt），会看到 Git 插入的标记 ：
<<<<<<< HEAD下方是你当前分支（master）的内容 。
=======是分割线 。
>>>>>>> test上方是待合并分支的内容 。
你需要人为判断保留哪些代码，删除多余的内容以及这三行特殊标记。修改完成后，执行提交来生成合并节点：
bash
git commit -a -m 'Mrege on conflict'此时通过 git log --all --graph --oneline 查看，会看到漂亮的 |\ 合并线，两分支的修改完美整合 。
五、 高阶玩法：变基 (Rebase) 与优选 (Cherry-pick)
除了 Merge 这种让分支回到主干的方式，我们还有其他整合代码的手段：
1. 变基 (Rebase)
变基是直接修改分支开始的位置 。例如我们希望将 test 变基到 master 上：
bash
git rebase master执行后，test 分支的起点会移动到 master 的最后一次提交位置，相当于同步了此前 master 分支的全部提交，让提交历史变成一条干净的直线，而不再有交叉的合并线 。
2. 优选 (Cherry-pick)
如果你并不想合并整个分支，只是垂涎隔壁分支刚刚提交的一个小功能（某一次单独的 commit），你可以使用优选操作：
bash
git cherry-pick <commit id>这可以单独将某一个特定的提交记录，精准地"复制"并作用于你当前所在的分支上 。
希望这份基于实操的详细整理对你有帮助！