刚开始用Git的人十有八九都经历过这样的场面照着教程敲完了git init、git add、git commit看着屏幕上跳出来的提交记录还觉得自己挺厉害转头换个分支、改个提交信息、处理一次冲突整个人就懵了。更别提在某天打开IDE的控制台发现Git命令前面挂着一长串-c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks还以为是哪里出了问题。这篇东西不是把Git文档重新抄一遍而是按我自己用下来的经验从安装、配置、日常高频命令到git commit --amend和IDE隐藏参数这些容易卡住人的细节串成一条能直接上手干活的主线。标题叫“Git的简单使用”但我想说的“简单”不是把命令缩减到五个而是把每个动作背后为什么这么做讲清楚踩过的坑也一并放在里面。1. 安装这一步很多人在换行符上埋了雷1.1 三个平台的最低成本装法先说Windows。直接去Git官网下载Git for Windows安装包双击一路Next基本能用。但有两个选项值得注意一个是默认编辑器建议选Visual Studio Code或者Nano别用Vim不是Vim不好是初学者在Windows的Git Bash里误入Vim之后退出都要靠运气。另一个是环境变量选项选“Use Git from the Windows Command Prompt”这样后面在PowerShell或CMD里也能直接敲Git命令方便很多。macOS就简单了几条命令的事。先试着直接跑git --version新版macOS会弹出安装Command Line Tools的引导不弹就自己装Xcode Command Line Tools或者用Homebrew装brew install git。Linux这边Ubuntu/Debian用sudo apt install gitCentOS/RHEL系用sudo yum install gitFedora用sudo dnf install git。装完验证一下终端输入git --version能打出git version 2.x.x就说明装上了。1.2 为什么装Windows版时要专门勾选Git Bash很多Windows新手会问我直接在CMD里用Git不行吗为什么非要装个Git Bash原因是绝大多数教程、文档里的命令都是Linux风格路径用正斜杠/参数拼法和环境变量处理也和Windows原生命令行不一样。你拿CMD执行git log --oneline这种简单命令问题不大一旦遇到引号嵌套、管道符、换行处理行为就不完全一致了。Git Bash本质上是在Windows里模拟一个Linux风格的终端环境Git目录、目录结构、文件权限的显示逻辑都更接近Unix习惯。我当时吃过一次亏在CMD里跑一个包含多行commit信息的命令引号被CMD转义得面目全非最后提交信息完全错乱。换了Git Bash之后这类问题基本绝迹。所以我的建议很简单Windows用户安装时勾选Git Bash日常操作都在Git Bash里进行它同时满足“磨炼终端手感”和“少踩转义坑”两个需求。1.3 换行符问题不配置好的话整个团队diff都是红的第一次装完Git最容易忽略的就是换行符。Windows和Linux/macOS对换行的存储方式不一样Windows用的是CRLF回车换行Unix系用的是LF仅换行。如果不同平台的人协作同一个仓库Git在你提交时会自动把换行转换来转换去出现的结果就是——你明明只改了一行代码git diff却把整个文件标记成改动因为每一行的行尾都被替换了。建议统一配置为git config --global core.autocrlf input这句的意思是仓库里统一存LF在Windows检出时转换成CRLF方便本地编辑在Linux/macOS下保持LF。团队里把这句话放到文档里写上能省掉一大半换行符引起的冲突。2. 初始配置提交记录里那行“作者”是怎么来的2.1 三级配置体系与优先级装完Git第一件事不是clone仓库而是告诉Git你是谁。否则提交的时候Git会报错或者写上一串奇怪的名字。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里牵扯到Git配置的层级体系理解了它后面很多莫名其妙的“为什么我的配置不生效”就迎刃而解。Git配置分三档system级别作用于整台机器所有用户配置文件在Git安装目录或/etc/gitconfigglobal级别作用于当前系统用户配置文件在~/.gitconfiglocal级别作用于当前仓库配置文件在仓库目录下.git/config优先级是local global system。也就是说全局配错了没关系在某个特定仓库里用local配置覆盖即可。排查配置可以用git config --list --show-origin它会列出每一条配置来自哪个文件。我看过很多同事说“我明明配了用户名怎么还是旧名字”一查是某条local配置压过了global里的新配置。2.2 除了用户名邮箱这几条配置我建议顺手配掉git config --global init.defaultBranch main git config --global pull.rebase false git config --global core.quotepath false git config --global color.ui trueinit.defaultBranch main让git init创建默认分支是main而老版本默认叫master现在很少有人愿意看到后者的历史原因——纯粹是新习惯问题。pull.rebase false合并方式切到默认的merge避免新人执行git pull时因为rebase吓得以为历史被改了。想体验rebase后再手动改也行但新手阶段merge更稳。core.quotepath false这条直接解决中文文件名乱码。默认情况下Git对非ASCII字符的文件名会显示成\345\217\202\350\200\203这种八进制转义改成false后正常显示中文。我在IDEA的Git面板里看到中文文件名变乱码很多就是这台机器没设置这条。color.ui true终端里高亮显示Git输出可读性提升一大截。配置完成之后可以用git config user.name和git config user.email验证是否生效。3. 密钥配置为什么要让Git“认识”你的电脑3.1 SSH与HTTPS的选择逻辑托管平台的连接方式主要有两种HTTPS和SSH。HTTPS最直观克隆时填账号密码或者Token但它每次推送都可能要求凭证频繁得让人烦躁。SSH则是通过一对公私钥完成身份认证公钥放在平台比如Gitee私钥留在本机。推送、拉取都不需要反复输入密码这才是日常开发的舒服姿势。以Gitee为例说明。首先检查本机是否已有密钥ls -al ~/.ssh看有没有id_ed25519.pub或id_rsa.pub。如果没有生成新的密钥。我推荐用ED25519算法它比传统RSA密钥更短、生成更快、安全性也足够高。ssh-keygen -t ed25519 -C 你的邮箱生成的路径默认是~/.ssh/id_ed25519.pub建议一路回车不要设密码否则每次SSH连接都要输入口令体验和HTTPS没区别了。拿到公钥之后查看内容cat ~/.ssh/id_ed25519.pub复制整行粘贴到Gitee的「设置」-「SSH公钥」里标题随便填公钥填进去保存。验证是否配置成功ssh -T gitgitee.com第一次会提示确认主机指纹输入yes回车。如果看到类似“欢迎”的反馈说明密钥配对成功。3.2 多个平台的密钥互不干扰有人同时用Gitee和GitHub如果给两个平台用的是同一个私钥一旦某个平台信息泄露另一个平台也受影响。更稳妥的做法是为不同平台生成不同的密钥然后通过配置文件分流在~/.ssh/config里写入类似这样的内容Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github这样Git会自动根据域名选择对应的私钥文件。配置完成后分别执行一下ssh -T gitgitee.com和ssh -T gitgithub.com验证即可。需要提醒的是私钥文件无.pub后缀的那个绝对不能泄露也不能提交进Git仓库。如果你不小心把私钥加进了仓库并推到了远程哪怕删除了文件也要立刻吊销该密钥重新生成——历史提交记录里依然躺着完整的私钥内容。4. 日常高频命令别背命令记住这张工作流程图4.1 克隆、状态、暂存、提交刚开始用Git最容易陷入“背命令”的误区。我的建议是把命令按使用场景分组理解每组在解决什么问题。第一组是获取代码和查看状态。git clone拉取远程仓库git status查看当前工作区有哪些改动。这两条命令没有任何风险任何时刻都可以放心执行。git status的输出分三块已暂存改动、未暂存改动、未跟踪文件。刚入门的理解方式就一句话工作区是草稿暂存区是待提交清单提交记录是存档。第二组是添加和提交。git add把改动加入暂存区git commit打好存档。组合命令是git add . git commit -m 提交说明git add .会把当前目录所有改动都加进暂存区简单粗暴但容易把不需要提交的文件也加进去。更好的习惯是git add src/HelloWorld.java git status git commit -m 完成某某模块先add明确文件再用git status确认暂存区内容最后再提交。尤其中大型项目每天提交之前看一遍暂存区能拦住至少一半的“误提交”。4.2 推送、拉取、分支单机操作和多人协作的分界线提交只是本地动作真正的协作从推送和拉取开始。git push把本地提交推送到远程git pull把远程提交合并到本地。git pull本质上是git fetch加git merge理解这一点后续遇到pull时的合并冲突就好分析得多。分支操作是多人协作的核心。看一眼项目里常见的命令组合git branch # 查看本地分支 git checkout -b feature # 基于当前分支新建并切换到feature分支 git checkout main # 切回主分支 git branch -d feature # 删除已合并的feature分支为什么推荐基于分支开发因为主分支通常是main/master代表稳定可发布的版本所有新功能、修bug都在独立分支上进行验证通过后再合并回去。这样即使某次提交写坏了代码也不会直接影响主分支上其他同事的工作。4.3 从今天开始的工作流一个新需求的完整Git闭环假设手头接了一个新需求以我平时的工作流为例git checkout main git pull git checkout -b feature/order-export # 写代码、自测 git add . git commit -m 新增订单导出功能 git push -u origin feature/order-export在远程仓库里发起合并请求MR/PR等评审通过后合并本地再切回主分支拉取最新代码。这个流程覆盖了日常工作80%的操作“简单使用”照这个走不会迷路。这里有一个容易踩的坑在错误的基线上开新分支。比如还没git pull就直接git checkout -b feature新分支的基础是旧的master等你提交完发现远程master已经前进了一大截合并时冲突面会大很多。每次开新分支前先git pull更新基础是成本最低的防冲突手段。5. 提交写错了怎么办git commit --amend以及那些“收回”提交的办法5.1 amend的三种典型场景热词里有“git commit --amend怎么使用”这是绝大多数人会遇到的情况刚提交完就发现提交信息拼错了、忘了加某个文件进去、或者想补充一点改动进上一条提交。git commit --amend就是干这个的它允许你修改上一次提交。三个典型用法改提交信息。上一条提交信息写得词不达意想重新来git commit --amend -m 正确的提交信息补漏文件。上一条提交少了某个文件先把它加进暂存区git add 遗漏的文件 git commit --amend --no-edit--no-edit表示保持原提交信息不变只更新内容。这样不会把你带入编辑器重新写一遍信息。修改作者信息。有时候提交用的用户名错了git commit --amend --author正确名字 正确邮箱 --no-edit5.2 最重要的边界amend只适用于“尚未推送”的提交git commit --amend的底层实现是用一个新的提交对象替换掉原来那个提交新提交的parent和原提交一致只是内容更新了。副作用是提交的哈希值变了。如果你的提交已经推送到远程而别人基于那个旧提交开发了代码那么本地amend后再次push远程会拒绝因为历史已经在远端被改写。此时如果用git push --force强行覆盖远程历史队友那边会出现大量冲突严重的会把别人基于旧提交整合的东西全打散。所以一个稳妥经验是只要这条提交是你自己刚提交、还没push到远程随便amend。一旦push出去就尽量别再amend。非改不可先和团队说明push时用git push --force-with-lease这个命令比裸的--force多一层保护——它会检查远程分支是否和你上次拉取时一致防止覆盖别人新增的提交。5.3 想改的不是上一条是更早的提交怎么办如果犯错的提交不是最新一条git commit --amend就帮不上忙了。这时候分三种处理方式想改文件内容用git rebase -i HEAD~n进入交互式变基把目标提交标记为edit改完再继续。这个操作会对多个提交重新生成风险较高适合熟练者。想放弃最近几条提交用git reset --soft HEAD~2。--soft会把改动保留在暂存区方便你重新组织提交--hard则连工作区一起回退但会丢改动使用前一定要确认。想保留历史又想让代码回到某个状态用git revert生成反向提交不修改历史适合远程已推送提交的撤销场景。这三个工具选择的依据很简单提交是否已push远程、你希不希望保留历史轨迹。场景推荐命令是否改写历史上一条提交信息或内容有问题未推送git commit --amend是多步提交需要压缩/拆分未推送git rebase -i是纯本地提交想整体回退git reset --soft/hard是已推送且别人可能基于此开发git revert否6. IDE日志里那一长串参数到底在说什么6.1 一条命令的逐段拆解很多人第一次注意到git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks是在IntelliJ IDEA或VS Code的Git控制台里。第一感觉是“这是什么鬼命令”第二感觉是“我是不是点错了什么”。其实这条命令就是IDE在调用外部Git时给Git追加的一组临时配置和开关。先看格式git -c keyvalue表示在本次执行中临时设置一条配置等价于在执行前临时往Git配置里加参数但不会真正写进配置文件命令结束后自动失效。第一段-c diff.mnemonicprefixfalse和diff显示格式有关。Git的diff默认把比较的两个版本标记为a/xxx和b/xxx这是mnemonicprefix的表现。IDE一般会关掉这个前缀把文件路径显示得更干净。你平时用命令行敲git diff看到的输出是diff --git a/src/Main.java b/src/Main.java而IDE调用时输出可能是diff --git src/Main.java src/Main.java这就是mnemonicprefix在被禁用后的差异。它让你的diff输出更贴近纯路径比较不会因为a/和b/的前缀干扰文件路径的辨认。第二段-c core.quotepathfalse上面提过是让非ASCII字符比如中文文件名在Git输出里正常显示而不是显示成八进制转义序列。IDEA的Git面板默认要显示文件名的中文如果Git配置里没有core.quotepath falseIDE传这段临时配置过去就是确保每次调用时都生效不依赖全局配置里有没有设置。第三段--no-optional-locks是关键的开关注释。Git在执行某些命令时会在.git目录里创建可选的锁文件用于协调并发操作。在IDE场景下用户可能同时触发多个Git操作刷新状态、拉取、提交如果两个操作都想拿锁其中一个就会等待甚至报错。--no-optional-locks的意思是本次执行中凡是“可以不加锁”的操作一律不加锁。Git只在明确必须一致性保证的操作上才使用强制锁其他辅助性的状态刷新比如读取状态、计算差异就绕开锁避免IDE频繁调用时互相阻塞。6.2 这些参数什么时候需要手动敲看到这段命令不是问题问题是你什么时候需要手动输入它场景一IDE的Git面板里diff显示异常。文件路径前缀显示为a/、b/尝试在终端里手动执行 diff 命令排查时可以加上-c diff.mnemonicprefixfalse让输出和IDE一致方便对照怀疑点。场景二中文文件名乱码。全局配置没来得及改又急着看当前改动时可以直接敲git -c core.quotepathfalse status输出恢复正常也不会影响其他配置。场景三你在写脚本批量调用Git命令担心并发时的锁冲突。脚本里加--no-optional-locks能显著减少“其他Git进程似乎正在运行”的报错。6.3 从使用到懂得参数背后的Git设计思想从这段IDE参数里能品出Git的一条设计主线Git把锁和并发机制做得极其谨慎用可选锁来平衡“一致性”与“可用性”。IDE这种高频率调用的环境每次刷新状态都带强制锁体验会非常僵硬。所以Git提供--no-optional-locks让调用方自己决定是否承担那个微小的一致性风险——状态刷新时看到的可能是稍旧的数据但胜在操作不互相排队。类似的临时参数很多都是同样的-c keyvalue语法。排查问题时可以先用git -c临时调整确认有效后再决定要不要写进全局配置而不是直接改配置文件来回试。这是排查Git行为问题的通用思路先最小化验证再固化配置。实际操作中还有一个小技巧值得分享强烈建议先给自己的常用命令配上别名把每次输入成本降到最低比如git config --global alias.st status、git config --global alias.lg log --oneline --graph --all --decorate。这样日常看历史提交用git lg看状态用git st效率会高很多。刚开始用Git不必贪多把安装、配置、密钥、提交、推送、分支、amend这几件事吃透团队协作里90%的操作你都已经能独立完成了。剩下的等真的遇到再查也不迟。