Linux下Git高效使用指南：从安装配置到分支管理与免密推送

1. 项目概述与环境准备

Git在Linux下的使用，说简单也简单，说深了能写一本书。但绝大多数人实际遇到的场景，无非是提交代码、推送拉取、分支管理、解决冲突这几板斧。真正让人头疼的往往不是命令本身，而是环境配置不到位、权限搞不定、免密配不好，最后卡在“能用但不顺手”的尴尬阶段。

我见过太多人——包括早期的我自己——在Windows上用惯了可视化界面，一到了Linux服务器上就抓瞎，连个git status都要犹豫半天。但其实只要你理解了Git的核心逻辑（本地仓库、暂存区、远程仓库三者之间的关系），再配合几个高频命令，Linux命令行下操作Git反而比图形界面更清爽、更高效。

这篇文章我会从零开始，分四个部分把Git在Linux下的使用讲透：环境准备与安装、日常高频操作、完整推拉流程、以及常见问题排查。每一部分都会结合我实际踩过的坑，不写空话，直接给能跑的方案。

1.1 为什么选择在Linux下使用Git

很多刚开始接触Linux的人会问：我在Windows上装个Git for Windows，或者直接用VS Code的图形化Git插件，不也挺好的吗？为什么要费劲在Linux命令行下用Git？

这个问题得分两方面看。第一，如果你从事前端、后端、嵌入式、运维这类工作，将来几乎必然要接触Linux服务器——生产环境的代码部署、服务器上的热修复、线上日志排查，都是在纯命令行的Linux环境里操作。你不能指望生产服务器上还装个图形界面让你点鼠标，这不现实。第二，Git本身就是Linus Torvalds在Linux内核开发中诞生的工具，它在Linux下的表现是最原生、最稳定的。命令行下的Git命令，效率远高于鼠标点按——比如你要对3个文件分别提交不同信息，命令行几秒钟搞定，图形界面得来回切。

另外还有一个很实际的考量：我在实际工作中发现，很多问题的根本原因在于本地与服务器的环境不一致。例如在Windows下你可能会被CRLF换行符坑过——代码明明没问题，一推到Linux服务器上就因为换行符差异导致编译异常。而在Linux下使用Git，直接从源头规避了这类环境一致性问题。

1.2 Linux发行版选择与Git安装前检查

在开始安装之前，先确认你的Linux发行版类型。主流的可以分为两大系：Debian系（Ubuntu、Debian、Linux Mint等）和Red Hat系（CentOS、RHEL、Fedora、Rocky Linux等）。两系的包管理器不同，安装命令也完全不同。

我在初期经常看到有人拿Ubuntu的apt-get install去CentOS上跑，结果报一堆错，然后怀疑是不是系统坏了。其实不是，纯粹是包管理器不对路。

安装前建议先做两件事：

# 1. 更新软件源（Debian/Ubuntu系） sudo apt update # 2. 检查是否已安装git git --version

如果系统已经预装了Git（很多Linux发行版默认自带），直接跳到配置环节。如果没有，根据你的发行版选择对应命令安装。

提示：在服务器上执行sudo时，确保当前用户有sudo权限。常用的运维操作是先创建一个具备sudo权限的普通用户来操作，而不是一直用root。原因很简单：root操作没有审计日志，出了问题很难追溯。

2. 安装方式与配置文件的深度理解

安装Git看起来简单，无非一条命令的事。但我在给团队做培训时发现，很多人搞不清楚“版本区别”和“配置文件优先级”这两个概念，导致后续出现各种莫名其妙的问题。

2.1 Debian/Ubuntu系安装

对于Ubuntu或Debian系统，安装过程非常丝滑：

sudo apt update sudo apt install git -y

安装完成后验证版本：

git --version

正常会输出版本号，比如git version 2.39.2。这里有一个很多人忽略的点：如果安装时网络源特别慢，可以换国内镜像源再装。但我不太建议在服务器上频繁换源，除非你非常确定当前源不可用。服务器最重要的是稳定，换了源之后，后续apt update时可能无法正常获取部分软件包列表，反而把自己坑了。

2.2 Red Hat/CentOS系安装

对于CentOS或RHEL系统：

sudo yum install git -y

如果是比较新的版本（CentOS 8+/Rocky Linux），可能用的是dnf：

sudo dnf install git -y

这里有一个实操经验：CentOS 7自带的Git版本通常比较老（1.8.x），如果你需要使用一些新特性（比如更友好的git switch命令、更完善的分支管理能力），建议使用IUS软件源或者源码编译安装。

2.3 源码编译安装（进阶）

如果你对版本有硬性要求，或者需要定制编译参数，可以选择源码编译。这里以Git 2.40.0为例：

# 安装编译依赖 sudo apt install make gcc libssl-dev libcurl4-openssl-dev zlib1g-dev -y # 下载源码（可以从GitHub获取） wget https://github.com/git/git/archive/refs/tags/v2.40.0.tar.gz # 解压并进入目录 tar -zxvf v2.40.0.tar.gz cd git-2.40.0 # 编译安装 make prefix=/usr/local all sudo make prefix=/usr/local install

源码编译的坑主要在依赖上，如果缺了某个开发库，编译到一半会报错。所以我通常列一个“标准依赖清单”，缺啥补啥。编译一次大约需要5-10分钟，视机器性能而定。日常使用完全没必要折腾源码编译，这一段是给有特殊需求的朋友准备的。

2.4 三个层级的配置文件：global与system与local

这是Git使用中最容易忽略、却最影响体验的部分。Git配置文件分为三个层级：

配置优先级的规律很好记：越靠近当前仓库的配置，优先级越高。local会覆盖global，global会覆盖system。

查看当前所有生效的配置：

git config --list --show-origin

这个命令会详细显示每个配置项来自哪个文件，排查问题的时候非常好用。比如你发现某个仓库的提交用户名不符合预期，先用这个命令看看是哪一层配置出了问题。

设置用户名和邮箱：

# 当前用户级别 git config --global user.name "Your Name" git config --global user.email "your_email@example.com" # 仓库级别（覆盖global） git config user.name "Another Name"

很多初学者会问：为什么提交代码一定要配置user.name和user.email？因为Git在记录每一次提交时，都要写入“作者是谁”的信息。这个信息没有配置，提交时Git会报错（新版会提示，旧版会使用默认值）。特别是团队协作时，准确的用户名邮箱直接关系到代码评审时确认“这个提交是谁写的”，也关系到提交是否能正确关联到代码托管平台的账号上。

2.5 换行符与文件权限等关键配置

在Linux下使用Git，有两个配置项务必理解清楚：

换行符配置（core.autocrlf）：在Windows下开发时，文本文件默认使用CRLF（回车+换行）作为行尾；而Linux/macOS使用LF（换行）。如果团队跨平台协作，这一差异会造成大量无意义的“整文件变更”。

在Linux下，推荐设置：

git config --global core.autocrlf input

这个含义是：提交时将CRLF转换为LF入库，检出到工作区时不转换（保持LF）。在Linux+Windows混合团队中，Windows端设置core.autocrlf true（提交时CRLF转LF，检出时LF转CRLF），Linux端设置input即可。

文件权限配置（core.fileMode）：Git会默认记录文件的可执行权限。在某些场景下（比如权限频繁变化但代码内容不变的目录），这种权限变化会被Git视为文件变更，产生大量噪音提交。如果你确认不需要关心文件权限变化：

git config --global core.fileMode false

但这个配置要谨慎用，如果你管理的是Linux下的脚本目录，可执行权限往往是有意义的，关掉track反而会漏掉关键信息。

提示：执行git config --global core.autocrlf input后，已有的仓库可能需要重新规范换行符格式，最省事的方式是执行git add --renormalize .后提交一次，可以一次性把仓库内所有文件规范到LF行尾，避免历史提交里混着CRLF导致的“假改动”。

3. 日常高频操作：add、commit、branch、log

安装完成、配置到位之后，就进入了真正的高频使用环节。下面的内容以实际工作中用得最多的命令为主，我尽量把“为什么要这么用”讲清楚，而不是只列命令。

3.1 git add：从工作区到暂存区

工作区、暂存区、本地仓库、远程仓库这四个概念，是整个Git使用的灵魂。很多人刚开始学Git会混乱，是因为不知道文件在哪个区，也不清楚每个命令对应的是哪个区之间的移动。

我的一个类比：假设你要邮寄一个快递。

• 工作区 = 你家里的所有物品
• 暂存区 = 你选定要装箱的物品（还没打包好）
• 本地仓库 = 已经打包好的一个快递包裹（但还没寄出）
• 远程仓库 = 快递已寄出，到达了目的地

git add相当于把选定的物品放进“暂存箱”。这个设计最大的好处是可以把一次开发中的不同改动拆分成逻辑清晰的多次提交。比如我修改了一个文件同时修复了两个bug，我就分两次add两次commit，保证提交历史清晰可追溯。

常用命令：

# 添加单个文件 git add src/main.py # 添加多个文件 git add src/main.py src/utils.py # 添加当前目录全部改动 git add . # 交互式添加（非常适合拆分提交） git add -p

git add -p算是我平时用得最多的一个“隐藏宝藏”命令，它允许你逐块（hunk）选择是否暂存某部分改动。比如一个文件里同时有功能A和功能B的修改，我用git add -p分别选择对应代码块暂存，再分两次提交，提交历史看起来非常整洁。

3.2 git commit：提交信息规范与原子提交

git commit是将暂存区的内容生成一个永久快照，写入本地仓库。这里有一个新手最常犯的错误：git commit不带-m参数时，会进入一个交互式编辑器（默认是vi/vim），一堆人卡在里面不知道怎么退出。避免方法很简单——每次都加-m。

git commit -m "feat: 新增用户登录接口"

关于提交信息，我们的团队内部有一套简单的规范，时间久了就能体会到它的价值：

• feat:新功能
• fix:修复bug
• docs:文档变更
• refactor:重构（不改变功能的代码调整）
• test:测试相关
• chore:构建、依赖等杂务

规范的提交信息，配合git log --oneline能够让你快速浏览项目修改脉络。我接手过的很多项目，就是靠清晰的提交历史才快速理解前人代码思路的。

“原子提交”也要提一句：一次提交只做一件事。不要一次提交里同时塞了几个不相干的修改，等到需要回滚或revert其中一个功能时，你会非常痛苦——要么带出一大堆不该动的代码，要么只能靠手动挑拣。

3.3 git branch：分支管理思路

分支是Git团队协作的利器，它的本质是一个可移动的指针，指向某次提交。

# 查看本地全部分支 git branch # 创建分支 git branch feature-login # 切换分支 git switch feature-login # 创建并切换到新分支 git switch -c feature-login # 删除本地分支 git branch -d feature-login # 合并分支到当前分支 git merge feature-login

这里要强调一下git switch和git checkout的关系。老教程里都用git checkout -b xxx来创建并切换分支，但checkout命令承担了太多职责（切分支、恢复文件、切commit），语义不够单一。git switch是Git 2.23+提供的专用分支切换命令，更安全、更清晰。如果你的Git版本支持，建议优先用switch。

分支命名也建议有一套规范，比如feature/开头开发新功能、bugfix/开头修复特定问题、release/开头发布版本。这套规范的好处在你对接多个并行需求时尤其明显。

3.4 git log：查看历史的正确姿势

git log是理解项目变迁的利器，但默认输出格式在提交多了之后会非常冗长。我常用的是这几种：

# 简洁的单行历史 git log --oneline # 带图形化分支视图 git log --graph --oneline --all # 查看某个文件的变更历史 git log -p src/main.py # 查看某个作者的提交 git log --author="zhangsan"

其中git log --graph --oneline --all几乎是我每天必用的命令，视觉上可以一目了然地看到分支分叉、合并的时间线和结构。对于刚接手项目的人，第一条建议就是先跑这个命令，摸清主干和分支的脉络。

4. 完整实操流程：从克隆到推送再到免密配置

这应该是这篇文章里最具“抄作业”价值的部分。我会用一个非常典型的场景串一遍完整流程：你接手了一个项目，需要把代码拉到Linux服务器上，修改后推送回远程仓库，并配置好免密登录。

4.1 生成SSH密钥并配置免密登录

不管是使用GitHub还是GitLab，推荐通过SSH协议来进行认证，因为SSH密钥验证比HTTPS密码认证更安全、更便利。

第一步：生成SSH密钥对

ssh-keygen -t ed25519 -C "your_email@example.com"

这里我建议使用ed25519算法，它比传统的RSA 2048更安全，且生成的密钥更短。如果你用的是老系统，对ed25519支持不好，再退回RSA：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

执行后会有几个交互提示，直接回车默认即可。如果想给私钥设置口令（推荐），可以输入一个口令短语。

第二步：把公钥添加到托管平台

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的完整内容，进入GitHub/GitLab的设置页面，找到SSH Keys -> Add new，粘贴并保存。

第三步：验证SSH连接

ssh -T git@github.com # 或 ssh -T git@gitlab.com

第一次连接会提示确认主机指纹，输入yes即可。成功后会显示欢迎信息，比如GitHub会提示Hi 你的用户名! You've successfully authenticated。

第四步：配置本地SSH代理（可选）

如果你经常连接多个主机（GitHub、GitLab、公司内网Git），建议在~/.ssh/config里配置主机别名，像这样：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_company

这个配置的好处是：不同平台的密钥分开管理，互不干扰，也不需要每次连接手动指定密钥文件。我实际遇到过一个场景——同一台机器上绑定了两个GitLab账号，没有用Host别名时，第二个账号的公钥怎么加都认证失败，明明复制粘贴正确却提示权限问题。原因就是Git默认使用同一个密钥与同一个主机域名匹配，两套账号在同一个域下没法区分。用Host别名就能彻底解决。

4.2 克隆、修改、推送到远程仓库

第一步：克隆远程仓库

git clone git@github.com:username/project.git # 或者指定本地目录名 git clone git@github.com:username/project.git my-project

第二步：创建功能分支

cd project git switch -c feature/optimize-login

第三步：修改代码并提交

# 修改代码... # 查看当前状态 git status # 暂存并提交 git add . git commit -m "feat: 优化登录模块的验证流程"

第四步：推送分支到远程

git push -u origin feature/optimize-login

-u参数（全称--set-upstream）很关键，它的作用是建立当前本地分支与远程分支的关联。设置之后，后续直接执行git push和git pull即可，不需要每次指定分支名。

4.3 合并请求与多人协作场景

推送到远程后，通常并不是直接合并到主干（master/main），而是发起合并请求（Pull Request / Merge Request）。经过代码评审后，由负责人合并。

在Linux服务器上做代码评审或辅助操作时，有时需要在命令行直接合并：

# 切换到主干分支 git switch main # 拉取最新代码 git pull # 合并功能分支 git merge feature/optimize-login # 推送合并结果 git push

如果团队习惯用rebase保持线性历史，可以在合并前执行：

git switch feature/optimize-login git rebase main

rebase的含义是把当前分支的提交“逐个”搬到目标分支的最新提交之上，让提交历史变成一条干净的直线。但有一条铁律：不要对已推送到远程的公共分支执行rebase，因为这会重写历史，导致其他协作者的本地仓库与远程分叉，造成比merge冲突更棘手的混乱。

我可以现身说法：我有一次在公共分支上执行rebase，改写了几个提交后强行push（git push -f），结果团队另一位成员拉取时出现了大量“rejected”报错，最后只能用git reset --hard回退到远程对应节点才恢复，白白浪费了半天时间。

4.4 tag打标签：版本管理的锚点

发版时给代码打标签（tag）是Linux环境下常用且重要的操作。标签相当于给某次提交起了一个固定的、有意义的名字。

# 新建标签 git tag v1.0.0 # 给指定提交打标签 git tag -a v1.0.0 -m "Release version 1.0.0" # 查看所有标签 git tag # 推送标签到远程 git push origin v1.0.0 # 删除远程标签 git push origin :refs/tags/v1.0.0

我见过不少团队没有打tag的习惯，发布的版本靠“我记得大概是上周那次提交”。等到线上出问题需要回滚时，对着几百条提交历史一脸茫然。养成给每次发布打tag的习惯，成本极低，收益极高。

4.5 远程仓库地址管理与回滚操作

查看远程仓库地址：

git remote -v

添加或修改远程仓库地址：

# 添加新的远程地址 git remote add origin git@github.com:username/project.git # 修改已有远程地址（比如仓库迁移后） git remote set-url origin git@github.com:username/new-project.git

这里特别提一下仓库迁移的场景。公司内部Git地址变更很常见，我之前遇到过一种情况：远程仓库迁移到新域，团队成员一个个把老地址删了再小心翼翼地添加新地址。其实git remote set-url一条命令就搞定，不需要删了再加。

回滚操作：

# 软回退：保留工作区和暂存区，撤销提交 git reset --soft HEAD~1 # 混合回退：保留工作区，撤销提交和暂存 git reset --mixed HEAD~1 # 这是默认行为 # 硬回退：彻底回到上次提交，工作区修改不保留（慎用） git reset --hard HEAD~1

git reset --hard是很多人的“救命稻草”，但也是“后悔药”。如果执行时丢失了未提交的工作内容，基本没有找回的可能。我的建议是：在不确定是否要丢弃当前修改时，先执行git stash暂存，或者把要重置的文件cp备份一份，再考虑reset。

4.6 git stash：临时保存现场

当你正在功能A分支开发到一半，突然需要切换到功能B分支处理一个紧急bug时，git stash就能派上用场：

# 暂存当前所有未提交的修改 git stash # 查看暂存列表 git stash list # 恢复最近一次暂存，并删除该暂存记录 git stash pop

我实际开发中几乎每天都用它。比如有时改了半天的代码，还没成型，但怕继续改坏了想先回到干净状态验证一下。git stash把修改存起来，干净环境测试完，再git stash pop回归开发现场，非常顺滑。

5. 常见问题与排查技巧实录

Git在Linux下的报错五花八门，但大部分都可以归为几类。这里记录一些我实际遇到过的高频问题和对应的处理方案，希望帮你少走弯路。

5.1 “无法将git识别为命令”

虽然这是Windows下的典型报错（git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称），但Linux下也有对应版本：bash: git: command not found。

这个报错几乎都是“Git未安装”或“PATH环境变量配置不对”导致。Linux下的排查顺序：

# 1. 确认是否安装 which git rpm -qa | grep git # RedHat系 dpkg -l | grep git # Debian系 # 2. 如果没有安装，按上文安装即可 # 3. 如果安装了但提示找不到，检查PATH echo $PATH

源码自行编译安装时，如果指定了prefix=/usr/local，而系统PATH没有包含/usr/local/bin，就会导致命令找不到。解决办法是把路径加到~/.bashrc：

export PATH=$PATH:/usr/local/bin source ~/.bashrc

5.2 SSL证书验证失败

运行git push或git clone时报错：SSL certificate problem: unable to get local issuer certificate。

这个报错通常是因为系统CA证书不完整，或者内网Git服务器使用了自签名证书。如果是内网环境且你信任该证书，可以临时关闭SSL验证：

git config --global http.sslVerify false

但请注意：这条命令请仅在特定信任的网络环境中使用。如果是在公共网络或生产环境，关闭SSL验证等于把数据传输裸奔在网络上，很容易被中间人攻击。更安全的做法是把自签名证书添加到系统的信任列表，或者把证书放在本地指定路径并在Git中单独配置：

git config --global http.sslCAInfo /path/to/your/cert.pem

5.3 认证失败：login failed. check api token or gitlab version

这个报错常见于GitLab操作，可能是API token过期、权限不足或GitLab版本过旧与Git客户端不兼容导致。

我的排查思路如下：

1. 先确认token是否有效：在GitLab个人设置中重新生成一个token，注意勾选所需权限范围（read_repository、write_repository等）
2. 检查GitLab版本是否过旧：旧版GitLab与新版Git客户端之间存在一些协议兼容问题，最简单的办法是升级GitLab，或者客户端改用SSH方式连接

这里我再多一句嘴：如果你是在浏览器里登录GitLab复制URL时带出了token，URL里暴露token本身就是安全隐患。尽量改用remote set-url配置成git@gitlab地址:用户/项目.git的SSH形式，更安全，也少了很多token超时的烦恼。

5.4 换行符导致的诡异大范围diff

场景：你只是修改了文件里一行代码，但git diff显示整个文件中几百行都变了。

原因：文件行尾是CRLF，而Git配置的autocrlf没有正确工作。解决办法：

# 检查当前仓库的autocrlf配置 git config --list | grep autocrlf # 设置为input（Linux下） git config core.autocrlf input

然后规范化文件：

git add --renormalize . git commit -m "chore: normalize line endings to LF"

我在一个跨平台项目中就被这问题坑了整整半天，十多个文件显示“全量修改”，一行行检查才发现是CRLF在作祟。设置规范之后，后续提交干净利落。

5.5 “git目录泄露”隐患与处理

搜索热词里出现了“git目录泄露如何下载”，虽然这是一句很简短的关键词，但它背后是一个常见的Web安全风险场景：开发者把项目部署到服务器（如Nginx/Vercel等Web服务）时，把.git目录一并暴露到了Web根目录。

所谓.git目录是Git仓库的“灵魂”所在，内部保存了提交历史、分支引用、配置、对象数据库等全部元数据。如果有人通过http://你的网站/.git/config访问到内容，说明该目录被直接暴露在Web根目录下了——攻击者可以通过特定工具把完整源码和历史提交下载下来，相当于项目核心资产秒变公开资料。

排查与处理建议：

# 检查Web根目录下是否有.git目录 ls -la /var/www/html/.git # 删除该目录（如果确认不需要在Web环境保留Git记录） rm -rf /var/www/html/.git # 生产部署的正确方式是源码编译/打包后复制过去，而不是直接放.git仓库

如果你负责的服务器上需要保留Git仓库但又不希望Web访问到.git，可以统一在Nginx/Apache配置里拒绝访问：

# Nginx示例 location ~ /\.git { deny all; }

5.6 分支名与推送被拒绝

推送时报错：! [rejected] main -> main (fetch first)。

这种基本都是远程已有新提交，本地落后导致的。最简单的解决办法：

git pull --rebase git push

--rebase的作用是把你的本地提交变基到远程最新提交之后，避免产生不必要的合并节点。如果pull --rebase时出现冲突，解决冲突后执行：

git add . git rebase --continue git push

5.7 提交历史中的敏感信息

另一个常见问题：密码、密钥、token等敏感信息被提交进了Git历史。即使你当前的提交把它们删除了，只要历史上存在过，就仍然可以通过git log翻出来。

如果有这样的场景，需要改写历史。对尚未推送到远程的提交，可以直接用git rebase -i修改。如果已经推送到远程，处理会相对麻烦，需要重写历史后强制推送，同时通知所有协作者同步。最有效的防范措施是事前预防：

1. 在.gitignore中添加敏感的配置文件
2. 使用gitleaks、trufflehog等工具扫描历史提交
3. 对核心密钥统一使用环境变量或密钥管理服务，不写入代码仓库

我在给一个团队做安全自检时，发现他们的历史提交里躺着一个数据库连接密码——因为很久之前项目刚起步时为了省事写死在配置里。好在项目还没对外，否则这个隐患相当严重。最后我们做了历史重写，把所有包含敏感信息的提交抹掉了，同时强制改了所有原来的密码。

6. 从“会用”到“用好”：效率提升建议

Git在Linux下真正用得顺手，其实是环境配置和习惯积累的结果。最后分享几个我日常工作中的小技巧。

配置别名，减少敲键次数：

在~/.gitconfig的[alias]段中配置：

[alias] st = status ci = commit br = branch co = checkout lg = log --graph --oneline --all last = log -1 HEAD

配置后，git st就是git status，git lg就是那串又长又常用的图形化历史命令。时间久了能省下不少敲击，也更愿意频繁查看状态。

善用.gitignore：

一个干净仓库的前提，是.gitignore配置到位。以Python项目为例：

__pycache__/ *.py[cod] venv/ .venv/ *.egg-info/ dist/ .env .idea/ .vscode/

.gitignore看起来不起眼，但它能避免大量“垃圾提交”。我见过不少仓库里塞满了__pycache__、.idea之类的文件，commit历史又长又乱，找一次关键变更极其痛苦。第一次git init后，先把.gitignore建好。

提交前一定先git status和git diff：

我在给团队定的规矩是：git commit之前，最少执行一次git status和git diff，确认要提交的就是自己想要的内容。这个习惯帮我避免了很多次“把调试代码一起提交上去”的事故。

善用git log --follow追踪文件移动：

有人问你“这个函数是什么时候被挪到这里来的”，普通git log -- path看不到文件移动前的历史，加上--follow参数就能顺着整个移动轨迹查下去：

git log --follow -p src/old_path.py

想学更多，从读git自带文档开始：

Linux下输入git help <command>或git <command> -h，就能查看官方帮助文档。很多搜索引擎第一条出来的答案不一定适配你的Git版本，官方文档反而最准确。我遇到一个不确定的参数时，先查官方文档，再决定怎么用，出错率低很多。

最后再分享一点个人感受。Git这套工具刚上手时，很多人会被它的概念绕晕：工作区、暂存区、索引、HEAD、origin，每个词都似懂非懂。但只要你坚持在Linux命令行下实际用两周，每天提交几次，遇到问题就git status看看状态，配合git log回看历史，这些概念会自然地在脑中形成画面。最难的不是命令记不住，而是没有形成“在终端里管理代码”的肌肉记忆。

我自己就是从这个阶段过来的，从最早在Windows下用图形界面，到后来硬着头皮在Linux服务器上敲命令，再到今天能熟练处理各种分支操作和冲突。回头看，真正的转折点就一句话：别怕破坏仓库，多折腾才是学Git最快的路。只要记住，仓库本质上分远程和本地，远程一份是“可恢复的备份”，本地一份就算被改坏了，也可以通过git clone重新拉一份，最多花几分钟克隆时间而已。有了这层底气，你可以放心大胆地在分支、rebase、reset这些操作上练手。

这篇文章写到的内容和命令，是我日常使用频率最高的子集，覆盖了从初始化到多人协作的完整链路。你完全可以把其中提到的命令执行一遍，在自己的服务器上做一个练习仓库，把分支、合并、rebase、stash、tag都过一遍。学完这一遍，Linux下的Git使用对你来说就不再是“知识”而是“手感”了。