我见过不少开发者第一次接触 Git 时，会下意识地敲git about，想看看这个工具的“关于”页面。我接手过一台新同事的开发机，对方当时就是这么问的：终端回了一句git: 'about' is not a git command. See 'git --help'.，他愣住的表情我现在还记得。
其实 Git 从来没有提供过一个集中展示“关于”信息的入口。版本、配置、仓库状态、分支关系、历史记录、远程地址，这些信息被打散到不同的子命令里，像一块块拼图。这篇文章就从头开始，把这些拼图按使用场景拼起来，看完你至少能回答三件事：当前机器上的 Git 是什么状态、面前这个仓库是怎么回事、以及该从哪里开始动手不踩坑。
1. 为什么没有 git about 子命令，以及真正的“官方说明书”在哪
1.1 Git 的命令设计：都是动词，不是标签
Git 的所有子命令都像动词：add、commit、branch、checkout、remote、fetch。动词后面跟着操作对象，比如git add file.txt、git commit -m "message"。而about更像一个名词性标签，它不符合 Git 的设计哲学。Git 想让你主动描述“我要做什么”，而不是被动地查“它是什么”。
这样设计确实让新人不习惯。但反过来看，好处也很明显：你不需要记住一个充满选项卡的 About 弹窗，你只需要知道几个固定的查询命令，它们各自负责回答某一方面的问题。
1.2 想看“关于”信息，先认识这几个出口
很多人不知道，Git 本身带了一套完整的帮助系统，平时你敲错命令时它的提示只是一个入口。真正常用的是这些：
| 命令 | 回答什么问题 | 适用场景 |
|---|---|---|
git --version | 当前 Git 是什么版本 | 排查兼容性、确认安装状态 |
git help -a | 当前安装支持哪些子命令 | 想知道某个功能是否存在 |
git help git | Git 总体的用法和核心概念 | 新人看概念总览 |
git help everyday | 日常高频命令集合 | 想快速上手 |
git <子命令> -h | 某个子命令的参数说明 | 只想知道参数，不想翻完整文档 |
举个例子，我经常看到新人问“怎么撤销这次提交”，其实git reset -h一分钟就能把--soft、--mixed、--hard几个参数看得明明白白。先练会用帮助系统，比到处搜索更高效。
1.3 命令不存在时的“你指的是不是”提示
如果你敲了git about，Git 很可能会提示“The most similar command is git add”之类的内容。这个设计看起来很贴心，但也容易误导人。它只是基于字符串相似度做的猜测，并不理解你的真实意图。它不是你想要的答案，你真正要做的，是根据我下文讲的场景去选命令：查版本用--version，查配置用config，查仓库用status，查历史用log。
2. 先认识这台机器的 Git：版本、配置与隐藏规则
2.1 版本号不是只写给“有强迫症”的人看
git --version输出类似git version 2.39.1。这个信息看起来简单，但关键时刻能救命：
- 不同版本对命令的支持不一样，比如
git switch和git restore是 2.23 之后才稳定的，老机器上可能得用checkout代替。 - 默认分支名相关配置
init.defaultBranch在 2.28 之后才引入，指望它生效就得确保版本足够新。 - 如果你在服务器上部署自动化脚本，服务器 Git 版本太老，脚本里的新参数可能直接报错。
所以拿到一台新机器，我第一件事永远是：
git --version然后顺手看一眼git help -a | head -50，确认环境大体状态。
2.2 配置体系：三层文件，一层盖过一层
Git 的配置存在三个层级，从下往上优先级依次升高：
| 层级 | 配置文件位置 | 作用范围 | 优先级 |
|---|---|---|---|
| system | 安装目录下的 etc/gitconfig | 这台机器所有用户 | 低 |
| global | 用户主目录下的 .gitconfig | 当前用户所有仓库 | 中 |
| local | 仓库目录下的 .git/config | 当前仓库 | 高 |
当你执行git config --list时，看到的是三层合并后的结果；想要知道某个配置到底在哪一层，用--show-origin参数：
git config --list --show-origin输出里每一行都会带上文件路径，一眼就能看出当前 user.name 是在全局配置里设的，还是在某个仓库里单独设的。这个对我排查问题非常有用，我见过有人明明改了全局邮箱，某个仓库却还是显示旧邮箱，原因就是那个仓库的 local 配置覆盖了它。
2.3 新机必配的几个全局项
我个人在新机器上的最小配置是这样的：
git config --global user.name "你的名字" git config --global user.email "你常用的邮箱" git config --global init.defaultBranch main git config --global core.autocrlf input git config --global pull.rebase false逐项解释一下为什么我会这么设：
user.name和user.email：这是写进提交记录的“作者签名”。没配好的话，提交会以机器名或完全不可读的邮箱形式出现在历史里，回头想改非常麻烦。init.defaultBranch main：让新初始化的仓库默认分支叫 main 而不是 master。这是习惯问题，也避免后续脚本里写死分支名时踩坑。core.autocrlf input：在类 Unix 系统上，这个设置能让 Git 把仓库里的换行符转成 LF，提交时保持仓库干净，避免因为 CRLF 导致整文件 diff。pull.rebase false：让git pull的默认行为保持 merge，而不是 rebase。刚入门阶段，merge 产生的历史更直观，改成 rebase 需要你对历史重写有清晰认识。
这些配置设置完，可以用git config --global --list复核一遍。遇到某个仓库要使用不同身份，就在该仓库里单独设 local 配置，不要动全局文件。
2.4 一个容易忽略的坑：配置写错位置
新手最容易犯的错是把本应放在仓库里的配置写进了全局，比如在全局把remote.origin.url配死，结果每个仓库 clone 下来都指向同一个地址。所以，看到git config --list里有仓库相关的配置项时，先想想它是不是应该属于 local 层。分层的核心原则是：机器相关的放 system，用户相关的放 global，仓库相关的放 local。
3. 一个仓库的“自我介绍”：status、remote 与 branch 三件套
3.1 git status：先看有没有脏东西
进入一个新克隆下来的仓库，我从不开 IDE，而是先跑：
git status一个干净的仓库输出通常是这样的：
On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean这个输出告诉你三件事：当前在哪个分支、这个分支有没有落后或领先远程、工作区是不是干净。如果是你刚接手别人的仓库，看到工作区有未提交的改动时，先别急着干活，先弄清楚这些改动是谁产生的。我可以负责任地说，接手项目时最常见的翻车就是没看git status直接checkout或reset，把别人没提交的工作白白丢掉。
3.2 git remote -v：看仓库从哪里来、往哪里推
克隆完项目后，我想知道这个仓库对应的远程地址，用：
git remote -v输出大概长这样：
origin https://example.com/group/project.git (fetch) origin https://example.com/group/project.git (push)origin是 Git 在克隆时自动给远程仓库起的默认名字，不代表它有多特殊。看到 fetch 和 push 地址不同也不要慌，有些团队会刻意让 fetch 走只读镜像、push 走独立入口，这是协作规范，不是异常。
在这个环节我还习惯顺手做一次git fetch --all --prune，把远程最新的引用同步到本地，再配合下面的分支查看命令使用。
3.3 git branch -vv 与 log 的装饰信息
只看分支名是不够的，还得知道每个分支和远程的跟踪关系。用：
git branch -vv会看到类似这样的输出：
* main a1b2c3d [origin/main] 修复登录超时问题 feature/login e4f5a6b [origin/feature/login: ahead 2] 新增验证码方括号里的ahead 2表示这个本地分支比远程分支多了两个提交，说明本地有还没推送的内容。这种信息对判断“我能不能直接改这个分支”特别重要。
再配合git log的装饰模式看整体脉络：
git log --oneline --graph --decorate --all -20--graph会列出分支分叉和合并的线条，--decorate会标出分支和标签指向哪里，-20只显示最近 20 条，防止输出太长。只要仓库不是那种极其复杂的网状历史，这个命令足够让你在三分钟里建立起全局印象。
3.4 先观察后动手的分寸
新手最容易冲动，看到分支就切，看到远程就 push。我的建议是：接手任何仓库，先连续执行下面五个“只看不改”的命令，把输出截图或记在笔记里，再考虑操作：
git status git remote -v git branch -vv git log --oneline --graph --decorate --all -20 git stash listgit stash list往往被忽略，但它能看到历史遗留的暂存工作。很多“神秘消失”的改动其实静静躺在 stash 里，知道这一点，排查问题时思路会宽很多。
4. 深挖历史里的“关于”：log、blame、shortlog 与对象查询
4.1 git log 不止能看提交记录
git log是查历史的核心命令，根据不同需求可以变换参数。我最常用的组合是：
git log --oneline --stat -10--stat会在每个提交后面列出改了哪些文件、增删了多少行。这样你不光知道提交信息，还能快速判断这个提交是不是“噪音提交”。
git log --oneline --author="某开发者" -20想查某个人最近做了什么，就用--author过滤。注意这里的作者名要跟提交配置里的 user.name 一致，而不是“显示名”之类的东西。
git log --since="2 weeks ago" --until="yesterday" --oneline这个适合回答“最近两周项目改了什么”。首次使用这类日期参数时，建议用--since="2 weeks ago"这种人类可读的格式，Git 会正确解析，没必要手动算日期。
4.2 查一个文件的“前世今生”：git log --follow 和 git blame
想知道某个文件是怎么逐步变成现在这个样子的，用：
git log --follow --oneline -- config/app.yml--follow的关键作用是在文件被重命名后，仍然能追踪到旧名字下的历史。我第一次用的时候正好碰到一个文件在几个月前被重命名过，没加--follow时日志只剩重命名后的提交，加了之后才找到最初版本。
想逐行看某个文件的每一行是谁在哪个提交里写的，用git blame：
git blame src/utils/format.ts -L 10,30-L 10,30表示只看第 10 到第 30 行。排查“这段代码是谁加的”这类问题，用blame比用log直观得多，但要注意：blame 追溯的是“最后修改这行的人”，而不是“最初设计这行的人”，所以当看到一行代码归属于一个无关紧要的格式调整提交时，别急着下结论。
4.3 代码贡献统计：git shortlog
团队里时不时会有人统计“谁提交最多”。git shortlog就是干这个的：
git shortlog -sn-s只显示提交次数，-n按次数排序。想看最近一个季度的贡献分布，可以组合日期参数：
git shortlog -sn --since="3 months ago"这类统计只能代表提交频率，不能代表代码质量或工作量。我在使用它的实际场景里，主要是帮导师快速了解新同学是否真的在频繁练习提交，或者复盘某个版本发布前哪些提交过于集中、是否存在“压单提交”的风险。
4.4 内容搜索：git log -S 和 -G
有时候你不是要找提交，而是想知道某段字符串是从哪个版本开始出现的。这时候用：
git log -S "TODO: fix timeout" --oneline-S会在每个提交的 diff 里统计该字符串出现次数，次数变化了就显示出来，适合追踪“这个常量/函数名是哪次提交引入的”。-G则支持正则表达式，适合更灵活的模式匹配：
git log -G "timeout=\d+" --oneline我自己踩过的坑是：-S后面的字符串如果带特殊字符，最好用引号包起来，否则 shell 可能会做通配符或管道解析，导致 git 收到一堆奇怪参数。
4.5 必要时看一眼对象层
Git 底层其实存的是对象，提交、树、文件内容都是对象。普通的日常操作不需要触及这个层面，但遇到“明明历史里能看到，怎么 clone 下来就没了”这种玄学问题，知道一点对象概念能救急：
git rev-parse HEAD git cat-file -t HEADrev-parse能把像 HEAD、分支名这类引用解析成完整的 SHA-1 哈希值，cat-file -t则能查看这个对象是什么类型。比如你想验证当前 HEAD 指向的提交确实存在，可以输入：
git cat-file -t HEAD输出commit就说明类型没问题。对于普通使用，这两个命令足够了，更深层的推荐看 Git 官方文档里的“Git 对象”章节。
5. 模拟演练：用几十个查询命令“吃透”一个陌生仓库
5.1 场景设定
假设你刚入职，拿到一台配好的电脑，被导师丢来一个内部项目的地址，让你先看看代码，准备下一周提交第一个修复。你面前有一个完全陌生的仓库，怎么做才能在不动手改的前提下最快建立全局认识？
我会严格按照下面的顺序走一遍。
5.2 从 clone 到第一次提交前的完整命令流
# 1. 克隆仓库到本地 git clone https://example.com/team/project.git project # 2. 进入仓库 cd project # 3. 先看工作区状态，确认没有意外改动 git status # 4. 看远程地址，确认 clone 来源 git remote -v # 5. 拉取所有远程分支和标签引用 git fetch --all --prune # 6. 看本地分支和远程分支的对应关系 git branch -vv # 7. 看最近 30 条提交的图形化历史 git log --oneline --graph --decorate --all -30 # 8. 看最近三个月谁在做贡献 git shortlog -sn --since="3 months ago" # 9. 找到最近一次提交改了什么 git show --stat HEAD # 10. 查看 README，了解项目用途和运行方式 less README.md第 5 步的--prune很有用，它会把远程已经删除的分支引用在本地同步删除，避免本地残留一堆“幽灵分支”误导你。第 7 步的--all会显示包括远程分支在内的所有分支，让你看到仓库的整体结构，而不只是本地分支。
5.3 这十条命令之外还要留个心眼
只跑命令不够，真正要往下了解项目，还要看几个文件：
ls -la我通常会注意根目录下的README.md、CONTRIBUTING.md、LICENSE、.gitignore。.gitignore决定了哪些文件永远不该提交，如果你发现本地有node_modules/或target/目录没有被忽略，后期几乎必然出现误提交垃圾文件的问题。
5.4 一个需要克制冲动的动作：不要马上 checkout 别人的分支
看图形化历史时很容易看到很多功能分支，比如feature/login、fix/payment，手一滑就切过去了。但你要想清楚：checkout 之前先确认工作区干净，否则别人未提交的改动可能会跟着你一起“搬家”，造成难以解释的工作区内容错乱。
git checkout feature/login执行前先跑一次git status，如果输出不是 “nothing to commit, working tree clean”，要么 stash，要么先问清楚，反正不要硬切。
6. 我在“关于”这件事上踩过的坑和最终习惯
6.1 最经典的坑：全局邮箱没配，历史里全是“幽灵作者”
有一次我看到一个团队的仓库，提交历史里居然有root@localhost这样的作者信息。一查才知道，某位同事装完 Git 后没有配置user.name和user.email，在本地提交了几百条记录，而这些记录的 author 字段全变成了系统默认值，跟匿名提交没区别。想修复历史要动用 filter-repo 或 rebase 改写，风险很大，最后只能不了了之。所以新机器第一件事永远是配身份，这不是洁癖，是基本功。
6.2 默认分支名不一致引发的脚本事件
有次我在一个自动化脚本里写死了master分支名，结果拿到另一台机器上跑，初始化出来的仓库默认分支是main，脚本直接找不到分支。这事的根源就是两台机器上init.defaultBranch设置不一致。现在我的习惯是：脚本里永远读git symbolic-ref --short HEAD来获取当前分支名，而不是写死；新机器上则统一执行git config --global init.defaultBranch main。
6.3 用全局配置“一刀切”的麻烦
还有人图省事，在公司仓库和私人项目里共用同一个全局 user.email，结果所有提交都署上了公司邮箱，项目归属变得混乱。正确做法是：全局只配通用的姓名和邮箱，遇到需要隔离身份的仓库，在仓库目录下用 local 配置单独设置：
git config user.name "个人昵称" git config user.email "个人邮箱"因为 local 配置优先级最高，它会盖过全局值，而且不会影响其他仓库。
6.4 我现在的固定动作
接手任何仓库，我都会在动手前做完下面几件事，已经成了肌肉记忆：
git status git remote -v git branch -vv git log --oneline --decorate --graph --all -20 git stash list这五条命令只读不改，是成本最低的“仓库背景调查”。配置任何身份信息时，先确认自己在哪个层级，不要把仓库级的东西塞到全局。遇到记不清参数的情况，优先用git <子命令> -h，比在搜索引擎翻十分钟旧答案更准确。
回头再看最初那个git about的问题，其实得到的答案很简单：Git 把“关于”藏在了一套分散但有迹可循的命令里。版本用--version看，配置用config查，仓库状态用status读，历史脉络用log理，远程信息用remote -v获取。你不需要一个整齐的 About 窗口，你只需要把每条查询命令当作一个探针，按场景把它们插到对应位置。看清了这些，剩下的 Git 操作就像在光滑的地面上推箱子，方向对了，力气就不会白费。
