使用 Claude Code 必备的前置基础知识 - 学习笔记-Claude Code-上海佼艾

一、概述：为什么需要学习这些前置知识

Claude Code 是一个运行在终端中的命令行 AI 编程助手。与传统的图形界面工具不同，Claude Code 没有"安装向导"也没有"下一步按钮"，所有的交互都通过键盘输入命令来完成。这意味着，如果你不了解终端的基本操作，不知道如何切换目录、如何运行命令，那么即使 Claude Code 功能再强大，你也无从下手。因此，掌握终端和 Shell 的基础操作，是使用 Claude Code 的第一道门槛。

更进一步，Claude Code 的核心能力之一就是与 Git 版本控制系统深度集成。当 Claude Code 分析你的代码时，它需要理解 Git 仓库的状态 -- 哪些文件被修改了、当前在哪个分支上、最近的提交历史是什么。当你要求 Claude Code 提交代码时，它实际上是在执行 Git 操作。如果你不理解 Git 的基本概念，就无法理解 Claude Code 在做什么，也无法在出现问题时自行排查。这就好比开车不懂仪表盘的意义，虽然车能跑，但你永远不知道什么时候该加油、什么时候该保养。

此外，Claude Code 的许多高级功能，如 Worktree 隔离模式、PR 审查技能（/review），都直接建立在对 GitHub 工作流的深入理解之上。Worktree 让你能够在同一个仓库上同时处理多个任务，而 PR 审查则是团队协作中不可或缺的环节。如果你不了解这些概念，就无法充分利用 Claude Code 提供的这些强大功能，相当于买了一部高端智能手机却只用来打电话发短信。

本文的定位是面向刚参加工作的初级开发者。你可能在大学里学过一些编程知识，但实际工作中遇到的工具链和协作流程可能还是陌生的。我们将用最通俗的语言、最贴近实际场景的例子，帮助你建立起这些基础知识体系。无论你之前有没有接触过命令行，只要你愿意花时间跟着本文的示例一步步操作，你就能掌握使用 Claude Code 所需的一切前置技能。

最后需要强调的是，学习这些前置知识并不仅仅是为了使用 Claude Code。实际上，终端操作、Git 版本控制、GitHub 协作本身就是每一位软件工程师必备的核心技能。无论你以后使用什么工具、加入什么团队，这些知识都会陪伴你的整个职业生涯。学习 Claude Code 只是一个开始，而掌握基础工具将让你终身受益。

核心要点：Claude Code 是一个终端 AI 编程助手，所有操作都基于命令行和 Git 工作流。掌握终端、Shell、Git、GitHub 等前置知识，不仅是使用 Claude Code 的前提，也是每一位软件工程师的必备核心技能。本文用最通俗的方式带你入门。

二、终端与 Shell 基础

2.1 什么是终端和 Shell

很多初学者第一次打开命令行窗口时，面对黑色屏幕上闪烁的光标会感到不知所措。其实，理解终端和 Shell 的关系非常简单。我们可以用一个形象的类比：终端（Terminal）就像浏览器窗口，它是你看到的界面；而 Shell 就像浏览器引擎，是在后台真正执行工作的程序。终端负责显示输出、接收你的输入，而 Shell 负责解析你输入的命令并调用操作系统执行。

核心概念：终端 vs Shell

终端：一个用于与计算机交互的文本界面程序。在 Windows 上是命令提示符（CMD）或 Windows Terminal，在 macOS 上是 Terminal.app，在 Linux 上是各种终端模拟器。终端本身不做任何计算，它只是一个"窗口"。

Shell：一个命令解释器程序，它读取你输入的文本命令，将其转换为操作系统能理解的指令，并返回执行结果。常见的 Shell 有 Bash、Zsh、PowerShell 等。

工作流程：你在终端中输入命令 → 终端将命令传递给 Shell → Shell 解析并执行命令 → Shell 将结果返回给终端 → 终端显示结果给你看。

不同操作系统默认的 Shell 不同。Linux 和 macOS 默认使用 Bash（Bourne Again SHell），macOS 从 Catalina 版本开始默认使用 Zsh（Z Shell），它们都属于 Unix Shell 家族，语法非常相似。Windows 则默认使用 PowerShell，它是一个更现代、面向对象的 Shell。Claude Code 主要使用 Bash 语法，所以在 Windows 上使用 Claude Code 时，需要了解 Bash 和 PowerShell 的区别。

打开终端的方法也很简单。在 Windows 上，你可以按下 Win + X 然后选择"Windows Terminal"或"命令提示符"。在 macOS 上，按下 Cmd + 空格搜索"Terminal"即可。在 VS Code 中，你也可以通过 Ctrl + ` 快捷键打开内置终端。初次打开时，你可能会看到一个 `$`（Linux/macOS）或 `>`（Windows）符号，这就是 Shell 等待你输入命令的提示符。

新手提示：不要害怕命令行

很多初学者觉得命令行很可怕，担心输错命令会"弄坏电脑"。实际上，绝大多数日常命令都是安全的，最多只会提示"命令未找到"或"文件不存在"。而且，即使真的出了错，Git 也能帮你恢复大部分代码变更。建议你大胆尝试，多敲多练，这是最快的学习方式。

2.2 常用 Shell 命令

下面我们列出文件操作中最常用的一组命令。对于每个命令，我们会给出它在 Bash（Linux/macOS）和 PowerShell（Windows）中的写法，以及对应的示例。你可以对比着学习。

操作	Bash 命令	PowerShell 命令	说明
列出文件	`ls`	`Get-ChildItem`（别名 `ls`、`dir`）	显示当前目录下的所有文件和文件夹
切换目录	`cd 目录名`	`Set-Location`（别名 `cd`）	进入指定目录
查看当前路径	`pwd`	`Get-Location`（别名 `pwd`）	显示当前所在的完整路径
创建目录	`mkdir 目录名`	`New-Item -ItemType Directory`（别名 `mkdir`）	创建新的文件夹
复制文件	`cp 源文件目标`	`Copy-Item`（别名 `cp`、`copy`）	复制文件到指定位置
移动文件	`mv 源文件目标`	`Move-Item`（别名 `mv`、`move`）	移动文件或重命名
删除文件	`rm 文件名`	`Remove-Item`（别名 `rm`、`del`）	删除指定文件（谨慎使用！）
查看文件内容	`cat 文件名`	`Get-Content`（别名 `cat`、`type`）	显示文件内容到终端

下面我们通过一个实际场景来演示这些命令的用法。假设你要创建一个项目目录并初始化一个文件：

# Bash 示例：创建项目目录并进入
mkdir my-first-project
cd my-first-project

# 查看当前路径
pwd
# 输出: /home/username/my-first-project

# 创建一个 README.md 文件并查看内容
echo "# 我的第一个项目" > README.md
cat README.md
# 输出: # 我的第一个项目

# 列出目录中的文件
ls
# 输出: README.md

# 复制文件
cp README.md README-backup.md
ls
# 输出: README.md  README-backup.md

在使用这些命令时，有几点需要特别注意。首先，删除操作是不可逆的，`rm` 或 `del` 命令不会把文件放入回收站，而会直接永久删除。其次，Bash 中的路径使用正斜杠 `/`（如 `/home/user/project`），而 Windows 传统上使用反斜杠 `\`（如 `C:\Users\project`），但在 PowerShell 中两者都可以接受。最后，大多数命令都支持 Tab 键自动补全，输入命令或路径的前几个字符后按 Tab 即可自动补全，这是提高效率的最重要技巧之一。

2.3 环境变量

环境变量是存储操作系统和应用程序配置信息的"全局变量"。你可以把它们理解为操作系统的"便签纸"，上面记录了各种有用的信息，比如系统文件放在哪里、用户的个人目录在哪里、API 密钥是什么等等。当你在终端中运行一个命令时，Shell 会查找环境变量来确定去哪里找对应的程序。

核心概念：PATH 环境变量

PATH 是最重要的环境变量之一。当你输入一个命令（如 git 或 node）时，Shell 会遍历 PATH 中列出的所有目录，查找是否存在同名的可执行文件。如果 PATH 中没有包含 Git 的安装目录，即使你已经安装了 Git，终端也会提示"命令未找到"。这就是为什么很多工具安装完成后需要"配置环境变量"的原因。

对于 Claude Code 来说，最重要的环境变量是 ANTHROPIC_API_KEY。Claude Code 需要通过这个 API 密钥来验证你的身份并调用 Claude API。你可以在终端中临时设置环境变量，也可以将其永久配置到系统配置文件中。临时设置只在当前终端会话中生效，关闭终端后就会失效。永久设置则会将变量写入配置文件，每次打开新终端都会自动加载。

# Bash 中临时设置环境变量
export ANTHROPIC_API_KEY="你的API密钥"

# 查看环境变量
echo $ANTHROPIC_API_KEY

# PowerShell 中临时设置环境变量
$env:ANTHROPIC_API_KEY = "你的API密钥"

# 查看环境变量
echo $env:ANTHROPIC_API_KEY

新手提示：API 密钥安全

API 密钥就像你的密码一样重要。千万不要把它硬编码在代码中，也不要在公开仓库中提交包含密钥的文件。建议使用环境变量来管理密钥，或者使用 .env 文件（确保已添加到 .gitignore 中）来管理。如果你不小心将密钥提交到了 Git 仓库，请立即到 API 管理后台撤销该密钥并重新生成。

要永久设置环境变量，在 Bash 中可以将 `export` 语句添加到 `~/.bashrc` 或 `~/.zshrc` 文件中（取决于你使用的 Shell）。在 PowerShell 中，可以通过系统设置中的"编辑环境变量"界面来添加，或者使用 PowerShell 配置文件。无论哪种方式，设置完成后都需要重启终端或执行 `source ~/.bashrc` 使配置生效。

章节小结

终端是你与计算机交互的窗口，Shell 是解释命令的引擎。掌握 ls、cd、pwd、mkdir、cp、mv、rm、cat 这八个核心命令，就能完成绝大多数文件操作。环境变量是系统全局配置的关键，特别是 PATH 变量决定了能否找到可执行程序，而 ANTHROPIC_API_KEY 则是使用 Claude Code 的钥匙。建议你打开终端，把上面的命令逐个敲一遍，亲身体验每个命令的效果。

三、Bash Shell 详解

3.1 Bash 基础

Bash（Bourne Again SHell）是 Linux 和 macOS 系统上最流行的 Shell，也是 Claude Code 在非 Windows 系统上的默认运行环境。Bash 不仅仅是执行命令的工具，它本身是一门完整的编程语言，支持变量、条件判断、循环、函数等编程特性。即使你主要在 Windows 上开发，了解 Bash 也是非常有价值的，因为大多数服务器、云平台和 CI/CD 系统都运行在 Linux 上。

Bash 中有几个非常重要的操作符，它们是提高命令行效率的关键。首先是管道符 `|`，它可以将前一个命令的输出作为后一个命令的输入，实现命令的串联。例如，如果你用 `ls` 列出了很多文件，但只想看其中包含"test"的文件，可以这样写：

# 管道符示例：列出包含 "test" 的文件
ls | grep test

# 更复杂的管道：统计当前目录下的文件数量
ls -l | grep "^-" | wc -l

# 管道链：查看 Git 历史中最近的 3 条提交记录
git log --oneline | head -3

其次是重定向符。`>` 用于将命令的输出写入文件（会覆盖原有内容），`>>` 用于追加内容到文件末尾（不会覆盖）。这两个符号在日常开发中使用频率极高，比如将编译日志保存到文件、将命令结果导出为报告等。

# 重定向示例
# 将文件列表保存到文件（覆盖）
ls > file-list.txt

# 追加内容到文件（不覆盖）
echo "新增一行内容" >> file-list.txt

# 将错误信息重定向到文件
gcc main.c 2> error.log

最后是通配符 `*` 和 `?`。`*` 匹配任意长度的任意字符，`?` 匹配单个任意字符。这在批量操作文件时非常有用。例如，`rm *.tmp` 可以删除所有 `.tmp` 结尾的文件，`mv report-2026-??-??.txt archive/` 可以将所有日期格式的报告移动到归档目录。

# 通配符示例
# 列出所有 .html 文件
ls *.html

# 删除所有 .log 文件（谨慎！）
rm *.log

# 匹配单个字符：如 a1.txt, a2.txt 等
ls a?.txt

3.2 Bash 脚本基础

当你需要重复执行一系列命令时，手动逐条输入显然效率太低。这时就可以编写 Bash 脚本 -- 将多个命令写入一个文件，然后一次性执行。Bash 脚本通常以 `.sh` 为扩展名，第一行以 `#!/bin/bash` 开头，这行称为 shebang，告诉系统使用哪个解释器来执行这个脚本。

下面我们来看一个实用的 Bash 脚本示例。这个脚本用于检查当前 Git 仓库的状态，并在发现问题时给出提示。即使你现在还不熟悉 Git 的细节，也可以先感受一下 Bash 脚本的语法风格。

#!/bin/bash
# 文件名: check-git-status.sh
# 功能: 检查 Git 仓库状态并给出建议

# 变量定义
REPO_NAME=$(basename `pwd`)
BRANCH=$(git branch --show-current)
DIRTY=$(git status --porcelain)

echo "===== 仓库检查报告 ====="
echo "仓库名称: $REPO_NAME"
echo "当前分支: $BRANCH"

# 条件判断：检查是否有未提交的更改
if [ -z "$DIRTY" ]; then
    echo "✓ 工作目录是干净的"
else
    echo "✗ 你有未提交的更改!"
    echo "更改数量: $(echo "$DIRTY" | wc -l)"

    # for 循环：列出所有更改的文件
    echo "更改文件列表:"
    git status --short
fi

# 函数定义：检查是否有未推送的提交
check_unpushed() {
    local unpushed=$(git log origin/$BRANCH..HEAD 2>/dev/null)
    if [ -n "$unpushed" ]; then
        echo "⚠ 你有未推送的提交 ($(echo "$unpushed" | wc -l) 条)"
    else
        echo "✓ 所有提交已推送"
    fi
}

# 调用函数
check_unpushed

Bash 脚本的核心语法包括：变量赋值（`变量名=值`，等号两边不能有空格）、变量引用（`$变量名` 或 `${变量名}`）、条件判断（`if-then-else-fi`）、循环（`for`、`while`）和函数定义（`function_name() { ... }`）。有了这些基础知识，你就可以编写各种自动化脚本来提高工作效率了。

3.3 常用配置

Bash 的行为可以通过配置文件来定制。最重要的配置文件有三个：`~/.bashrc`、`~/.bash_profile` 和 `~/.zshrc`（如果你使用 Zsh）。`~/.bashrc` 在每次打开新的终端窗口时都会执行，通常用于设置别名、环境变量和提示符样式。`~/.bash_profile` 仅在登录 Shell 时执行一次。Zsh 用户则使用 `~/.zshrc`。

最常见的配置是设置别名（alias）。别名可以让长命令变短，大大提高输入效率。例如，很多开发者会将 `git status` 设置为别名 `gs`，将 `git pull` 设置为 `gp`。

# 在 ~/.bashrc 或 ~/.zshrc 中添加别名

# Git 别名
alias gs='git status'
alias ga='git add'
alias gc='git commit'
alias gp='git push'
alias gl='git log --oneline --graph'
alias gb='git branch'

# 通用别名
alias ll='ls -lah'
alias la='ls -A'
alias ..='cd ..'
alias ...='cd ../..'

# 危险操作的防护别名
alias rm='rm -i'    # 删除前确认
alias cp='cp -i'    # 覆盖前确认
alias mv='mv -i'    # 覆盖前确认

除了别名，你还可以定制 Shell 的提示符。默认提示符通常只显示当前目录，但你可以让它显示更多信息，比如 Git 分支、命令执行时间等。这需要用到 `PS1` 环境变量。如果你使用 Zsh，还可以安装 Oh My Zsh 等框架来获得开箱即用的漂亮提示符和丰富的插件。

# 定制 Bash 提示符（显示用户名、主机名、目录和 Git 分支）
export PS1='\u@\h:\w$(__git_ps1 " (%s)")\$ '

# 更简洁的选项
export PS1='\[\e[32m\]\w\[\e[0m\]\$ '  # 绿色路径 + $ 符号

新手提示：我的第一个别名

如果你刚开始接触配置，建议从最简单的开始。先添加一个别名试试：在 ~/.bashrc 或 ~/.zshrc 末尾添加一行 alias ll='ls -lah'，然后执行 source ~/.bashrc（或重新打开终端）。此时输入 ll 可以看到详细的文件列表，比单纯的 ls 好用得多。每次添加新别名后，别忘了执行 source 命令使配置立即生效。

章节小结

Bash 是开发者的核心工具之一。管道 | 和重定向 > 让命令组合变得无比灵活，通配符让你能批量操作文件，而脚本则能将重复工作自动化。配置文件（.bashrc 等）是定制个人开发环境的关键，别名设置可以极大地提高日常操作效率。花一些时间配置好你的 Shell 环境，是值得的长期投资。

四、PowerShell 基础

4.1 PowerShell 的特点

PowerShell 是微软开发的现代化 Shell 环境，预装在 Windows 系统中。与传统的 Bash 最大的不同在于，PowerShell 的管道传递的是对象（Object）而非纯文本。这意味着当你使用 `ls` 列出文件时，每个文件不是一个字符串，而是一个包含名称、大小、修改日期等属性的对象。你可以像操作数据库一样，对这些对象进行筛选、排序、分组等操作，无需进行繁琐的文本解析。

PowerShell 的另一个显著特点是命令的动词-名词命名规范。所有命令都采用 `动词-名词` 的格式，比如 `Get-ChildItem`（获取子项）、`Set-Location`（设置位置）、`Remove-Item`（移除项目）。这种命名方式非常直观 -- 看到命令名称就能猜到它的大致作用。当然，为了照顾从 Bash 迁移过来的用户，PowerShell 为大多数常用命令都提供了别名，比如 `ls`、`cd`、`rm` 等都可以直接使用。

PowerShell 的版本管理也非常方便。你可以通过 `$PSVersionTable` 变量查看当前 PowerShell 的版本信息。Windows 10 及以上版本默认安装了 PowerShell 5.1，而 PowerShell 7+ 是跨平台版本，可以在 Windows、macOS 和 Linux 上运行。建议在 Windows 上安装 PowerShell 7，因为它兼容性更好，功能也更强大。

4.2 常用命令

实际使用中，你大多时候会使用 PowerShell 提供的别名来操作，这样感觉上和 Bash 差别不大。但理解背后的真正命令名称和 PowerShell 的特有语法，在编写脚本时会非常有帮助。下面我们对照 Bash 和 PowerShell 的写法来学习。

操作	Bash 写法	PowerShell 写法
列出文件	`ls -la`	`Get-ChildItem -Force` 或 `ls -Force`
切换目录	`cd /path/to/dir`	`Set-Location /path/to/dir` 或 `cd /path/to/dir`
查看文件内容	`cat file.txt`	`Get-Content file.txt` 或 `cat file.txt`
环境变量	`echo $PATH`	`$env:PATH`
设置环境变量	`export KEY="value"`	`$env:KEY = "value"`
创建目录	`mkdir newdir`	`New-Item -ItemType Directory -Name newdir` 或 `mkdir newdir`

PowerShell 中的环境变量操作与 Bash 有较大区别。在 PowerShell 中，环境变量通过 `$env:` 前缀来访问。例如，读取 PATH 变量使用 `$env:PATH`，设置临时环境变量使用 `$env:MY_VAR = "value"`。这种语法比 Bash 的 `export` 更直观，因为 `$env:` 明确标识了这是一个环境变量，而非普通变量。

# PowerShell 中操作环境变量

# 查看 PATH 环境变量
$env:PATH

# 临时设置 API Key
$env:ANTHROPIC_API_KEY = "sk-ant-xxx"

# 检查变量是否存在
if ($env:ANTHROPIC_API_KEY) {
    Write-Host "API Key 已设置" -ForegroundColor Green
} else {
    Write-Host "API Key 未设置" -ForegroundColor Red
}

# 通过管道进行对象筛选（显示所有超过 1MB 的文件）
Get-ChildItem -Recurse | Where-Object { $_.Length -gt 1MB } | Sort-Object Length -Descending

注意上面最后一个命令使用了 PowerShell 的对象管道。`Get-ChildItem` 返回文件对象，`Where-Object` 筛选出大小大于 1MB 的对象，`Sort-Object` 按大小降序排列。在 Bash 中完成同样的功能需要借助 `find`、`awk` 等外部工具，而 PowerShell 用统一的语法就能搞定。

4.3 脚本基础

PowerShell 脚本以 `.ps1` 为扩展名。与 Bash 脚本相比，PowerShell 脚本的语法更接近传统的编程语言（如 C# 或 Python），对于有编程经验的人来说更容易上手。PowerShell 中的变量统一以 `$` 开头，不需要像 Bash 那样区分 `$var` 和 `var` 的引用方式。

# check-git-status.ps1 -- PowerShell 版本的仓库检查脚本

# 变量定义（注意 $ 前缀）
$repoName = Split-Path -Leaf (Get-Location)
$branch = git branch --show-current
$status = git status --porcelain

Write-Host "===== 仓库检查报告 =====" -ForegroundColor Cyan
Write-Host "仓库名称: $repoName"
Write-Host "当前分支: $branch"

# 条件判断（语法与 C 语言相似）
if (-not $status) {
    Write-Host "✓ 工作目录是干净的" -ForegroundColor Green
} else {
    Write-Host "✗ 你有未提交的更改!" -ForegroundColor Red

    # foreach 循环
    $status -split "`n" | ForEach-Object {
        Write-Host "  $_"
    }
}

# 函数定义
function Check-Unpushed {
    try {
        $unpushed = git log origin/$branch..HEAD 2>$null
        if ($unpushed) {
            Write-Host "⚠ 你有未推送的提交" -ForegroundColor Yellow
        } else {
            Write-Host "✓ 所有提交已推送" -ForegroundColor Green
        }
    } catch {
        Write-Host "⚠ 无法检查推送状态（可能没有远程分支）" -ForegroundColor Yellow
    }
}

# 调用函数
Check-Unpushed

对比上方的 Bash 版本和 PowerShell 版本，你会发现它们的逻辑结构几乎相同，但语法细节有差异。Bash 使用 `if [ -z "$var" ]`，PowerShell 使用 `if (-not $var)`；Bash 的函数不需要关键字，PowerShell 使用 `function` 关键字。如果你已经熟悉了一种，学习另一种时会很快上手。

4.4 跨平台注意事项

使用 Claude Code 时，一个常见的困惑是：Claude Code 默认使用 Bash 语法来执行命令，即使在 Windows 上也是如此。这意味着当 Claude Code 要创建一个目录时，它可能会使用 `mkdir -p` 这样的 Bash 命令，而不是 PowerShell 的 `New-Item`。这就引出了一个重要的问题：在 Windows 上使用 Claude Code 时，你需要了解 Bash 和 PowerShell 之间的差异。

另一个需要注意的问题是路径分隔符。Windows 传统上使用反斜杠 `\`，但 Claude Code 和 Bash 使用正斜杠 `/`。好消息是，现代 Windows 系统和 PowerShell 已经完全支持正斜杠，所以你可以在绝大多数场合直接使用正斜杠。例如，你可以用 `cd D:/projects/my-app` 来切换到项目的目录。

新手提示：Windows 上使用 Claude Code 的最佳实践

在 Windows 上使用 Claude Code 时，推荐使用 Git Bash（随 Git 安装提供）来执行命令，这样 Bash 语法可以原生支持。也可以使用 Windows Terminal + WSL（Windows Subsystem for Linux）获得完整的 Linux Shell 体验。如果你必须使用 PowerShell，请注意 Claude Code 可能会输出 Bash 格式的命令，你需要理解其含义并做适当的转换。

总结来说，无论是在哪种平台上使用 Claude Code，核心原则是一样的：理解你正在使用的命令的功能，而不是盲目复制粘贴。当你看到 Claude Code 输出一个 `git commit -m "message"` 命令时，即使你不熟悉 Bash，你也应该能理解这行命令的作用是提交代码。理解命令的目的，比理解命令的语法更重要。

章节小结

PowerShell 是 Windows 上的原生 Shell，以面向对象管道和动词-名词命名规范为特色。日常操作中你大多使用别名，感受上和 Bash 差别不大。关键区别在于：环境变量使用 $env: 前缀，脚本使用 .ps1 扩展名，管道传递的是对象而非文本。使用 Claude Code 时，默认采用 Bash 语法，在 Windows 上建议使用 Git Bash 或 WSL 来获得最佳体验。

五、Git 版本控制基础

5.1 什么是 Git

Git 是当今世界上最流行的分布式版本控制系统，由 Linux 的创始人 Linus Torvalds 在 2005 年创建。版本控制系统的核心功能是"记录文件的每次修改"，让你能够随时回顾历史、比较差异、甚至是回到任意一个历史版本。它就像是代码的"时间机器"。

类比：Git 就像游戏存档

想象你在玩一款复杂的角色扮演游戏。每当你完成一个重要任务或到达一个新区域时，你都会手动保存一下进度。如果你在后续的探索中走错了路或者做出了错误的选择，只需读取之前的存档就能回到那个安全的节点重新开始。Git 的工作原理与此非常相似：每次 git commit 就相当于一次"存档"；你可以随时查看所有的"存档列表"（git log）；如果出了问题，可以"读档"回到任何一个存档点（git checkout 或 git reset）。

除了"时光回溯"的能力，Git 还有一个极其重要的功能 -- 分支（Branch）。分支让你可以在不影响主线代码的情况下，开辟一个"平行宇宙"进行实验性开发。想象一下，你想给项目添加一个新功能，但这个功能可能需要进行大量修改、甚至有失败的风险。如果直接在主代码上修改，万一改坏了所有同事都会受影响。这时你创建一个分支，在分支上安心开发，等完全测试好了再合并回主线 -- 这就是分支的魅力所在。

Git 的"分布式"特性意味着每个开发者本地都有一份完整的代码仓库历史。你不需要一直连接着服务器，可以在本地自由地提交、创建分支、查看历史。当你准备好时，再通过 `git push` 将本地的更改同步到远程服务器。这种设计使得 Git 非常快 -- 绝大多数操作都在本地完成，不需要网络请求。

5.2 核心概念

要理解 Git，首先需要掌握几个核心概念。它们就像 Git 世界中的"基本粒子"，理解了它们，整个 Git 体系就豁然开朗了。

仓库（Repository）

仓库是 Git 管理项目的基本单位。每个仓库包含项目的所有文件和完整的版本历史。你可以把仓库想象成一个特殊的文件夹，这个文件夹里的所有文件都被 Git "监视"着，任何修改都会被记录。一个项目通常对应一个仓库。在项目根目录下执行 git init 就可以创建一个新的仓库，此时会生成一个隐藏的 .git 文件夹，所有的版本信息都存在这里面。

提交（Commit）

提交是 Git 中最基本的操作，相当于一次"存档"或"快照"。每次提交都会生成一个唯一的哈希值（如 a1b2c3d4...），用于标识这次提交。每次提交还包含作者信息、时间戳、提交信息（描述这次修改的内容）以及指向父提交的引用。提交信息是写给未来的自己和其他开发者看的，务必写得清晰明确。

分支（Branch）

分支是 Git 最强大的功能之一。它本质上是一个指向某个提交的可移动指针。默认分支通常叫 main（或 master）。创建新分支就像是复制了一份代码副本，你可以在这个副本上自由修改而不影响主分支。这对于多人协作开发至关重要。

工作区和暂存区

Git 将文件分为三个区域：工作区（Working Directory）是你实际编辑文件的地方；暂存区（Staging Area / Index）是提交前的"预览区"，你可以选择性地将某些修改加入暂存区；仓库（Repository）是已经提交保存的历史版本。工作流程是：在工作区修改文件 → 用 git add 将修改加入暂存区 → 用 git commit 将暂存区的内容提交到仓库。

5.3 常用命令

以下是 Git 最常用的命令，每个命令都配有实际示例。建议你打开终端跟着操作一遍。

git init -- 初始化仓库

# 在当前目录创建一个新的 Git 仓库
cd /path/to/my-project
git init
# 输出: Initialized empty Git repository in /path/to/my-project/.git/

这会在当前目录下创建一个隐藏的 `.git` 文件夹，里面包含了仓库的所有配置和版本信息。一个项目只需要执行一次 `git init`。

git clone -- 克隆远程仓库

# 从 GitHub 克隆一个仓库到本地
git clone https://github.com/username/repo.git

# 克隆到指定目录
git clone https://github.com/username/repo.git my-copy

# 克隆并指定分支
git clone -b develop https://github.com/username/repo.git

`git clone` 是获取远程代码的最常用方式。它会将整个仓库（包括所有历史记录和分支）下载到本地。

git add -- 暂存更改

# 暂存单个文件
git add index.html

# 暂存所有更改
git add .

# 暂存所有 .js 文件
git add *.js

# 交互式地选择要暂存的内容（推荐）
git add -p

`git add` 将工作区的修改加入暂存区。`-p` 参数尤其有用，它可以让你逐块确认是否要暂存，避免了不小心把调试代码也提交上去的尴尬。

git commit -- 提交更改

# 提交并添加提交信息
git commit -m "修复登录页面的样式bug"

# 跳过暂存区，直接提交所有已跟踪文件的修改
git commit -a -m "优化数据库查询性能"

提交信息是 Git 历史的重要组成部分。良好的提交信息应该简洁地说明"为什么"做这次修改，而不是"改了哪些文件"（后者可以通过 `git diff` 看到）。推荐的提交信息格式：第一行是标题（不超过50字），空一行后写详细说明。

git status -- 查看状态

# 查看工作区和暂存区的状态
git status

# 简洁模式输出
git status -s
# 输出示例:
#  M src/index.js    (已修改但未暂存)
# A  src/new.js      (已暂存)
# ?? test.log         (未跟踪的文件)

这是你使用最频繁的 Git 命令之一。它清晰地告诉你：哪些文件被修改了、哪些已经暂存了、哪些还没有被 Git 跟踪。养成频繁执行 `git status` 的习惯，可以让你对仓库的状态了如指掌。

git log -- 查看历史

# 查看提交历史
git log

# 一行显示一条提交（推荐）
git log --oneline

# 图形化显示分支历史
git log --oneline --graph --all

# 限制显示的条数
git log --oneline -5

git diff -- 查看差异

# 查看工作区与暂存区的差异
git diff

# 查看暂存区与最后一次提交的差异
git diff --staged

# 查看两个提交之间的差异
git diff commit1..commit2

git branch -- 分支管理

# 列出所有本地分支
git branch

# 创建新分支
git branch feature-login

# 删除分支
git branch -d feature-login

git checkout / git switch -- 切换分支

# 切换分支（传统方式）
git checkout feature-login

# 切换分支并创建（如果不存在）
git checkout -b feature-login

# 新式语法（Git 2.23+ 推荐）
git switch feature-login

# 创建并切换
git switch -c feature-login

从 Git 2.23 开始，官方推荐使用 `git switch` 和 `git restore` 来替代 `git checkout` 的部分功能，这样职责更清晰：`switch` 只管切换分支，`restore` 只管恢复文件。

git merge -- 合并分支

# 将 feature-login 分支合并到当前分支
# 先切换到目标分支（比如 main）
git switch main

# 然后合并
git merge feature-login

# 合并时生成合并提交信息
git merge feature-login -m "合并登录功能到主分支"

git pull -- 拉取远程更新

# 拉取远程更新并合并到当前分支
git pull origin main

# 相当于以下两条命令的组合:
# git fetch origin    (下载远程更新但不合并)
# git merge origin/main (合并远程分支)

git push -- 推送本地更改

# 推送本地分支到远程
git push origin main

# 首次推送新分支，建立跟踪关系
git push -u origin feature-login

# 之后就可以简写:
git push

5.4 Git 工作流

掌握了单个命令之后，更重要的是理解如何将这些命令串联成一个完整的工作流程。下面是一个标准的功能开发流程：

# 第一步：获取最新代码
git clone https://github.com/team/project.git
cd project

# 第二步：创建功能分支
git switch -c feature-add-search

# 第三步：开发编码...
# （修改文件、添加功能）

# 第四步：暂存和提交
git add .
git commit -m "添加搜索功能"

# 第五步：推送分支到远程
git push -u origin feature-add-search

# 第六步：在 GitHub 上创建 Pull Request
# （请同事审查代码）

# 第七步：审查通过后，合并到主分支
git switch main
git pull origin main    # 确保本地主分支是最新的
git merge feature-add-search
git push origin main

为什么需要分支开发？想象一下，你和另外两个同事同时在修改同一个项目。如果大家都在主分支上直接修改，那么你改到一半的代码可能会影响到其他人的工作。更糟糕的是，如果你改出了 bug，所有人都被迫使用这个有问题的版本。分支开发的核心思想是：主分支始终是可部署的健康状态，所有实验性开发都在独立的分支上进行，经过充分的测试和审查后再合并回主分支。

5.5 合并冲突解决

合并冲突是 Git 使用中最让人头疼但也必须面对的问题。当两个分支修改了同一文件的同一部分时，Git 无法自动判断应该保留哪个版本，于是就会产生冲突。此时 Git 会暂停合并，并在冲突文件中标记出冲突的区域，等待你手动解决。

// 合并冲突的文件内容示例 (index.js)
function greet(name) {
<<<<<<< HEAD
    return "Hello, " + name;
=======
    return "Hi there, " + name + "!";
>>>>>>> feature-greeting
}

在上面的例子中，`<<<<<<< HEAD` 和 `=======` 之间的是当前分支的代码，`=======` 和 `>>>>>>> feature-greeting` 之间的是被合并分支的代码。你需要手动编辑这个文件，删除冲突标记，决定保留哪个版本（或者组合两个版本）。解决后保存文件，然后 `git add` 标记为已解决，最后 `git commit` 完成合并。

# 解决冲突的完整流程

# 1. 尝试合并，遇到冲突
git merge feature-greeting
# 输出: Automatic merge failed; fix conflicts and then commit the result.

# 2. 查看哪些文件有冲突
git status
# 输出: both modified: index.js

# 3. 手动编辑 index.js 解决冲突，然后
git add index.js

# 4. 完成合并
git commit -m "解决 merge 冲突: 统一问候语格式"

对于 Claude Code 用户来说，一个好消息是 Claude Code 能够帮助你分析和解决合并冲突。你只需要让 Claude Code 读取冲突文件，它就能理解冲突的原因，并给出合理的解决方案。当然，最终的决定权还在你手上 -- 毕竟只有你才知道代码的正确逻辑是什么。

章节小结

Git 是每个开发者必须掌握的核心工具。核心概念包括：仓库（项目容器）、提交（快照）、分支（平行宇宙）、暂存区（预览区）。常用命令形成了完整的工作流：clone → branch → edit → add → commit → push → pull request。合并冲突虽然麻烦，但理解了本质（同一文件同一部分的修改冲突）后，解决起来并不复杂。Claude Code 也可以辅助解决冲突。建议每天都在终端中使用 Git，熟能生巧。

深入学习：Git 版本控制专题详解

本文是 Git 基础入门，如果你想更深入地学习 Git，包括核心概念精讲、高级技巧（rebase、cherry-pick、stash、bisect、reflog）、内部原理、分支策略、最佳实践等，请阅读专题文档：

👉 Git 版本控制专题详解

六、GitHub 与远程协作

6.1 GitHub 是什么

GitHub 是全球最大的代码托管平台，基于 Git 版本控制系统构建。如果把 Git 比作你的本地"代码保险箱"，那么 GitHub 就是云端"代码银行" -- 你可以在任何地方存取你的代码，与其他人共享和协作。GitHub 不仅仅是一个存储代码的地方，它还提供了 Issue 跟踪、Pull Request、代码审查、CI/CD、项目管理、Wiki 等一系列围绕开发协作的功能。

除了 GitHub，类似的平台还有 GitLab 和 Bitbucket。不过 GitHub 是使用最广泛的，绝大多数开源项目都托管在 GitHub 上。理解 GitHub 的工作方式，对于参与开源项目、在团队中进行协作开发至关重要。对于 Claude Code 来说，GitHub 上的 PR 审查、代码分析等场景也是其核心功能的使用场景。

核心概念：远程仓库（Remote Repository）

远程仓库是托管在服务器上的 Git 仓库。默认情况下，克隆一个仓库后，远程仓库会被自动命名为 origin。你可以通过 git remote -v 查看所有远程仓库的地址。当你执行 git push origin main 时，就是将本地的 main 分支推送到名为 origin 的远程仓库的 main 分支上。

6.2 核心操作

Fork 和 Clone 的区别

Fork 是在 GitHub 上创建某个仓库的个人副本。当你没有权限直接修改别人的仓库时（比如开源项目），你可以 Fork 该仓库到你自己的账号下，然后你就可以自由地修改自己的 Fork 版本了。Fork 完全在 GitHub 网页上进行，不涉及本地操作。Clone 则是将远程仓库（无论是原始仓库还是 Fork 之后的仓库）下载到本地计算机上。典型的工作流程是：Fork 别人的仓库 → Clone 自己的 Fork 到本地 → 修改代码 → Push 到自己的 Fork → 通过 Pull Request 向原始仓库提交贡献。

创建和管理仓库

在 GitHub 上创建新仓库非常简单：点击右上角的 "+" 图标，选择 "New repository"，填写仓库名称、描述，选择公开（Public）或私有（Private），然后点击创建。创建后，GitHub 会显示一些快速设置指南，包括如何将本地仓库关联到远程：

# 将本地仓库关联到 GitHub 远程仓库
git remote add origin https://github.com/username/my-project.git

# 将本地 main 分支推送到远程
git push -u origin main

SSH Key 配置

每次与 GitHub 交互时，都需要验证你的身份。GitHub 支持两种认证方式：HTTPS（需要输入用户名和密码/令牌）和 SSH（使用密钥对）。SSH 方式更加方便和安全，配置好后就不需要每次都输入密码了。SSH 的原理是使用一对密钥：私钥（private key，保存在本地，绝对不能泄露）和公钥（public key，可以添加到 GitHub 账号中）。

# 第一步：生成 SSH 密钥对
ssh-keygen -t ed25519 -C "your_email@example.com"
# 一路回车使用默认配置即可

# 第二步：查看公钥内容
cat ~/.ssh/id_ed25519.pub
# 复制输出的全部内容

# 第三步：将公钥添加到 GitHub
# 打开 github.com → Settings → SSH and GPG keys → New SSH key
# 粘贴公钥内容，保存

# 第四步：测试连接
ssh -T git@github.com
# 成功输出: Hi username! You've successfully authenticated...

配置好 SSH 后，记得将本地仓库的远程地址从 HTTPS 切换到 SSH 格式：

# 查看当前远程地址
git remote -v
# 输出: origin  https://github.com/username/repo.git (fetch)

# 切换到 SSH 地址
git remote set-url origin git@github.com:username/repo.git

6.3 Pull Request (PR)

Pull Request（简称 PR）是 GitHub 最核心的协作机制。PR 本质上是一个"请求项目维护者合并你的代码变更"的请求。它不仅是一个合并操作，更是一个包含了代码审查（Code Review）、讨论、CI 自动化测试等的完整协作流程。

PR 的生命周期

创建：当你推送了一个新分支到远程后，GitHub 会提示你创建一个 PR。你需要填写标题和描述，清晰地说明这次变更的目的和内容。

审查：PR 创建后，团队成员会收到通知。他们会查看你修改的代码、提出建议、指出问题。这个过程称为 Code Review。

讨论：审查者和作者可能会在 PR 中进行多轮讨论。你可能会根据反馈修改代码，然后推送新的提交，PR 会自动更新。

自动化检查：许多项目配置了 CI（持续集成）系统，PR 中的代码会自动运行测试、代码风格检查、安全扫描等。

合并：当所有审查通过、所有检查通过后，维护者会将 PR 合并到目标分支。

一个标准的 PR 包含以下要素：标题（简明扼要地概括变更）、描述（详细说明背景、解决方案和测试方法）、变更文件列表（GitHub 自动生成的 diff）、评论（团队成员可以在特定代码行上留言）。好的 PR 描述应该包括"为什么要改"和"怎么改的"两部分，让审查者不必猜测你的意图。

对于审查者来说，Code Review 主要关注以下几个方面：代码正确性（逻辑有没有问题）、代码质量（可读性、可维护性）、安全性（有没有安全漏洞）、性能（会不会影响系统性能）、测试覆盖（有没有对应的测试）。Claude Code 提供了 `/review` 技能，可以自动审查 PR 中的代码变更，快速发现潜在问题，大大提高 Code Review 的效率。

新手提示：PR 的黄金法则

PR 要小而精：一个 PR 只做一件事，不要混杂多个不相关的修改。小的 PR 更容易被审查、更容易合并、出错的风险也更小。PR 描述要清晰：想象一下，三个月后的你或者另一个同事看到这个 PR，能否立即明白为什么要做这次修改？PR 之前先测试：在提交 PR 之前，先在本地完整测试一遍你的修改，确保不会破坏现有功能。

章节小结

GitHub 是 Git 的云端协作平台。核心操作包括：Fork（复制他人仓库到自己账号）、Clone（下载到本地）、SSH 配置（免密认证）。PR 是团队协作的核心机制，包含了创建、审查、讨论、检查、合并的完整生命周期。小而精的 PR、清晰的描述、充分的本地测试，是提交高质量 PR 的关键。Claude Code 的 /review 技能可以辅助代码审查，提升协作效率。

深入学习：GitHub 远程协作专题详解

本文是 GitHub 基础入门，如果你想更深入地学习 GitHub，包括仓库管理与协作模式、Pull Request 深入（审查、合并策略）、Issues 与项目管理、GitHub Actions CI/CD、GitHub CLI（gh 命令）、Pages 与文档、开源协作实践等，请阅读专题文档：

👉 GitHub 远程协作专题详解

七、Git Worktree 详解

7.1 什么是 Worktree

Git Worktree（工作树）是 Git 2.5 版本引入的一个功能，它允许你在同一个仓库上同时签出多个分支到不同的目录中，每个目录完全独立、互不影响。换句话说，你可以同时打开两个终端窗口，一个在 main 分支上工作，另一个在 feature 分支上工作，而它们使用的是同一个仓库的 Git 对象存储，不会产生任何冲突。

核心概念：Git 仓库的内部结构

理解 Worktree 之前，需要知道 Git 仓库实际上由两部分组成：.git 目录（存储所有版本数据、配置、引用等）和 工作目录（你实际看到的文件）。传统上，一个 .git 目录只能关联一个工作目录。Worktree 允许一个 .git 目录同时关联多个工作目录，每个工作目录对应不同的分支。这样既节省了磁盘空间（不需要多次克隆完整的 .git 数据），又实现了工作隔离。

7.2 为何需要 Worktree

在 Worktree 出现之前，开发者面临一个常见的困境：你正在 feature 分支上开发一个新功能，代码写到一半，突然有一个紧急 bug 需要修复。你有三个选择：stash（暂存当前工作，但 stash 有风险）、强制提交（提交一个半成品，破坏代码库的整洁）、再克隆一份仓库（浪费磁盘空间，而且还需要重新配置环境）。这三种方案都不理想。

Worktree 完美解决了这个问题。你可以创建一个新的 worktree 用于修复紧急 bug，修复完成后随时切换回来继续原来的开发。使用 Worktree 的好处包括：并行处理多个任务（在不同的目录中同时处理不同的功能）、紧急修复（在不中断当前工作的前提下修复生产问题）、独立测试（在 worktree 中测试不同的分支配置）。

实际使用场景举例：你正在开发一个新的支付功能，突然收到通知说生产环境有一个严重的登录 bug。你可以在另一个目录创建一个 worktree 用于修复 bug，在修复目录中执行 `git switch -c hotfix-login`、修改代码、提交、推送。修复完成后，回到原来的开发目录继续工作。两个目录互不干扰，完美并行。

7.3 常用命令

# 1. 创建一个新的 worktree
# 语法: git worktree add <路径> <分支>
git worktree add ../project-hotfix hotfix-login-bug
# 这会在 ../project-hotfix 目录中签出 hotfix-login-bug 分支

# 如果分支不存在，加上 -b 参数创建新分支
git worktree add -b new-feature ../project-feature main
# 基于 main 创建 new-feature 分支，并在 ../project-feature 中签出

# 2. 列出所有 worktree
git worktree list
# 输出示例:
# /path/to/main-project       main     a1b2c3d [Hauptprojekt]
# /path/to/main-project/hotfix  hotfix   e5f6g7h [worktree]
# /path/to/feature-worktree    feature  i9j0k1l [worktree]


# 3. 移除 worktree
git worktree remove ../project-hotfix
# 注意：worktree 对应的分支不能有未提交的更改

# 4. 清理失效的 worktree 记录
git worktree prune
# 当你手动删除了某个 worktree 目录后，用此命令清理 Git 中的引用记录

# 5. 锁定 worktree（防止被意外移除）
git worktree lock ../important-worktree
git worktree unlock ../important-worktree

新手提示：Worktree 的注意事项

使用 Worktree 时有几点需要注意：第一，一个分支在同一时间只能在一个 worktree 中签出，不能在两个 worktree 中同时工作于同一个分支；第二，创建 worktree 时指定的路径应该是一个不存在的目录，Git 会自动创建它；第三，删除 worktree 不会删除对应的分支，如果不需要该分支了需要手动 git branch -d 删除；第四，worktree 中的更改会影响整个仓库的 Git 对象存储，所以在 worktree 中的提交和其他 worktree 中的提交是共享的。

7.4 Claude Code 中的 Worktree

Claude Code 对 Worktree 有非常好的支持。它提供了一个 `isolation: "worktree"` 模式，当 Claude Code Agent 需要在一个隔离的环境中安全地运行子代理时，它会自动创建一个 worktree 并在其中工作。这样做的好处是：子代理对代码的任何修改都完全独立，不会影响到主工作目录；当子代理的任务完成后，worktree 会被自动清理，不会留下任何垃圾文件。

这种"隔离 + 自动清理"的模式在以下场景中特别有用：代码审查（在一个干干净净的工作目录中审查代码，不会被未提交的更改干扰）、批量操作（安全地运行可能产生大量临时文件的脚本）、实验性修改（测试一些不确定的更改，即使改坏了也无所谓，直接删除 worktree 就行）。

从开发者的角度来看，你不需要手动创建和管理这些 worktree -- Claude Code 会自动处理这一切。你只需要理解 worktree 的概念，就能明白 Claude Code 在某些场景下的行为逻辑。如果你看到 Claude Code 在输出中提到了"worktree"相关的信息，你就能知道它正在使用隔离模式工作。

章节小结

Git Worktree 允许在同一个仓库中同时签出多个分支到不同目录，解决了"同时处理多个任务"和"紧急修复"的问题。常用命令包括：git worktree add（添加）、git worktree list（列出）、git worktree remove（移除）、git worktree prune（清理）。Claude Code 的 isolation: "worktree" 模式利用 worktree 实现子代理的隔离执行和自动清理，确保主工作目录的整洁。

八、开发工作流（Workflow）

8.1 个人开发工作流

即使你是独立开发者，建立一个规范的工作流也非常重要。一个良好的个人工作流不仅能保护你的代码安全，还能让你在回顾历史时清晰地了解每个修改的来龙去脉。以下是推荐的个人开发工作流：

从 main 分支创建功能分支：在开始任何新功能之前，先从最新的 main 分支创建一个新的功能分支。分支名应该清晰体现功能，比如 feature-user-login、fix-payment-bug。这样做的好处是 main 分支始终保持干净可部署，你可以随时切换到 main 分支而不必担心被半成品代码污染。
在功能分支上开发：在功能分支上进行所有修改。建议频繁提交（"早提交、常提交"），每次提交是一个逻辑完整的修改单元。不要等到功能全部完成才提交一次。
使用 Claude Code 辅助编码：在开发过程中，随时可以调用 Claude Code 来辅助编码 -- 生成代码片段、解释复杂的逻辑、编写测试、查找问题等。Claude Code 会在当前分支上进行操作，不会影响其他分支。
提交更改并推送：当你完成了一个阶段的工作后，提交所有的更改并推送到远程。提交信息要清晰明了，推送前最好再检查一下有哪些文件被修改了（git status 和 git diff）。
创建 PR：推送完成后，在 GitHub 上创建 PR。即使你是独立开发者，PR 的"自我审查"效果也很有价值 -- 写 PR 描述的过程本身就是一次代码回顾。
代码审查：使用 Claude Code 的 /review 技能对 PR 进行自动审查，或者自我检查代码质量。如果有团队成员，也可以邀请他们进行 Code Review。
合并到 main：审查通过后，将功能分支合并到 main 分支。可以选择"创建合并提交"或"squash 合并"（将多个提交压缩成一个）来保持主分支历史的整洁。

# 个人工作流完整示例

# 1. 确保 main 是最新的
git switch main
git pull origin main

# 2. 创建功能分支
git switch -c feature-add-search

# 3. 开发过程中频繁提交
git add src/search/
git commit -m "实现搜索功能的 UI 组件"
git add src/search/logic.js
git commit -m "实现搜索逻辑"

# 4. 推送并创建 PR
git push -u origin feature-add-search

8.2 团队协作工作流

在团队环境中，统一的工作流程规范尤为重要。不同团队可能采用不同的工作流模型，以下是三种最流行的模式。

工作流模型	特点	适用场景
Git Flow	多分支管理：main（生产）、develop（开发）、feature（功能）、release（发布）、hotfix（紧急修复）。规则严格，流程完整。	大型项目、需要严格发布管理的团队、有固定发布周期的项目
GitHub Flow	简化模型：只有 main 分支和 feature 分支。所有开发在 feature 分支上完成，通过 PR 合并回 main。规则简单，灵活高效。	持续部署的项目、小型团队、节奏快的互联网项目
Trunk-Based Development	所有开发者频繁地（每天多次）将小规模修改直接合并到主干分支。分支存在时间通常不超过一天。	高度自动化的团队、CI/CD 非常成熟的项目、要求快速迭代的场景

对于大多数中小团队来说，GitHub Flow 是最推荐的选择。它的核心理念是："main 分支始终是可部署的"。所有新功能、bug 修复都在独立的分支上进行开发，通过 PR 进行审查，审查通过后合并到 main。这种模型简单、灵活，适合大多数现代软件开发场景。

8.3 Claude Code 如何融入工作流

Claude Code 可以在开发工作流的每个阶段提供帮助，下面我们看看它在各个环节中的具体作用：

代码生成：在功能开发阶段，你可以让 Claude Code 生成新的代码文件、编写函数、创建测试用例等。Claude Code 会理解项目上下文，生成符合项目风格的代码。
代码审查：使用 /review 技能，Claude Code 可以自动审查当前分支上的代码变更，发现潜在的问题、指出改进方向。这对于确保代码质量非常有帮助。
测试编写：Claude Code 可以根据你的代码自动生成单元测试，帮助你提高测试覆盖率。
提交信息生成：当你完成了一组修改后，Claude Code 可以根据变更内容自动生成规范的提交信息，省去你组织语言的麻烦。
问题诊断：当遇到 bug 时，你可以向 Claude Code 描述问题，它可以帮助你分析和定位问题的根源。
重构建议：Claude Code 可以分析你的代码结构，给出重构建议，并帮助你执行重构。
文档生成：根据你的代码，Claude Code 可以生成 API 文档、README、代码注释等。

核心要点：Claude Code 不是一个孤立的工具，而是深度嵌入到你现有工作流中的 AI 助手。它可以在开发的每一个环节提供帮助 -- 从生成代码到编写测试，从审查 PR 到诊断问题。理解工作流，就是理解如何让 Claude Code 在正确的时间、正确的环节发挥最大的作用。

章节小结

个人开发工作流的核心是"分支开发、主分支保持健康"。团队协作中，GitHub Flow 是最适合大多数团队的工作流模型。Claude Code 可以融入工作流的每个环节：代码生成、审查、测试、提交、诊断、重构。理解工作流，你就能充分发挥 Claude Code 的效率。

九、常用开发工具链

除了 Shell、Git 和 GitHub 这些核心工具，日常开发中还会用到一系列辅助工具。了解这些工具的作用和基本用法，可以让你更加得心应手。

9.1 包管理器

包管理器用于安装、更新和管理项目依赖。不同的编程语言有不同的包管理器：

npm（Node Package Manager）：JavaScript/Node.js 生态的包管理器。通过 npm install 包名 安装依赖，package.json 文件管理项目依赖列表。yarn 和 pnpm 是 npm 的替代品，速度更快。
pip：Python 的包管理器。通过 pip install 包名 安装依赖，requirements.txt 或 pyproject.toml 管理依赖列表。
Homebrew（简称 brew）：macOS 上的包管理器，用于安装系统级的工具和软件。比如 brew install git、brew install node。在 Linux 上对应的是 apt、yum 等。
Chocolatey / winget：Windows 上的包管理器，可用于安装各种开发工具。

# 包管理器常用命令示例

# npm: 初始化项目并安装依赖
npm init -y                 # 创建 package.json
npm install express         # 安装 express 包
npm install --save-dev jest  # 安装开发依赖
npx create-react-app my-app # 无需全局安装即可运行工具

# pip: Python 包管理
pip install requests        # 安装 requests 库
pip install -r requirements.txt  # 批量安装依赖
pip list                    # 列出已安装的包

# brew: macOS 包管理
brew install node           # 安装 node
brew update                 # 更新 brew 自身
brew upgrade                # 升级所有包

9.2 编辑器：VS Code 基础操作

Visual Studio Code（VS Code）是当前最流行的代码编辑器，也是使用 Claude Code 时的推荐编辑器。VS Code 内置了终端（Ctrl + `），你可以在编辑器内部直接运行 Claude Code，无需切换到独立的终端窗口。VS Code 的一些基础操作包括：

命令面板（Ctrl + Shift + P）：通过搜索执行 VS Code 的所有功能
文件搜索（Ctrl + P）：快速打开文件
全局搜索（Ctrl + Shift + F）：在所有文件中搜索文本
源代码管理：内置 Git 图形界面，可以查看修改、暂存、提交和推送
扩展市场：安装各种扩展来增强功能（如 ESLint、Prettier、GitLens 等）

9.3 SSH

SSH（Secure Shell）是一种加密的网络协议，用于安全地连接远程计算机。在开发场景中，SSH 主要有两个用途：连接远程服务器（如登录到云服务器进行运维操作）和 Git 认证（前面章节提到的 SSH Key 免密认证）。

# SSH 常用命令

# 连接到远程服务器
ssh user@192.168.1.100

# 指定端口连接
ssh -p 2222 user@example.com

# 使用密钥文件连接
ssh -i ~/.ssh/my-key.pem user@server.com

# 复制文件到远程服务器
scp local-file.txt user@server:/remote/path/

9.4 Makefile

Makefile 是一个自动化构建工具，最初用于 C/C++ 项目的编译，但现在被广泛用于定义任何类型的项目任务。在一个项目中，你经常需要重复执行某些命令（如运行测试、构建项目、清理临时文件等）。把这些命令写在 Makefile 中，给它们起个名字，就可以用简单的 `make 任务名` 来执行了。

# Makefile 示例
.PHONY: install test build clean

install:
    npm install

test:
    npm test

build:
    npm run build

clean:
    rm -rf dist/
    rm -rf node_modules/

run:
    npm start

# 使用方式：在终端中执行
# make install   -> 安装依赖
# make test      -> 运行测试
# make build     -> 构建项目

9.5 Dotfiles

Dotfiles 是以点（`.`）开头的配置文件，用于存储应用程序和 Shell 的设置。常见的 dotfiles 包括 .bashrc、.zshrc、.gitconfig、.vimrc 等。很多开发者将自己的 dotfiles 托管在 GitHub 上，这样在换新电脑时只需克隆自己的 dotfiles 仓库，然后运行一个脚本就能恢复所有的配置，非常方便。

对于 Claude Code 用户来说，`.claude/` 目录就是 Claude Code 的配置文件目录。它通常包含 settings.json（配置 Claude Code 的行为）和 keybindings.json（自定义快捷键）。

章节小结

包管理器（npm、pip、brew）、编辑器（VS Code）、SSH、Makefile、Dotfiles 构成了开发者日常使用的工具链。这些工具虽然各有不同的用途，但核心目的是提高效率、减少重复劳动。不需要一次性掌握所有工具，而是在实际使用中逐步学习和积累。Claude Code 本身也遵循同样的理念 -- 在工具链中找到最适合自己的组合，让 AI 帮助你更高效地工作。

十、核心要点总结

经过前面九个章节的学习，我们从最基础的终端操作讲到了团队协作的工作流，从 Shell 命令讲到了 Claude Code 的高级特性。作为总结，我们把最重要的核心要义提炼出来，方便你日后回顾。

第一：终端和 Shell 是 Claude Code 的操作基础。Claude Code 没有图形界面，所有的交互都在命令行中完成。你必须能够熟练地打开终端、切换目录、运行命令、设置环境变量。如果你记不住所有的命令，至少要知道去哪里查（比如 --help 参数和搜索引擎）。

第二：Git 是版本控制的核心工具，必须掌握常用命令。Git 最常用的 12 个命令（init、clone、add、commit、status、log、diff、branch、checkout/switch、merge、pull、push）覆盖了 95% 的日常操作。理解工作区、暂存区、仓库三级结构是掌握 Git 的关键。

第三：PR 是团队协作的基础，Code Review 是质量保障。Pull Request 不仅仅是合并代码的请求，更是一个包含了讨论、审查、自动化检查的完整协作流程。小而精的 PR、清晰的描述、充分的测试，是提交高质量 PR 的三要素。

第四：Worktree 实现并行开发，Claude Code 内置支持。Git Worktree 让你能同时处理多个任务而互不干扰。Claude Code 的 isolation: "worktree" 模式利用这个特性实现了子代理的安全隔离和自动清理。

第五：理解工作流才能充分发挥 Claude Code 的效率。Claude Code 不是孤立工具，而是嵌入工作流的 AI 助手。从代码生成、测试编写到 PR 审查、问题诊断，Claude Code 在开发的每个环节都能提供帮助。理解工作流，你就能在正确的时间、正确的环节让 Claude Code 发挥最大作用。

第六：Claude Code 可以辅助学习这些基础工具。在学习 Git 命令时遇到不理解的地方？直接问 Claude Code。在配置环境变量时遇到困难？让 Claude Code 帮你排查。把 Claude Code 当作你的"私人教师"，遇到不懂的就问。实际上，利用 Claude Code 来学习这些前置知识本身，就是最好的练习。

"掌握基础工具的投资回报率是超乎想象的。花一周时间学好 Git，未来十年每天都能节省半小时。终端、Shell、Git、GitHub -- 这些工具会陪伴你整个职业生涯。打好基础，才能走得更远。"

下一步学习建议

读完本文后，建议你按照以下步骤巩固所学：

动手练习：打开终端，逐个敲一遍文中列出的所有命令。不要只是"看懂了"，要"敲熟了"。
创建沙盒仓库：在本地创建一个练习用的 Git 仓库，反复练习 init、add、commit、branch、merge 等操作。弄坏了也不怕，删除重建就行。
提交一个真实的 PR：找一个你常用的开源项目，尝试提交一个小修改（比如修复文档中的错别字），完整走一遍 Fork → Clone → Branch → Edit → Commit → Push → PR 的流程。
安装 Claude Code：在掌握了这些前置知识后，按照官方文档安装 Claude Code，开始第一行"AI 辅助编程"的体验。
持续学习：基础工具的学习是持续的过程。每天花 15 分钟学习一个新命令或技巧，一年后你会惊讶于自己的进步。