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可能用的是dnfsudo 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配置文件分为三个层级层级配置文件位置作用范围优先级system/etc/gitconfig系统所有用户低global~/.gitconfig当前用户所有仓库中local.git/config当前仓库高配置优先级的规律很好记越靠近当前仓库的配置优先级越高。local会覆盖globalglobal会覆盖system。查看当前所有生效的配置git config --list --show-origin这个命令会详细显示每个配置项来自哪个文件排查问题的时候非常好用。比如你发现某个仓库的提交用户名不符合预期先用这个命令看看是哪一层配置出了问题。设置用户名和邮箱# 当前用户级别 git config --global user.name Your Name git config --global user.email your_emailexample.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。在LinuxWindows混合团队中Windows端设置core.autocrlf true提交时CRLF转LF检出时LF转CRLFLinux端设置input即可。文件权限配置core.fileModeGit会默认记录文件的可执行权限。在某些场景下比如权限频繁变化但代码内容不变的目录这种权限变化会被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 -pgit 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:修复bugdocs:文档变更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 --authorzhangsan其中git log --graph --oneline --all几乎是我每天必用的命令视觉上可以一目了然地看到分支分叉、合并的时间线和结构。对于刚接手项目的人第一条建议就是先跑这个命令摸清主干和分支的脉络。4. 完整实操流程从克隆到推送再到免密配置这应该是这篇文章里最具“抄作业”价值的部分。我会用一个非常典型的场景串一遍完整流程你接手了一个项目需要把代码拉到Linux服务器上修改后推送回远程仓库并配置好免密登录。4.1 生成SSH密钥并配置免密登录不管是使用GitHub还是GitLab推荐通过SSH协议来进行认证因为SSH密钥验证比HTTPS密码认证更安全、更便利。第一步生成SSH密钥对ssh-keygen -t ed25519 -C your_emailexample.com这里我建议使用ed25519算法它比传统的RSA 2048更安全且生成的密钥更短。如果你用的是老系统对ed25519支持不好再退回RSAssh-keygen -t rsa -b 4096 -C your_emailexample.com执行后会有几个交互提示直接回车默认即可。如果想给私钥设置口令推荐可以输入一个口令短语。第二步把公钥添加到托管平台查看公钥内容cat ~/.ssh/id_ed25519.pub复制输出的完整内容进入GitHub/GitLab的设置页面找到SSH Keys - Add new粘贴并保存。第三步验证SSH连接ssh -T gitgithub.com # 或 ssh -T gitgitlab.com第一次连接会提示确认主机指纹输入yes即可。成功后会显示欢迎信息比如GitHub会提示Hi 你的用户名! Youve 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 gitgithub.com:username/project.git # 或者指定本地目录名 git clone gitgithub.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 mainrebase的含义是把当前分支的提交“逐个”搬到目标分支的最新提交之上让提交历史变成一条干净的直线。但有一条铁律不要对已推送到远程的公共分支执行rebase因为这会重写历史导致其他协作者的本地仓库与远程分叉造成比merge冲突更棘手的混乱。我可以现身说法我有一次在公共分支上执行rebase改写了几个提交后强行pushgit 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 gitgithub.com:username/project.git # 修改已有远程地址比如仓库迁移后 git remote set-url origin gitgithub.com:username/new-project.git这里特别提一下仓库迁移的场景。公司内部Git地址变更很常见我之前遇到过一种情况远程仓库迁移到新域团队成员一个个把老地址删了再小心翼翼地添加新地址。其实git remote set-url一条命令就搞定不需要删了再加。回滚操作# 软回退保留工作区和暂存区撤销提交 git reset --soft HEAD~1 # 混合回退保留工作区撤销提交和暂存 git reset --mixed HEAD~1 # 这是默认行为 # 硬回退彻底回到上次提交工作区修改不保留慎用 git reset --hard HEAD~1git 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就会导致命令找不到。解决办法是把路径加到~/.bashrcexport PATH$PATH:/usr/local/bin source ~/.bashrc5.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.pem5.3 认证失败login failed. check api token or gitlab version这个报错常见于GitLab操作可能是API token过期、权限不足或GitLab版本过旧与Git客户端不兼容导致。我的排查思路如下先确认token是否有效在GitLab个人设置中重新生成一个token注意勾选所需权限范围read_repository、write_repository等检查GitLab版本是否过旧旧版GitLab与新版Git客户端之间存在一些协议兼容问题最简单的办法是升级GitLab或者客户端改用SSH方式连接这里我再多一句嘴如果你是在浏览器里登录GitLab复制URL时带出了tokenURL里暴露token本身就是安全隐患。尽量改用remote set-url配置成gitgitlab地址:用户/项目.git的SSH形式更安全也少了很多token超时的烦恼。5.4 换行符导致的诡异大范围diff场景你只是修改了文件里一行代码但git diff显示整个文件中几百行都变了。原因文件行尾是CRLF而Git配置的autocrlf没有正确工作。解决办法# 检查当前仓库的autocrlf配置 git config --list | grep autocrlf # 设置为inputLinux下 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 push5.7 提交历史中的敏感信息另一个常见问题密码、密钥、token等敏感信息被提交进了Git历史。即使你当前的提交把它们删除了只要历史上存在过就仍然可以通过git log翻出来。如果有这样的场景需要改写历史。对尚未推送到远程的提交可以直接用git rebase -i修改。如果已经推送到远程处理会相对麻烦需要重写历史后强制推送同时通知所有协作者同步。最有效的防范措施是事前预防在.gitignore中添加敏感的配置文件使用gitleaks、trufflehog等工具扫描历史提交对核心密钥统一使用环境变量或密钥管理服务不写入代码仓库我在给一个团队做安全自检时发现他们的历史提交里躺着一个数据库连接密码——因为很久之前项目刚起步时为了省事写死在配置里。好在项目还没对外否则这个隐患相当严重。最后我们做了历史重写把所有包含敏感信息的提交抹掉了同时强制改了所有原来的密码。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 statusgit 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使用对你来说就不再是“知识”而是“手感”了。