Skip to content
从零开始：
克隆已有仓库：
Git 概述与安装配置
版本控制与快照模型
版本控制系统负责跟踪文件在时间轴上的变化，让使用者可以随时回到任意历史记录点，查看当时的文件内容、对比差异，或在多条开发线之间切换。手工管理版本的方式（复制文件并重命名为 v2、final、final-v2-really-final）在项目规模扩大或多人协作时，混乱几乎不可避免，版本控制系统把状态记录这件事自动化了。
Git 采用的是快照模型。每次提交存储的都是文件系统的完整状态，对于没有变化的文件，Git 会直接保存一个指向上一个版本中该文件的引用，不会重新存储内容。这与基于差异叠加的模型不同——那种模型需要从初始状态开始重放所有变更才能还原某个历史版本，时间越长效率越低。在快照模型下，切换分支或回退到任意版本的操作几乎瞬时完成，因为 Git 只需要把工作目录的文件指针指向目标快照的内容。
快照模型的另一个作用是让数据完整性验证变得简单。每个快照的内容通过 SHA-1 哈希生成一个 40 位的标识符，文件内容一旦有任何改动，哈希值就会完全不同。Git 的历史记录由这些哈希串联而成，任何篡改都会打乱引用链条，不可能在 Git 不知情的情况下进行。
分布式意味着什么
集中式版本控制系统（如 SVN）依赖一个中心仓库，所有人的代码拉取与提交都经过这个节点。服务器一旦宕机，本地除了已经检出的文件之外没有历史记录、无法创建分支、无法回退。
Git 是分布式的。git clone 拉到本地的是仓库的完整副本，包含全部提交历史和分支信息。本地的提交、分支创建、版本回退等操作都不需要与远程服务器交互，直到执行 git push 才把本地更改同步出去。这种设计带来的直接结果包括：
- 离线工作：断网状态下仍然可以提交、查看日志、切换分支。
- 冗余备份：每个人的机器上都保存了一份完整的仓库副本，任何单一节点的故障都不会造成数据丢失。
- 灵活的工作流：提交不再必须经过中心节点，你可以决定同步的时机、分支和对象。这种灵活性衍生出了 Git Flow、GitHub Flow、GitLab Flow 等工作模式，不过它们不是本篇要展开的内容。
Git 的起源
Linux 内核社区在 2005 年之前一直使用商业版本控制工具 BitKeeper，后因许可问题失去免费使用权。Linus Torvalds 决定自己写一个，并定下了几个目标：
- 速度快，能处理内核规模的代码库；
- 数据完整性，所有改动必须留下不可篡改的记录；
- 完全分布式，每个人都能拥有完整的仓库副本；
- 支持非线性开发，能够同时维护多条独立的分支线。
两周后 Git 的第一个版本诞生。它从设计之初就不是为了在旧工具的基础上做增量改进，而是重新定义了版本控制的工作方式。
安装 Git
Git 不是操作系统的默认工具，需要手动安装。
Windows
从 git-scm.com/download/win 下载安装程序。安装过程中的配置选项如果没有特殊偏好保持默认即可，默认编辑器和换行符处理等可以在安装后调整。
Windows 版 Git 不会自动更新。升级大版本时需要手动下载新版本安装程序运行就地更新，已有的配置会被保留。
macOS
macOS 10.9 及以上版本在终端输入 git，系统会弹出 Xcode Command Line Tools 的安装提示，但这种方式安装的版本受系统绑定，更新不够灵活。推荐使用 Homebrew：
bash
brew install git后续可以通过 brew upgrade git 获取更新，Homebrew 对安全补丁和依赖库的跟进速度通常比系统自带方式快。
Linux
使用发行版自带的包管理器。Ubuntu/Debian 执行：
bash
sudo apt-get install git其他发行版的包名可能略有差异，但基本都能在官方源直接找到。
验证安装
安装完成后执行：
bash
git --version输出类似 git version 2.x.x 就表示 Git 已正确安装并加入 PATH。如果提示命令未找到，需要检查安装过程是否正常完成。
配置用户身份
每次提交都会记录作者信息，这些信息是后续追溯变更、审计和统计贡献的基础，需要在开始使用前配置 user.name 和 user.email：
bash
git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"--global 表示该配置作用于当前操作系统用户的所有仓库，去掉这个选项则只对当前仓库有效。
这两个值会写入每次提交的元数据。如果使用 GitHub 或 GitLab，user.email 应当与平台账户绑定的邮箱一致，否则平台无法将提交关联到个人账户。注意，Git 本身不验证邮箱的真实性，填写任意地址都会被接受，但协作场景下邮箱错误会导致提交归属混乱，应该在开始提交前确认清楚。
配置换行符与编辑器
文本文件的换行符在不同操作系统中不一致：Windows 使用 CRLF（\r\n），macOS 和 Linux 使用 LF（\n）。跨平台协作时如果不处理换行符，可能会出现仅换行符不同的“伪变更”，污染 diff 记录。
core.autocrlf 用来处理这个问题：
bash
# Windows：提交时将 CRLF 转为 LF，检出时转回 CRLF
git config --global core.autocrlf true
# macOS / Linux：提交时将 CRLF 转为 LF，检出时不处理
git config --global core.autocrlf input另一个影响日常操作的配置是默认编辑器。Git 在编写提交说明、处理合并冲突、编辑交互式变基命令等场景下需要调用文本编辑器。如果不指定，Git 会使用系统默认编辑器，可能在终端中出现界面错乱。
bash
# 设置为 VS Code
git config --global core.editor "code --wait"
# 或使用 vim
git config --global core.editor "vim"--wait 参数让 Git 等待编辑器关闭后再继续执行；缺了这个参数，VS Code 打开后 Git 会立即认为编辑已完成。
配置的三层作用域
Git 的配置存在三个层级，从大到小依次为：
| 层级 | 作用范围 | 配置文件位置 |
|---|---|---|
system | 整台机器所有用户 | /etc/gitconfig |
global | 当前用户的所有仓库 | ~/.gitconfig 或 ~/.config/git/config |
local | 当前仓库 | .git/config |
同一配置项出现在不同层级时，范围越小的优先级越高：local 覆盖 global，global 覆盖 system。
通常将用户身份和编辑器偏好放在 global 层。如果某个项目需要使用不同的邮箱（例如工作项目用企业邮箱，个人项目用私人邮箱），可以在该仓库的根目录下执行不带 --global 的命令，写入 local 层。
要查看所有层级当前生效的配置：
bash
git config --list --show-origin--show-origin 会显示每一项配置的来源文件路径，方便辨认配置是哪个层级设置的。输出类似于：
file:/home/user/.gitconfig user.name=Your Name
file:/home/user/.gitconfig user.email=your_email@example.com
file:.git/config core.editor=vim最后一条来自仓库内的配置文件，表明该仓库覆盖了全局的编辑器设置。
创建仓库
把 Git 引入项目有两种方式。
从零开始：git init
在项目目录下执行：
bash
git initGit 会在当前目录生成 .git 子目录，其中存放仓库所需的全部元数据（对象、引用、配置、钩子脚本等）。此时项目文件并不会自动加入版本控制，它们处于“未跟踪”状态，需要后续通过 git add 和 git commit 手动纳入管理。
克隆已有仓库：git clone
当项目已经存在于远程仓库时，使用 clone 拉取：
bash
git clone https://github.com/user/repo.git这个命令做了三件事：创建以仓库名命名的目录；拉取远程仓库的完整副本（包括所有提交历史与分支）；默认将远程仓库命名为 origin。进入目录后可以直接开始工作，不需要再执行 git init。
帮助系统与别名
Git 内置了一套完整的帮助文档：
bash
# 简要帮助
git help
# 特定命令的完整文档
git help <command>
# 简短版的命令选项列表
git <command> -h这份文档在本地安装时就已经存在，没有网络也能使用。
某些 Git 命令加上参数组合起来比较长，可以为常用操作设置别名：
bash
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status设置完成后，git co 等效于 git checkout。别名不会删除原有命令，Git 会优先匹配别名，原命令仍可通过 git-<command> 的形式调用（如 git-checkout）。
注意点
user.email只要格式合法，Git 不做真实性校验，但托管平台依赖它关联提交者身份，填写后不要频繁更改。core.autocrlf配置错误不会立即报错，而是可能在后续合并时产生大量与换行符相关的冲突，排查起来比较耗时。- Windows 版 Git 不会自动更新，安全补丁的跟进依赖用户的主动操作。
- 执行
git init后看到空目录，但实际上.git已包含完整的仓库框架，不要手动修改.git目录内的任何内容。 --global配置绑定的是当前操作系统用户，同一台机器上切换操作系统账户时，每个账户拥有独立的配置层级。