Pick the files you want in the next commit and stage them:

挑出要包含在下次提交里的文件，加入暂存区：

git add chapter-3.md
git add images/cover.png
git add .

The first two add specific files; the third adds every changed file in the current directory and below. git add -p opens an interactive prompt that lets you stage chunks of a file rather than the whole thing — useful when you have edited a single document for two unrelated reasons and want to commit them separately.

前两行添加指定文件；第三行添加当前目录及子目录下的所有变更。git add -p 会进入交互模式，允许按"块"暂存文件的一部分 —— 当你修改一个文件是出于两个不相关的原因、想分两次提交时，非常有用。

Command 4: commit — save the snapshot

命令 4：commit —— 保存快照

A commit takes whatever is staged and turns it into a permanent entry in the history. Always write a message explaining why, not just what:

commit 会把暂存区里的内容变成历史中永久的一笔。请始终写一段说明 为什么 这么改的注释，而不只是 改了什么：

git commit -m "Clarify the chapter 3 ending and add a transition paragraph"

A good commit message is a sentence in the imperative mood ("Fix typo", not "Fixed typo"). The first line should fit in 50 characters; longer explanations go after a blank line. Future you, reading the log in a year, will thank present you for being clear.

好的 commit 信息应当是祈使句（"Fix typo"而不是"Fixed typo"）。首行尽量不超过 50 个字符；更长的解释放在空行之后。一年后的你回看日志时，会感谢现在写得清晰的你。

Command 5: push — share your commits

命令 5：push —— 分享你的提交

Commits live on your machine until you push them to a remote:

commit 只会保存在本地，要推送到远程才会被共享：

git push origin main

This sends your new commits on the main branch to the origin remote. After the first push of a branch, the modern shorthand is simply git push (Git remembers the upstream). Push regularly — the value of version control is multiplied when others (or future you on another device) can see your work.

这条命令把你 main 分支上的新提交推送到 origin 远程。首次推送某个分支后，更简洁的写法是 git push（Git 会记住上游）。请养成经常推送的习惯 —— 当别人（或另一台设备上的你）能看到你的工作时，版本控制的价值才真正放大。

Command 6: pull — get the latest

命令 6：pull —— 拉取最新

Before you start editing, sync with the remote:

开始编辑前，先与远程同步：

git pull

A pull is two operations: first fetch (download new commits from the remote) and then merge or rebase them into your local branch. The default behavior is fine. If you have uncommitted local changes, git will either merge them automatically or refuse until you commit or stash them.

pull 其实是两步：先 fetch（从远程下载新提交），再 merge 或 rebase 合并到你的本地分支。默认行为一般就够用。如果你有未提交的本地修改，git 会自动合并，或者在必要时拒绝并提示你先提交或暂存。

Command 7: log — see the history

命令 7：log —— 查看历史

git log lists commits from newest to oldest, each with its hash, author, date, and message. For a one-line-per-commit view:

git log 按从新到旧列出提交，每条包含哈希、作者、日期和信息。只需要一行展示时：

git log --oneline

For a graphical view of branches and merges:

想看到分支和合并的图形化视图：

git log --oneline --graph --all

To see exactly which lines changed in a commit, add -p (or --patch). To see who last touched each line of a file, use git blame file. To find a commit by content, git log -S "phrase" searches the diffs for a specific string.

想看某次提交具体改了哪些行，加 -p（或 --patch）。想看文件的每一行最后是谁改的，用 git blame file。想按内容搜提交，用 git log -S "phrase" 在 diff 中查找特定字符串。

Command 8: diff — compare two states

命令 8：diff —— 比较两种状态

git diff shows unstaged changes. git diff --staged shows changes that are staged but not yet committed. git diff branch-a..branch-b shows what would change if you merged one branch into another. The diff format is the same in every git tool: removed lines prefixed with -, added lines prefixed with +, context lines unmarked. Once you can read a diff, you can read a patch — and most code review happens through diffs.

git diff 显示未暂存的变更；git diff --staged 显示已暂存但未提交的变更；git diff branch-a..branch-b 显示把一个分支合到另一个分支会发生什么。diff 格式在所有 git 工具中都是一致的：删除行以 - 开头，新增行以 + 开头，上下文行无前缀。一旦你能读懂 diff，就能读懂 patch —— 大多数代码评审都是通过 diff 完成的。

Command 9: branch — work in parallel

命令 9：branch —— 并行工作

A branch lets you work on something without disturbing the main line. To create a branch and switch to it:

分支让你在不打扰主线的情况下做新工作。创建并切换到一个新分支：

git switch -c new-chapter

The older git checkout -b new-chapter still works, but switch (introduced in Git 2.23) is clearer about intent. From here, every commit you make lives only on new-chapter until you merge it back. When the work is ready:

旧写法 git checkout -b new-chapter 仍可用，但 switch（Git 2.23 引入）意图更清晰。从这一刻起，你的所有提交只存在于 new-chapter 分支，直到被合并回去。工作完成后：

git switch main
git merge new-chapter

For a non-code example: imagine a writer working on chapter 5 of a book. They create a branch draft/chapter-5, write freely, commit as they go, and only merge back to main when the chapter is reviewed. The other chapters stay untouched in the meantime, and if the writer decides the chapter is a dead end, they delete the branch and main is unaffected.

举一个非代码的例子：一位作者在写书的第 5 章。他创建一个 draft/chapter-5 分支，自由地写作并随时提交，只有在章节审过后才合并回 main。期间其他章节保持不变；如果作者决定这章是死胡同，删掉这个分支即可，main 不受影响。

Command 10: switch / checkout — move around

命令 10：switch / checkout —— 在分支间切换

To jump to an existing branch:

跳转到已有分支：

git switch main

To jump to an older commit (in "detached HEAD" state, useful for inspection):

跳转到某个旧提交（进入"分离 HEAD"状态，常用于查看）：

git switch --detach a1b2c3d4

To abandon changes in a single file and revert it to the last committed version:

放弃对单个文件的修改，恢复到最近一次提交的样子：

git restore chapter-3.md

The restore command (also from Git 2.23) finally gives a clear name to "undo my changes to this file". Before restore, the same operation was a confusing git checkout -- chapter-3.md that overloaded checkout for several different jobs.

restore 命令（同样来自 Git 2.23）终于给了"撤销我对这个文件的修改"一个明确的名字。在此之前，同样的操作要用含义模糊的 git checkout -- chapter-3.md —— 一个 checkout 命令身兼数职。

How to undo things safely

安全地撤销操作

Three rules save you from disaster. First, before any "scary" command, run git status and git log --oneline -5 to remind yourself where you are. Second, when in doubt, make a commit or a branch before changing anything — "save points" are cheap. Third, remember that almost nothing in git is truly destructive. Commits you "deleted" can be found in the reflog for 30+ days; commits you "lost" on a branch can be retrieved by their hash. The worst-case "I rewrote history and lost my work" is exceedingly rare and almost always recoverable.

有三条规则能让你远离灾难。第一，在跑任何"危险"命令之前，先跑 git status 和 git log --oneline -5 提醒自己身在何处。第二，拿不准时，先做一个 commit 或建一个分支再动手 —— "存档点"几乎零成本。第三，记住：git 里几乎没有真正不可逆的操作。你"删除"的提交会在 reflog 里保留 30 天以上；分支上"丢失"的提交可以通过哈希找回。最坏情况"我重写了历史并丢失了工作"极为罕见，而且几乎总能恢复。

Some undo patterns worth memorizing: git restore file throws away local changes. git commit --amend edits the most recent commit (message or contents). git revert hash creates a new commit that undoes an older one — the safe way to undo something already pushed. git reset --soft HEAD~1 undoes the last commit but keeps the changes staged. git reset --hard HEAD~1 throws away the last commit and its changes (only do this on unpushed work).

下面这些"撤销套路"值得记住：git restore file 丢弃对某个文件的本地修改；git commit --amend 修改最近一次提交（信息或内容）；git revert hash 创建一个新提交来撤销旧提交 —— 是撤销已推送内容的安全方式；git reset --soft HEAD~1 撤销最近一次提交，但保留修改并保持暂存；git reset --hard HEAD~1 丢弃最近一次提交及其修改（仅适用于未推送的工作）。

When to use a GUI instead

什么时候该用 GUI 工具

The command line is the most precise, but GUI clients are often more forgiving for visual tasks. GitHub Desktop, GitKraken, Sourcetree, and the git integration inside VS Code all show branches, diffs, and merge conflicts graphically. A conflict — when two people edited the same lines of the same file — is dramatically easier to resolve with a visual merge tool than by reading conflict markers <<<<<<< in a terminal.

命令行最精确，但 GUI 客户端在可视化任务上往往更友好。GitHub Desktop、GitKraken、Sourcetree，以及 VS Code 内置的 Git 集成，都能图形化地展示分支、diff 和合并冲突。当冲突发生 —— 两个人改了同一文件的同一行 —— 用可视化合并工具比在终端里读 <<<<<<< 标记要轻松得多。

A sensible workflow: use the command line for the everyday edit-add-commit-push cycle (it is faster once you have the muscle memory), and reach for a GUI when you need to understand a tangled history, resolve a tricky conflict, or bisect to find which commit introduced a bug.

一个合理的实践方式：日常的"编辑-暂存-提交-推送"循环用命令行（一旦形成肌肉记忆会更快）；当需要理清复杂历史、解决棘手冲突、或用二分法定位引入 Bug 的提交时，再切到 GUI。

A non-code use case: writing a book in git

一个非代码场景：在 Git 中写一本书

Many authors now write books in plain text (Markdown or AsciiDoc) tracked in git. The benefits are real: every revision is recoverable, drafts can be reviewed through pull requests, multiple co-authors can work in parallel without emailing chapter-3-FINAL-v2-actually-final.docx back and forth, and the publishing pipeline (build to PDF, ePub, HTML) lives in the same repository as the text.

许多作者现在用纯文本（Markdown 或 AsciiDoc）写书，并把文本放在 git 里管理。好处是实实在在的：每个版本都可恢复；草稿可以通过 pull request 评审；多个合著者可以并行工作，不必再互发 chapter-3-FINAL-v2-actually-final.docx；出版流水线（构建 PDF、ePub、HTML）也跟正文放在同一个仓库里。

A typical book repository has a main branch for the published text, feature branches for each chapter in progress, and a drafts/ directory for experimental material. The author commits at the end of each writing session with messages like "End of day: tightened opening, ~200 words". When a reviewer suggests edits, they go in their own branch as suggested commits; the author merges the suggestions one at a time, with attribution preserved in the history.

一个典型的书稿仓库会有：main 分支保存已发布文本；每个正在写的章节一个 feature 分支；drafts/ 目录保存实验性内容。作者在每次写作结束时提交一次，信息形如 "今日收尾：开头更紧凑了，~200 字"。当审稿人提出修改建议时，他们在独立分支里以单独提交提交建议；作者一次合并一条建议，归属信息也完整保留在历史中。

The same pattern works for research notes, lesson plans, legal briefs, recipes, design specs, almost any text-based work. The shift is not from Word to git; it is from "files with names like v3" to "files with history". Once you make the shift, you will not want to go back.

同样的模式也适用于研究笔记、教案、法律意见、食谱、设计规范，几乎所有文本型工作。这不是从 Word 切换到 git，而是从"靠文件名后缀管理版本"切换到"文件自带历史"。一旦完成这个转变，你就再也不想回到过去。

Try the tools

试试这些工具

Git does not run in a browser, but a good text editor helps. Try the word counter and the text case converter for shaping your writing as you draft. Both run entirely in your browser, with nothing uploaded.

Git 本身无法在浏览器里运行，但一个趁手的文本编辑器能帮上忙。试试 字数统计 和 文本大小写转换 工具，在写作时随手调整内容。两者都完全在你的浏览器中运行，不会上传任何内容。