周末学Git
绝大多数开发者其实并不真正理解 Git。他们背下五个命令（add、commit、push、pull、status），然后祈祷合并冲突永远别出现。结果某个周二的下午，他们在错误的分支上跑了一条 git rebase，一整周就这么没了。
好消息是：你不需要计算机科学学位才能掌握版本控制。你需要的是一个结构化的周末。接下来 48 小时，你会从"复制粘贴命令"进化到"真正理解驱动现代软件开发的那张有向无环图"。不谈废话，只给战术计划。想同时把配套的工程思维补全，可以看本站的逻辑思维训练。
为什么大多数 Git 教程会失败（以及这个周末计划不同在哪）
学 Git 的标准路径是读 Pro Git 那本书，或看 4 小时的视频。那是被动学习，到周一你已经忘了九成。
这个周末计划建立在"间隔式失败"之上。你要故意搞坏 Git：故意制造合并冲突、把 HEAD 弄到游离状态、丢掉提交。到周日晚上你会发现，几乎所有 Git 事故都是可恢复的——这才是信心的真正来源。
而且，前 24 小时我们完全不碰 GUI（图形界面）工具。像 SourceTree 或 GitHub Desktop 会藏掉底层机制。如果你只依赖 GUI，一旦要到没有界面的服务器上用 SSH 远程操作，就会抓瞎。先学命令行（CLI），GUI 之后就不必要了。
周六上午：核心循环（离不开的命令）
先忘掉分支策略、忘掉 CI/CD 流水线。周六上午的目标是理解"快照"模型。Git 不存"改动"（差异），它存的是整个项目的快照。
对多数人一讲就通的心智模型是这样的：
- 工作目录：你在编辑器里看到的文件。
- 暂存区（Index）：一个"临时停放区"，你在这里挑选下一次快照要包含哪些改动。
- 仓库（.git 文件夹）：存所有快照的数据库。
周六的训练：建一个叫 practice-repo 的文件夹，初始化它，建三个文本文件，一个个 add，一个个 commit。然后改一个文件，但只用 git add -p 只暂存其中一半的改动。这种交互式暂存是最被低估的、写出干净提交历史的技能。
练两小时，直到你不看小抄也能做。想加速这类"以练代学"的方法论，可以对照30 天学会 SQL——同一个"高频演练"思路用在数据分析上。
周六下午：分支与合并（可视化工作流）
分支不是"文件夹"。分支只是一个指向特定提交的可移动指针。你创建分支，其实就是创建了一个新指针。
"啊哈"时刻通常发生在你把它可视化的时候。用 git log --graph --oneline --all 看这棵树。你会看到分支分叉（fork）又汇合（merge）。
下午的训练是制造一场刻意的合并冲突。配方如下：
- 建一个叫
feature/login的分支。 - 在这个分支里改
index.html的第 10 行。 - 切回
main。 - 同样的第 10 行改成不同的文字。
- 把 feature 分支合并进 main。
看那条报错信息。然后打开文件，你会看到 <<<<<<< HEAD 和 >>>>>>> feature/login 这样的冲突标记。手动修好，再 git add 和 git commit。练到你觉得无聊为止。如果你能熟练解冲突，你已经领先 70% 的上班族开发者了。
周日上午：改写历史与远程协作
这里住着那些"吓人"的命令：rebase、reset、amend。避免丢数据的关键是记住"变基黄金规则"：永远不要对别人正在工作的分支做 rebase。
这个周末项目里，练下面这个序列：
- 做三次提交。
- 发现提交信息写得很烂。
- 用
git rebase -i HEAD~3把它们 squash（合并）成一条干净的提交。
接着进入远程协作。在 GitHub 或 Gitee 上建一个仓库，把你本地分支推上去。然后在你电脑上另一个文件夹 clone 一份，模拟一个队友。在 clone 里改东西、push，再 pull 回原文件夹。这就在不用第二个人在场的条件下，模拟出了多人协作的体验。
国内团队常用 Gitee（码云）来做托管，速度和访问更稳，流程和 GitHub 完全一致。如果你纠结"我的代码到底在哪"——一个常见的坎——那就先歇口气。核心原则其实和带队很像：要把工作流"解耦"，别让你的成员（或代码分支）互相踩脚。这一点可以从学习领导力里得到启发。
周日下午：真实工具与 GUI 客户端（对比）
现在你懂命令行，就可以不带依赖心理地去评估 GUI 工具了。下面是对 2026 年最热门工具的诚实对比，基于真实价格和实际工作流收益。
| 工具 | 适合 | 价格 | 优点 | 缺点 |
|---|---|---|---|---|
| GitHub Desktop | 想要零配置的新手 | 免费 | 界面简单，基础提交推送流程好用，适合学生 | 没有高级 rebase 工具，把 Git 内部藏得太深 |
| GitKraken | 喜欢看图的视觉学习者 | 免费版；Pro 约 420 元/年 | 可视图最强、内置合并冲突编辑器、跨平台 | 吃内存，付费版对独立开发者偏贵 |
| SourceTree | Atlassian 生态用户（Jira/Bitbucket） | 免费 | 复杂分支很强，和 Jira 工单集成好 | 界面偏旧偏笨，大仓库会卡 |
| Fork | Mac/Windows 高阶用户 | 试用后一次性约 350 元 | 快、界面干净、交互式 rebase 可视化出色 | 不支持 Linux，一次性付费吓退部分人 |
| VS Code（内置） | 本来就在用 VS Code 的开发者 | 免费 | 零切换、行内 blame 标注、内置终端 | 图表可视化受限，冲突解决界面偏基础 |
| GitLens（扩展） | "这行是谁写的"考古 | 免费版；Pro 约 320 元/年 | blame 标注无出其右、深度代码链接 | 它不是提交工具，是增强不是替代 |
我的结论：周末新手先用 GitHub Desktop 把基础搞定，再装 GitKraken（免费版）来看清你的分支。等有了信心，就把它们都丢掉回到终端。终端才是这个行业里唯一不变的东西。如果你主要用 Gitee 管理，这些客户端都能在设置里切换到码云。
实战项目：搭一个"周末维基"
别只做抽象练习，去搭一个真实的东西。建一个"周末维基"——一个记录你学习历程的简单 Markdown 文件。计划如下：
- 第一小时：建仓库，做一个叫
index.md的文件，提交你的目标。 - 第二小时：为每个学到的主题开一个分支（比如
topic/rebase），在每个分支里写笔记。 - 第三小时：把所有分支合并回 main，解掉必然出现的冲突（因为你大概率改了同一行标题）。
- 第四小时：推到 GitHub / Gitee，写一个 README，用
git tag v1.0标记你的第一次"发布"。
这个项目逼你把学到的所有命令在一个连贯流程里用起来，也给你一个可展示的成品——你确实会管理代码协作的证据。
如果你想把这套版本控制思维用到设计交接上，理解怎么给设计资产做版本管理很关键。可以参考快速上手 Figma——设计领域的版本思路和 Git 的快照模型惊人地相似。
常见问题
我不小心把提交放到了错误的分支，怎么撤销？
别慌。用 git log --oneline -1 拿到提交哈希。切到正确分支（git checkout 正确分支），再用 git cherry-pick <哈希> 把它拿过来。最后回到错误分支，git reset --hard HEAD~1 把那一跳挪走。这样就把提交搬对位置了。
git fetch 和 git pull 有啥区别？
fetch 会从远程把数据下载下来，但不会并进你的工作文件。pull 相当于 fetch + merge。经验规则：想先看看变了什么再决定要不要合并，就用 fetch，然后 git log origin/main 去检查。
我的合并冲突是个恶梦，能直接删分支重来吗？
还没推送的话可以。用 git merge --abort 中止合并，回到合并前的状态。已经推送了就得手动解决。可以借助 meld 或 kdiff3 这类外部工具做并排对比。
怎么从 Git 历史里彻底删掉一个文件？
你需要改写历史。用 git filter-repo（filter-branch 的现代替代品）。命令：git filter-repo --path 文件路径 --invert-paths。警告：这会改掉所有提交哈希，你必须强推（git push --force），而这会打破协作者本地的 clone。
在 AI 编程助手当道的时代，学 Git 还有意义吗？
绝对有。Copilot 这类 AI 生成代码，但它不管协作这一层。Git 追踪的是"某个改动为什么发生"。事实上，AI 生成越多代码，一份干净、可回退的历史就越关键——你得能精准回滚一条糟糕的 AI 建议，而不错伤其他无关工作。想把这套工程习惯长期铺开，先看本站的高效工作流习惯。