Git核心操作实战：安装配置、分支合并与回退撤销全攻略

Git这东西属于那种不学也能混一学就回不去的工具。身边不少朋友问我怎么入门我一般不会甩一堆命令让他们背而是建议先把提交、分支、合并、回退这条主干打通剩下的细节都是查文档的事。但真正让新手崩溃的往往是安装配置阶段的一些小坑以及遇到报错时不知道从哪里排查。这篇帖子就是把我自己平时最常用的 Git 操作梳理一遍从安装、配置到日常提交、分支合并、撤销回退再到几个高频疑难问题的处理思路尽量说人话不讲虚的。不管你是在 Windows、macOS 还是 Linux 上开发这篇都值得照着过一遍。1. 装好Git只是开始安装、全局配置与第一个报错1.1 各平台的安装方式与版本选择网上搜git安装能出来一大堆教程但很多教程只说下一步下一步导致很多人装完之后连 Git Bash 和 Git GUI 都分不清。这里先明确一下Git for Windows 安装包里自带的 Git Bash是我们在 Windows 上最常用的终端环境它模拟了 Linux 下的 shell 体验很多 Linux 命令如ls、grep、awk在里面都能直接用。Git GUI 反而是个鸡肋基本可以忽略。各平台安装方面我的建议很直接Windows去 Git 官网下载 Git for Windows安装时除了默认选项只有一个地方建议修改——把默认编辑器换成 VS Code 或者 Notepad别用 Vim。原因是新手一旦在提交信息里触发编辑器困在 Vim 里不知道怎么退出真的会原地崩溃。安装完成后右键菜单里会出现 Git Bash Here说明装好了。macOS系统自带 git 命令的话版本通常偏老建议用 Homebrew 装git或者执行xcode-select --install安装命令行开发者工具后者会附带较新的 git。LinuxDebian/Ubuntu 系直接apt install gitCentOS/RHEL 系用yum install git没什么好纠结的。如果对版本有强制要求就用源码编译但日常开发完全没必要。版本选择上除非公司有特定要求否则直接装最新稳定版即可。git 的版本迭代对 CLI 操作的影响很小主流用法十年都没大变不存在新版本不稳定的问题。1.2 全局配置user.name、user.email 与换行符安装完成后第一件事不是急着建仓库而是配置身份信息。这一步被很多人跳过了结果代码提交到远端之后提交记录上显示的不是自己的名字或者平台根本识别不了提交人。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个细节邮箱最好和你的 GitHub/GitLab 账号绑定的邮箱一致不然提交记录不会关联到你的账号头像上。另外可以用git config --list查看当前所有配置确认是否生效。除了身份还有两个配置是我强烈建议顺势改掉的git config --global core.autocrlf true # Windows 下开启自动处理换行符 git config --global core.quotepath false # 解决中文文件名显示成 \xxx 的问题core.autocrlf解决的是 Windows 和 Linux/macOS 之间最经典的换行符问题Windows 文本文件默认是 CRLF 结尾Linux/macOS 是 LF 结尾。如果不处理团队里有人用 Windows、有人用 macOS每次提交都可能产生一堆无意义的整个文件都被修改的 diff。设置为 true 之后Git 会在提交时把 CRLF 转成 LF 存进仓库检出时再转回 CRLFWindows 用户无感知仓库里始终是干净的 LF。如果你的项目里已经有 .gitattributes 文件在做更细粒度的换行符管理那就以仓库内配置为准。core.quotepath false则是给中文用户贴心准备的。Git 默认会对非 ASCII 字符做转义中文文件名在git status里显示成\346\265\213\350\257\225.txt这种八进制编码看着一头雾水。关掉之后直接显示中文省心很多。1.3 为什么提示git 不是内部或外部命令这个报错是搜索热词里的常客也是很多新手第一个遇到的坎。出现这个提示说明系统在环境变量 PATH 里找不到 git 可执行文件。常见原因有三个一是安装时没有勾选把 Git 加入 PATHGit for Windows 安装过程中有一页问你是否调整 PATH 环境变量选了 Use Git from Git Bash only 就会导致在 CMD 或 PowerShell 里找不到 git二是安装后没有重新打开终端环境变量没刷新三是某些绿色版、便携版 git 解压后压根没有写注册表和环境变量。解决方式分两类如果你只想在 Git Bash 里用 git那不影响因为 Git Bash 内部自己有完整的环境如果你需要在 VS Code 终端、IDEA 内置终端、CMD 或 PowerShell 里用 git那就去系统环境变量设置里手动把 Git 安装目录下的cmd目录例如C:\Program Files\Git\cmd加进 PATH然后重启终端。装完记得验证一下git --version如果输出了类似git version 2.39.2.windows.1的东西说明环境没问题了。1.4 初始化仓库与第一次提交配置完毕就可以创建第一个仓库了。进入项目目录执行git init这句话会在当前目录下生成一个.git文件夹这就是 Git 的版本库所有提交历史、分支指针、配置信息都存在里面。一个常见的误区是把.git当成可以随时删掉的临时文件——它确实是整个仓库的本体删掉之后本地历史全没了远端如果还有副本可以重新 clone但本地未推送的分支就真的丢了。初始化之后建议立刻养成一个习惯看一眼当前状态。git status然后添加文件并提交git add . git commit -m init: 初始化项目git add的作用是把文件加入暂存区indexgit commit才是一次真正的快照记录。很多新手以为git add之后文件就算存上了其实没有commit 之后才算。这个心智模型后面会专门讲现在先把流程跑通。如果你这时候弹出了 Vim 界面说明你 commit 时没带-m参数Git 打开编辑器让你输入提交信息。不想用 Vim 的话要么切到英文输入法依次输入:wq回车退出要么回到 1.1 节提到的把默认编辑器改成 VS Code。2. 每天高频使用的命令组提交、推送、拉取背后的状态机2.1 工作区、暂存区、版本库先建立这个心智模型Git 最核心的概念不是命令而是三个区域工作区Working Directory、暂存区Index/Staging Area、版本库Repository/HEAD。我习惯用一个寄快递的类比来解释工作区是你家里堆的货物暂存区是快递员已经贴上标签、装上车的中转站版本库是快递公司总部的仓库。git add是把货物搬上中转车git commit才是让快递公司把这一车货物登记入库、生成一个快照而git push是把这个仓库里的快照同步给远端的另一个仓库。理解了这个模型很多命令就不再是死记硬背git add file把某个文件的当前内容加入暂存区git commit -m msg把暂存区的内容固化成一个新的提交git status帮你确认现在是哪个分支工作区、暂存区分别有哪些变化git diff比较工作区和暂存区的差异git diff --staged比较暂存区和最后一次提交的差异2.2 status、log、diff 三件套的配合用法日常开发中我最常敲的命令是git status没有之一。它不仅能告诉你哪些文件改了还会给出下一步操作的提示——比如Changes not staged for commit、Untracked files这类信息英文不好的朋友也不要慌认准两个词modified已修改和 untracked未跟踪。git log用于查看提交历史但裸的git log输出太啰嗦我一般用这几种变体git log --oneline # 每个提交一行简洁 git log --oneline --graph # 附带分支线条能看清楚分叉 git log -n 5 # 只看最近 5 条 git log --author张三 # 按作者过滤git diff是看具体改了哪几行的命令。常见用法git diff # 工作区 vs 暂存区 git diff --staged # 暂存区 vs HEAD git diff HEAD # 工作区 暂存区 一起 vs HEAD很多 VSCode 和 JetBrains 系 IDE 已经把这些信息图形化展示在文件里了不习惯终端 diff 的可以依赖 IDE。但至少要知道终端下怎么看因为服务器上排查问题、处理代码评审意见时终端是最可靠的。2.3 clone、remote、pull 与 push和远端打交道的方式项目参与协作第一步通常不是git init而是git clone。git clone https://github.com/某用户/某项目.git这条命令做了三件事在当前目录创建项目文件夹、把远端仓库完整下载到本地、自动把远端地址注册为一个名为origin的远程仓库别名。所以 clone 完之后不需要再手动git remote add origin。只有你自己git init创建的仓库才需要手动关联远端git remote add origin https://github.com/某用户/某项目.git git remote -v # 查看当前关联的远端地址日常同步的节奏是先拉后推拉的时候尽量用git pull --rebase。这里解释一下为什么。普通git pull等同于git fetchgit merge会把远端新提交和本地提交合并成一个分叉再 merge产生一条多余的Merge branch提交记录而git pull --rebase是先把本地未推送的提交摘下来拉到远端最新提交之后再把本地提交一个个重新放上去提交历史是一条直线干净得多。当然rebase 也有副作用如果本地和远端改的是同一个文件的同一个地方rebase 过程中会触发冲突处理完再继续而 merge 是把冲突集中到一起处理。后面第 4 节会细讲这两种方式的选择策略。2.4 push 被拒绝时的标准处理流程新手最容易懵的场景git push报错 failed to push some refs to ...提示远端有新提交、本地落后。这时候千万不要用git push --force硬推——这是把远端提交覆盖掉的操作极危险。正确流程是git pull --rebase把远端更新拉下来让本地提交叠加到最新之上如果 rebase 过程中有冲突解决后git add 冲突文件再git rebase --continuegit push重新推送有时候 IDEA 或 VS Code 的图形化按钮会直接帮你执行类似操作逻辑相同先同步远端再处理冲突再推送。记住一个铁律多人共用的分支上永远不要用 force push。除非这个分支只有你一个人在用且你明确知道自己在做什么比如刚 rebase 完本地提交历史需要强制更新自己的 feature 分支。3. 撤销不是删掉重来restore、reset、revert 的正确打开方式3.1 还没提交的改动怎么恢复原样场景一你改了一个文件改坏了想放弃所有修改回到上次提交的状态。命令是git restore file # 或老版本写法 git checkout -- file如果你的修改已经git add进暂存区了想撤销暂存但保留工作区改动用git restore --staged file这个--staged非常常用。比如你本来想提交 A 文件结果手滑git add .把所有文件都加了进去其中 B 文件还不想提交就执行git restore --staged B把它从暂存区拿出来。注意这个操作只影响暂存区里有没有这个文件不影响工作区文件的实际内容。如果想把全部未提交的改动都扔掉git restore .我见过不少人在网上找怎么撤销 git add得到的答案是git reset HEAD file。这个老命令现在依然有效但 git 2.23 之后官方更推荐用git restore --staged语义更清晰一个负责恢复文件内容一个负责调整暂存状态职责分明。3.2 已经 commit 但没 push怎么回退提交后发现提交信息写错了、或者想把最近几条提交合并掉这时候本地历史还没同步到远端可以放心地改写历史。最常用的是git reset。git reset --soft HEAD~1 # 撤销最近一次提交但保留改动在暂存区 git reset --mixed HEAD~1 # 撤销提交和暂存保留改动在工作区默认 git reset --hard HEAD~1 # 撤销提交且丢弃所有改动危险三种模式的区别同样用快递类比--soft是把快递从总部仓库拿回中转站标签还在--mixed默认模式是把快递退回你家里但东西还在--hard是直接把货扔了彻底没了。实际场景中--soft常用于合并提交连续提交了三次想把它们压缩成一个那就git reset --soft HEAD~3然后重新git commit。--hard则要慎用因为工作区所有未提交的改动和这些提交里的改动会一并丢失。如果已经 push 过的提交最好不要用 reset 去回退原因很简单你和远端历史不一致下次 push 必须 force会污染公共分支。3.3 已经 push 的提交用 revert 而非 reset提交已经推到远端且被同事拉取了此时想撤销某个功能正确的做法是git revert commit-hashgit revert不是回到过去而是产生一个新提交把目标提交的改动反向应用一遍。它的好处是不动历史只追加一条新的提交记录所有同事都能正常 pull不会出现历史分叉和 force push。项目实践里线上代码回滚几乎都是用 revert。比如某个 commit 引入了一个 bug你找到它的 hash 后执行git revert abcd1234Git 会自动生成一个反提交把问题代码从最新代码里去掉。最后讲一个保命技能git reflog。它是 Git 的操作日志记录了你每一次 HEAD 移动的历史包括 reset、rebase、checkout 等操作。哪怕你git reset --hard之后后悔了也能通过 reflog 找到之前的 commit hash再用git reset --hard hash回到原来的位置。我的实践习惯是任何危险操作之前先敲一下git reflog或者至少记住当前分支的 commit hash心里有个底。4. 分支与合并从创建到冲突处理的全流程4.1 分支的创建、切换与删除分支是 Git 最强大的特性但很多新手把它想复杂了。实际上分支就是一个指向某个 commit 的指针创建分支的成本极低几乎为零。日常开发的标准姿势是主分支保持稳定每个新功能拉一个分支开发完合并回去。git branch feature/login # 创建分支 git checkout feature/login # 切换分支老命令 git switch feature/login # 切换分支新命令语义更清晰 git checkout -b feature/login # 创建并切换常用 git switch -c feature/login # 同上新命令写法一条建议从我开始就用git switch系列命令避免和git checkout的恢复文件语义混淆。切换分支时还有一个让很多人困惑的现象如果你工作区有未提交的改动切分支时 Git 会把这些改动带过去如果目标分支和当前分支对这些文件的内容冲突Git 会拒绝切换提示你先提交或 stash。这不是 Bug是保护机制防止你丢失工作。删除分支也不难git branch -d feature/login # 安全删除未合并时会拒绝 git branch -D feature/login # 强制删除不管是否合并推送到远端后想删远端分支git push origin --delete feature/login4.2 merge 和 rebase两条路线怎么选合并代码有两种方式理解它们的区别是 Git 使用水平的分水岭。git merge把两个分支的历史合并成一个新的合并提交。优点是操作简单、保留完整历史包括分叉和合并的时间线缺点是历史里会出现很多Merge branch ... into ...的提交多人协作久了git log --graph看起来像一团毛线。git rebase把自己分支上的提交搬家到目标分支的最新提交之后。优点是提交历史是一条直线非常清爽缺点是改写了自己分支的提交记录如果这个分支已经 push 到远端并且其他人也在用就会造成历史混乱。我的选择策略很简单本地功能分支合并回主分支之前先git rebase main把主分支的新提交拉过来确保本地分支基于最新代码再切回主分支git merge 功能分支。这样既保持主分支历史干净又避免了在公共分支上 rebase。如果是多人共用的开发分支禁止 rebase一律 merge。团队协同时约定好公共分支只 merge个人分支随意 rebase。4.3 冲突的产生根源与完整排查链路冲突是 Git 使用中绕不开的话题也是搜索热词里占了很大比重的一个词。先弄明白它为什么发生两个分支修改了同一个文件的同一块区域Git 无法判断哪份改动是正确的于是停下来让人类裁决。我把自己处理冲突的完整流程记录下来照着做基本不会卡壳。第一步触发冲突。比如我在 feature/login 分支合并主分支时git merge mainGit 输出CONFLICT (content): Merge conflict in src/login.js。此时不要慌不要关终端文件已经处于合并中的状态。第二步查看冲突文件列表git status冲突文件会显示在 Unmerged paths 区域。第三步打开冲突文件。文件里会出现类似这样的标记 HEAD const title 登录; const title Login; feature/login HEAD到之间是当前分支HEAD的内容到 feature/login之间是被合并分支的内容。你需要做的是决定保留哪一份、还是两份都加工一下然后把包括、、在内的所有标记行删除。第四步标记为已解决并继续git add src/login.js git merge --continuegit merge --continue会打开编辑器让你填合并信息通常保留默认信息直接保存退出即可。如果用的是 IDEA、VS Code 或 TortoiseGit小乌龟冲突解决界面会提供左右对比和接受当前/接受传入/合并两者的按钮比纯终端操作直观得多。我个人的经验是纯文本冲突用 IDE 解决了之后最好回到终端跑一遍git status和git diff --check确认没有遗漏冲突标记。git diff --check能检测出残留的冲突标记和行尾空白是个很实用的小技巧。第五步从根源上减少冲突。冲突不是靠会解决就行的更值得做的是预防。几条实战建议每个任务尽量小步提交避免一次性改几百行每天上班第一件事git pull --rebase别让本地落后太多同一文件如果有两个人同时大改提前在群里打个招呼格式化工具的配置Prettier、ESLint 的缩进规则必须统一否则每次格式化都会产生全文件 diff 冲突。我见过太多冲突其实不是逻辑冲突而是有人改了 4 空格缩进、有人改成 2 空格导致的。5. 忽略文件、标签与临时保存几个能明显提升效率的细节5.1 .gitignore该忽略的坚决不提交每个项目都应该在根目录放一个.gitignore文件告诉 Git 哪些文件不要纳入版本管理。常见的忽略对象包括依赖目录node_modules、vendor、编译产物dist、build、target、IDE 配置文件.idea、.vscode 里的个人配置、环境变量文件.env、.local 后缀、系统文件.DS_Store、Thumbs.db。一个最基础的 Node.js 项目忽略文件长这样node_modules/ dist/ .env *.log .DS_Store写 .gitignore 时有三个特别容易踩的坑单独说一下第一已跟踪的文件不受 .gitignore 影响。如果你之前已经把某个文件提交进仓库了之后在 .gitignore 里加上它也不会生效。需要先把它从版本库中移除git rm --cached file--cached表示只把文件从暂存区/版本库移除保留本地磁盘文件。这招在误提交了.env、target/这类文件时非常常用。第二目录和通配符的写法有讲究。node_modules/带斜杠表示忽略整个目录*.log忽略任何层级的 .log 文件build/表示忽略所有叫 build 的目录而/build/开头的斜杠表示只在仓库根目录下的 build 目录生效。第三想验证一条忽略规则是否生效用git check-ignore -v file它会告诉你匹配到了 .gitignore 里的哪一行。这个命令冷门但排查为什么这个文件没被忽略时极其有效。5.2 tag 标签给关键版本打点标签是对某个提交打上的锚点通常用于标记发布版本比如 v1.0.0、v2.3.1。标签分两种轻量标签lightweight和附注标签annotated。轻量标签只是一个指向提交的引用附注标签则包含打标签的人、时间、说明信息。发布版本时强烈建议用附注标签git tag -a v1.0.0 -m 发布 1.0.0 版本 git tag # 列出所有标签 git show v1.0.0 # 查看标签详情注意git push默认不会推送标签需要显式执行git push origin v1.0.0 # 推送指定标签 git push origin --tags # 推送所有标签删除远程标签的方式是git push origin --delete v1.0.0。日常开发中如果项目没有严格的发布流程标签可能用得不多但一旦需要回溯某个线上版本的代码标签的价值就体现出来了git checkout v1.0.0一键切到发布版本比翻 commit 找 hash 靠谱得多。5.3 git stash手头活没干完临时切分支经常遇到这种场景正在 feature/A 分支上写代码写到一半突然线上有紧急 Bug 需要立刻切到 main 分支修复。直接切分支Git 会把未提交的改动带过去容易污染主分支提交一个半成品 commit 又不想留。这时候就该git stash出场了。git stash # 把当前未提交的改动暂存起来工作区变干净 git stash list # 查看暂存的改动列表 git stash pop # 恢复最近一次暂存的改动并从列表移除 git stash apply # 恢复改动但保留在列表里用于多次恢复 git stash drop # 丢弃某个暂存一个容易忽略的细节git stash默认只暂存已跟踪文件的改动新建的、还没git add过的文件不会被 stash。如果想把未跟踪文件也一起暂存用git stash -uu 是 untracked 的首字母。这一点不记住的话很容易出现stash 完发现新写的文件还留在原地的困惑。6. 高频疑难杂症我踩过的坑和排查顺序6.1 fatal: not a git repository (or any of the parent directories): .git这个报错字面意思是当前目录不是 Git 仓库且上级目录也不是。常见于三种情况一是在git init之前的目录里执行 git 命令。解决办法在项目根目录先执行git init。二是你在某个子目录里执行命令但这个子目录不属于任何 Git 仓库。Git 查找仓库的方式是从当前目录逐级向上找 .git 文件夹如果整个路径都没有就报这个错。解决办法进入项目根目录再执行或者确认是否真的在仓库范围内。三是最阴间的目录里存在.git文件而不是.git文件夹。Git 支持一种子模块/工作树机制.git可以是一个文本文件内容指向真实的 git 目录。如果你用 IDE 或某些工具复制项目时只复制了部分文件.git文件里的相对路径失效就会在各种命令下报类似错误。排查这类问题我的习惯是先ls -la看当前目录有没有.git再git rev-parse --show-toplevel看 Git 认为的仓库根目录在哪里对照一下是不是自己以为的位置。6.2 免密配置告别每次 push 输账号密码频繁输入用户名密码很烦人免密配置是搜索热词里的高频需求。有两种主流方案。方案一凭据管理器适合 HTTPS 协议。Windows 下安装 Git for Windows 时默认就自带了 Git Credential Manager第一次 push 会弹出窗口让你登录之后凭据会被安全保存后续不再重复询问。如果之前不小心选了不保存可以手动开启git config --global credential.helper managermacOS 下对应的工具叫 osxkeychainLinux 下一般是libsecret或cache内存缓存默认缓存 15 分钟。方案二SSH 密钥适合 SSH 协议。生成密钥对ssh-keygen -t ed25519 -C 你的邮箱一路回车后把~/.ssh/id_ed25519.pub的内容复制到 GitLab/GitHub 的 SSH Keys 设置页面。之后把仓库地址换成 SSH 格式如gitgithub.com:user/repo.git就可以免密推送。SSH 方案的优点是一次配置、全平台通用且比 HTTPS 更受老开发者偏爱。如果你用的是 TortoiseGit小乌龟它在首次 push 时也会有自己的凭据弹窗找到 Load Putty Key 之类的选项或者直接在设置里指定 OpenSSH 作为 SSH 客户端否则可能出现Git 命令行能免密但小乌龟不行的奇怪现象。6.3 那些让人抓狂的报错GitLab API Token 失败与中文显示搜索热词里有一条很具体login failed. check api token or gitlab version. log in via git if the version is too old。这个报错通常出现在旧版本 IDE 的 GitLab 插件试图通过 API Token 连接 GitLab 时。排查顺序我建议这样走先在浏览器里确认你的 GitLab 账号能正常登录再确认是否创建了 Personal Access Token以及 Token 的权限范围是否包含api和read_repository最后检查 GitLab 服务器版本是否太老API 接口不兼容。很多时候最简单的绕过方式是放弃 API Token 方式直接用账号密码走 HTTPS 克隆不折腾插件。另一个我很想呼吁的是不要在项目路径和文件名里用中文和空格。虽然 Git 本身支持core.quotepath false也能正常显示中文但很多命令行工具、脚本、构建工具对非 ASCII 路径支持并不好。之前一个同事的项目放在D:\工作\需求文档终版\项目A\下IDEA 终端里执行 npm 脚本各种玄学报错最后把整个目录改成纯英文路径问题全没了。不是你操作错了是工具链对路径编码的支持参差不齐别跟它较劲。6.4 关于 .git 目录泄露的防范提醒搜索词里有一类git目录泄露如何下载这里想从另一个角度多说一句如果你的代码仓库是私有项目或者包含敏感信息就一定要注意不要把这些内容泄露出去。比较常见的场景有把整个项目文件夹连同.git一起打包发给了外部人员、或者部署到服务器后把.git目录也暴露在 Web 根目录下、或者把项目压缩包上传到了公开渠道。由于.git里保存着完整的提交历史和所有历史版本的文件内容一旦泄露等于把整个代码库的所有版本都送出去了比你单独泄露某个文件严重得多。几个我日常执行的安全习惯新增一个.gitignore规则把.git如果确实是粘贴进来的排除部署前检查目标目录结构确保 Web 服务根目录不包含.git压缩分发给外部人员前先删除.git目录或者用git archive命令导出干净的代码包。git archive --formatzip -o project.zip HEAD这个命令很适合用来生成发布用的源码包它只包含已提交的文件不包含 .git 历史干净又安全。6.5 GUI 工具与编辑器的 Git 集成最后聊聊工具。很多人问要不要学 Git Bash 命令行我的看法是命令行是必修但不是唯一的使用方式。日常开发中80% 的场景用 IDE 的图形按钮就能完成——VSCode 里的源代码管理面板、IDEA 的 Git 工具栏、TortoiseGit 的右键菜单都做得很成熟。特别提一下 VSCode它在执行 Git 操作时会自带一串参数类似git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks这是编辑器在调用 Git 命令时为解决差异显示、中文路径、文件锁等问题自动附加的配置项不用管但你至少要知道即使是从图形界面操作 Git底层调用的仍然是 git 命令。所以当图形界面报错时切到终端手动执行一遍对应命令往往能获得更完整的报错信息排查思路也更清楚。TortoiseGit小乌龟在 Windows 上依然有它的受众它把 Git 集成进了资源管理器右键菜单提交、拉取、比较、分支管理都有图形化界面。如果你是 Java 或后端方向IDEA 的 Git 面板我建议每天用一用commit、push、pull 都有快捷键还能直接在 IDE 里完成 rebase 和冲突解决效率很高。我自己平时还有一个很低成本但很实用的习惯给git status、git log这种高频命令配短别名。git config --global alias.st status git config --global alias.lg log --oneline --graph --all之后输入git st、git lg就能快速查看状态和历史。这算不上什么技巧纯粹是减少键盘负担。如果你刚开始系统学 Git我的建议是先把手动流程走通——init、add、commit、push、pull、merge再慢慢扩展到 reset、rebase、stash 这些进阶操作。每一个命令都先在自己本地的小项目里练熟了再拿到团队项目里用。等你哪一天遇到问题第一反应是想到用什么命令去排查、而不是直接上网搜答案时Git 的常用操作这关就算真正过了。