前几天有个刚接触编程的朋友指着IDE控制台里的长命令问我“这串像乱码一样的git命令是什么我是不是点错了”我凑过去一看是git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks ...。他说自己只是想提交一下代码结果被这段“神秘字符”吓住了还以为是出错了。其实这串命令在很多代码工具里很常见本质上是IDE在调用Git时附带的一组参数。正好这也勾起了我一直想写一篇Git基础教程的念头——从安装配置到日常命令从分支合并到改提交信息把最常用、最容易踩坑的部分一次说清楚。这篇文章适合刚接触Git或者用了一段时间但总靠“复制粘贴”混过去的同学。内容包括Git下载安装教程、日常提交如何操作、分支怎么合并、git commit --amend怎么用、Gitee密钥怎么配置以及IDE背后那些自动生成的命令到底是什么意思。我会尽量用大白话讲原理再配可直接照做的命令希望你看完能从“半懂不懂”变成“会用且知道为什么”。1. 装好Git下载安装与首次启动1.1 Git下载安装教程Windows、macOS、Linux怎么选Git的安装不算难但不少人会卡在“到底选哪个版本”上。Windows用户直接去官网下载Git for Windows。官网默认会识别你的系统但要注意如果电脑是64位系统建议选64-bit Git for Windows安装包别下成32位版。安装过程中很多选项可以保持默认有几个关键点要留意。一直点Next到“调整你的PATH环境变量”那一屏通常选Git from the command line and also from 3rd-party software。这个选项会把Git命令加到系统PATH里保证以后在CMD、PowerShell、以及各种IDE中都能直接调用git命令。如果选了别的可能打开终端敲git就提示找不到命令。还有一个常见选择是换行符转换方式默认的Checkout Windows-style, commit Unix-style line endings对团队合作最友好我建议保持这个默认选项。macOS用户最简单的办法是直接安装Xcode Command Line Tools在终端输入git --version如果没装系统会提示你安装也可以用官方pkg安装包或Homebrew安装。Linux用户则根据发行版选择包管理器比如Debian/Ubuntu用sudo apt install gitCentOS/RHEL用yum install git或dnf install git。装完之后在终端里敲git --version如果能输出版本号说明安装成功了。我看到有些新手在这一步就开始纠结版本新不新其实只要别太老能用就好。真正影响日常使用的是后面的基础配置不是版本号。1.2 装完必做配置用户名和邮箱Git安装完成后第一步不是急着建仓库而是告诉Git“你是谁”。因为每次提交commit都会记录作者信息如果你不设置Git会拿你系统的用户名和主机名去猜提交记录里就会显示奇怪的名字将来不管是自己找历史还是团队成员看提交都会一脸懵。配置命令非常简单在终端执行git config --global user.name 你的名字 git config --global user.email 你的邮箱这里面的--global表示全局配置对所有仓库生效。如果你在不同平台比如Gitee、GitHub使用不同邮箱也可以去掉--global然后进入某个仓库单独设置。不过我个人的习惯是尽量用同一个邮箱和代码托管平台账号对应上提交历史里更容易识别。配置完可以查看一下git config --list你会看到一堆配置项包括用户名和邮箱。要重点提醒的是这个邮箱最好与你在代码托管平台注册的邮箱一致。如果不一致推送到远端时平台可能会不认识你导致贡献图不亮、统计不到你的记录。这个坑我见过太多次新同事入职后连续提交了一周发现动态里根本没有自己最后排查半天邮箱写错了一个后缀。我自己的体会是Git装好之后配置用户信息是“一次做对终身受益”的事。后面你再建多少仓库都不用重复设置。2. 仓库的创建与日常提交从init到push一条龙2.1 本地仓库初始化与工作目录git init / clone理解了配置接下来就是真正使用Git。最常见的操作有两个场景一是自己从零开始一个项目二是在远程平台比如Gitee已有仓库需要拷下来。自己新建项目时进入项目文件夹执行git init这会在当前目录下生成一个隐藏的.git目录代表仓库已初始化。如果你用IDE也可以借助界面右键初始化效果一样。装好Git之后在文件夹里右键选“Git Bash Here”是比较顺手的操作尤其在Windows上能在指定目录打开命令行省去先用cd切换路径的麻烦。另一种常见方式是从远程克隆git clone 远程仓库地址克隆下来的项目自带.git目录并且会自动配置好远程地址省去手动添加远端的步骤。我第一次用Git时就是靠git clone入门的因为克隆一个现成项目比从零初始化更容易看到效果。这里有个基础概念要理解一个仓库里一般分几个区域——工作区你看到的文件、暂存区临时存放你改动的地方、本地仓库已经提交的历史。刚git init之后所有文件都还在工作区没有被追踪。2.2 提交三部曲add、commit、push含status、log一个完整的提交流程是“改代码、暂存、提交、推送”。在仓库里改动文件后用git status查看状态这一步我已经习惯每次操作前先跑一遍它能告诉你哪些文件被修改过。然后要把改动从工作区加入暂存区git add .git add .是添加当前目录的所有改动后面也可以加具体文件名。我自己更喜欢先git status看清楚有哪些改动再git add避免误添加临时文件或密钥文件。你可以把add理解为“挑菜”把要下锅的菜选出来不是所有东西都往里塞。接着提交到本地仓库git commit -m 提交说明-m后面跟提交信息建议写清楚这次改动做了什么。比如“修复登录页按钮点击无效”就比“updata”好得多。这里要记住一个原则提交信息是给人和未来的自己看的别偷懒。最后推送到远程仓库git push如果你克隆的是HTTPS地址推送时会要求输入托管平台的用户名和密码或私人令牌如果配置了SSH密钥则不需要反复输密码这也就是后面会讲到的Gitee密钥配置。日常还有一个高频命令是git log用来查看提交历史。简单执行会列出最近提交按q退出。如果想要简洁版看每条提交的一行标题可以用git log --oneline新手容易犯的错误是把git add和git commit混在一起觉得“我保存了文件为什么没提交”。其实保存文件是IDE做的事Git不会自动跟踪你的修改必须手动执行add和commit。这种“显式操作”刚开始觉得麻烦后面你会感激它每一步改动都有记录想回退也方便。3. 分支管理并行开发不乱套3.1 分支的创建与切换如果只有一个人开发所有提交都放在master或main上倒也能跑。但稍微正规一点的协作都会用到分支branch。分支可以理解成平行宇宙你可以在一个独立的线路上改动代码不影响主线路稳定后再合并回去。创建并切换到新分支git branch feature/login git checkout feature/login更快捷的写法是git checkout -b feature/login这条命令等于“创建并切换”。Git较新的版本也可以用git switch -c feature/login原理一样。我日常用checkout -b最多因为在旧仓库环境下也兼容。分支的好处是能隔离风险。比如你想试一种新的首页设计在主分支比如main上直接改改到一半发现方向错了要回退牵一发动全身但单独开一个experiment分支想放弃时直接不合并、删掉分支就行主分支完全不受影响。等实验成功再把分支合并回主分支。查看当前分支和所有分支git branch git branch -a分支列表里当前分支前面会带个*号。这里有个小技巧切换分支前建议先确认工作区是干净的可以用git status检查。如果当前有未提交的改动切换分支时这些改动会跟着你“跑”到目标分支可能导致混乱。所以我的习惯是“先提交再切分支”。3.2 合并分支与冲突处理开发完后要把分支的成果并回主干。首先切换到目标分支比如你要把feature/login合并到maingit checkout main git merge feature/login如果两边改动互不干扰合并会自动完成。但一旦同一文件同一行被两个人改动Git不知道听谁的就会报冲突。冲突出现时冲突文件里会出现类似这样的标记 HEAD 这里是当前分支的内容 这里是被合并分支的内容 feature/login你要手动选择保留哪一部分或把两者都整理一下删除这些标记保存文件然后继续提交git add 冲突文件 git commit -m 合并登录分支解决冲突我第一次遇到冲突时很慌觉得代码坏了。其实冲突不是错误而是Git在请你做决策。处理冲突的核心是理清楚两边各自改了什么再结合上下文决定最终内容的取舍。不要盲目删除别人的代码如果项目复杂建议先和冲突另一端的人沟通一下。合并后如果这个分支的任务已经完成可以删掉它保持仓库整洁git branch -d feature/login-d只删除已经合并过的分支如果没合并会提示你提醒你确认是否真的要删除。4. 撤销与修改reset、revert与amend的正确用法4.1 git commit --amend怎么用改信息、补提交git commit --amend是我经常“救急”的命令。它最典型的用途是修改上一次提交的信息。场景是这样的我刚提交完代码突然发现提交说明写错了或者漏掉了一个文件。如果这是本地仓库还没有推送一切都来得及。执行git commit --amend -m 修正后的提交说明这个命令会把本轮提交“覆盖”成新提交旧提交就被替换掉了。也可以不用-m直接执行git commit --amend这会打开默认编辑器可能是vim让你修改信息。有人在这儿卡住不知道怎么保存退出按i进入编辑改完按Esc输入:wq回车。不想用vim的话可以在之前的命令里直接带-m一步到位。另外--amend还能用来补提交漏掉的文件。比如你刚才提交时忘了加一个配置你先git add漏掉的文件再执行git commit --amend --no-edit--no-edit表示不修改提交信息直接把暂存区的改动并入上一次提交。这个技巧在开发时特别实用能保持提交历史干净不出现“fix typo”这种看了就烦的微小提交。但这里有一个非常重要的提醒--amend只能修改“尚未推送”的提交。如果上一次提交已经push到远程你就不要再用amend了因为远程历史已经被别的同事拉取你本地改掉提交哈希后推送到远端会引发冲突甚至需要强制推送非常危险。记住一个口诀本地随手改推送之后别乱动。4.2 撤销提交的两种思路reset与revert除了amend日常更常用到的还有git reset和git revert。这两个命令到底用哪个是很多新手头疼的地方。git reset是把提交历史“回退”它适合在本地仓库还没推送时用。比如我想撤销最近一次提交保留工作区改动git reset --soft HEAD~1soft的意思是保留改动在暂存区你可以重新提交。如果想连暂存也一起撤销用--mixed默认如果想连工作区改动一起丢弃用--hard。这里我要多说一句--hard是危险操作它会丢掉你未提交的改动不能恢复除非你有其他备份。我第一次用git reset --hard HEAD~1时把写了大半天的代码搞丢了之后吸取教训操作前一定先git status并确认有什么要保存。git revert则是“反向提交”它不会删除历史而是新建一个提交把之前某个提交的改动拿掉。好处是历史是完整的适合已经推送到远程、或者多人协作的分支。用法git revert commit号执行后会生成一条新的提交内容是“撤销某次提交的改动”。这种方式不会改写历史所以不会影响其他人。我自己的经验是如果代码还没推到远程想要干净的历史优先用reset如果已经推到远程或不确定别人是否拉取过那就用revert。记住这个判断原则你基本就不太会出大乱子了。5. 连接远端Gitee SSH密钥配置与IDE的神秘命令5.1 Gitee配置密钥SSH Key的生成与添加前面讲过可以用HTTPS地址克隆和推送但每次操作都要输账号密码久而久之很烦。更顺手的做法是配置SSH密钥这样克隆、推送都不需要反复认证。国内用Gitee的挺多就讲讲怎么给Gitee配密钥。先检查一下机器上有没有已经存在的密钥ls -al ~/.ssh如果没有id_rsa或id_ed25519这类文件就生成一个新密钥ssh-keygen -t ed25519 -C 你的邮箱一路回车就行默认会保存在~/.ssh/id_ed25519密码可以不设置设置了每次连接都会要你输入更麻烦。这里-C后面的邮箱通常是你的Gitee注册邮箱。生成后把公钥内容复制出来。Windows下可以用cat ~/.ssh/id_ed25519.pub也可以用记事本打开对应文件复制。然后登录Gitee网页点击头像进入“设置”在左侧找到“SSH公钥”把你复制的公钥内容粘贴到“公钥”输入框标题随便写比如“工作电脑”保存即可。接下来验证配置是否成功ssh -T gitgitee.com第一次连接会有确认提示输入yes回车。如果看到“Youve successfully authenticated”类似信息说明密钥配置成功。从此以后你在Gitee上克隆仓库时选择SSH地址比如gitgitee.com:用户名/仓库.git就能免密操作。配置失败有一个常见原因你在Gitee设置的公钥和你当前电脑的私钥不匹配。比如在公司电脑生成的密钥你拷到家里电脑上尝试免密当然不行。密钥是一对公钥放平台私钥留本机私钥不能乱拷贝。另一个原因是邮箱填得不对生成密钥时的邮箱和平台注册邮箱不一致但不让连接的情况比较少见多数还是公钥没粘贴完整或粘贴时多了空格。5.2 揭秘IDE自动生成的git -c命令以及quotepath等参数现在回头说开头那个命令。很多图形化工具比如某些代码编辑器在执行Git操作时会在控制台里输出类似git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks fetch --progress ...很多人看到这串就慌了其实它就是在普通git命令前面加了一些临时配置参数不影响仓库本身。逐段拆解一下。-c diff.mnemonicprefixfalse-c的作用是临时指定一个配置项只在这次命令里生效。diff.mnemonicprefix控制diff输出里的前缀标识。默认Git会用a/和b/来表示两个对比文件类似a/src/main.js和b/src/main.js设为false就是不要这些前缀输出更简洁。这纯粹是审美偏好。-c core.quotepathfalse这个非常实用。Git默认会对非ASCII文件名做八进制转义显示比如中文名会显示成\346\265\213\350\257\225.txt这种乱码。设成false后中文文件名能正常显示。如果你在仓库里看到乱码文件名手动执行git config --global core.quotepath false就能解决。--no-optional-locks这个参数告诉Git本次操作不要获取可选的索引锁。为什么要这样因为IDE自己可能正在后台不断读取仓库状态如果Git命令还用索引锁容易和IDE的文件更新机制互相干扰。加了--no-optional-locks就少一层锁减少冲突。所以这串命令不仅不是错误反而是IDE在帮你处理显示问题。下次再看到你就可以淡定地忽略它了。如果你手写命令行完全不需要加这些默认行为已经够用。6. 常见问题与避坑指南实战排查实录6.1 最常见的5个git报错场景我接触过不少Git初学者报错场景其实高度重复。挑几个高频的说说我的排查思路。第一个是“fatal: not a git repository”。当前目录不是Git仓库。解决办法是确认你所在目录有没有.git文件夹或者先用git init初始化。有时候是你在仓库的上级目录里执行Git命令Git找不到仓库也会报这个。第二个是“remote origin already exists”。想加远程地址时发现已经配置过了。可以先看远程地址git remote -v然后根据需求修改git remote set-url origin 新地址不要重复git remote add会报错。第三个是“Permission denied (publickey)”。这通常和SSH密钥有关。如果你确认配置过了先执行ssh -T gitgitee.com测试如果不行检查公钥是否正确添加以及当前用户是否用的对了。我遇到过有人把公钥添加到了Gitee的另一个账号当然提示没权限。第四个是“failed to push some refs”。推送被拒绝最常见原因是远程有本地没有的提交。解决办法是先拉取git pull --rebase如果有冲突就解决冲突再重新推送。这里建议优先用pull --rebase而不是pull能让提交历史保持线性好阅读。新手如果不了解区别直接git pull也没问题至少能把远端内容拿下来。第五个是“LF will be replaced by CRLF”。这是换行符警告Windows上很常见。前面提到安装时选默认的换行符处理基本上能减少出现频率。如果团队内有不同系统建议统一配置git config --global core.autocrlf trueWindows下会自动转换换行符保持文件内容的跨平台兼容。这个警告多数时候不影响使用但记得提交前别把无关文件带进来。6.2 我的几条独家操作经验最后分享几个自己摸索出来的习惯。第一养成每次提交前先看git status和git diff的习惯。git diff可以查看还没有暂存的改动能帮你发现自己不小心改动了不想动的文件。省钱省时比提交后才发现问题再回退轻松多了。第二提交信息别写“update”和“fix”这种了无意义的词。写得具体一点比如“修复了移动端导航栏点击区域过小的问题”。下次你翻log时就知道自己干了什么别人 review 时也更清楚上下文。第三遇到不熟悉命令时先查帮助。git 命令 --help会打开官方文档比在网上搜索乱码博客靠谱。不要一开始就记一堆参数随用随查用多了自然记住。第四不要把自己的一次提交写得过大。我刚开始用Git时经常攒了一下午改动一次全提交上去结果出问题时定位很麻烦。现在习惯是每个逻辑相关的小改动单独提交比如“修复登录接口超时”和“调整首页样式”分成两个提交。这样团队其他人看历史清楚你将来回退也能精准找到位置。第五留意IDE帮你执行的命令。很多人只会在图形界面点提交遇到报错完全不知道背后发生了什么。如果你能看到控制台或输出面板里的实际Git命令哪怕看不懂也要试着搜一搜时间久了你的命令行能力会被逼着提升。这不是坏事。关于git commit --amend我再补一个真实案例。有一次我在本地连续提交了三次每次都是“提交信息写错了”的修改最后我把三次提交压缩成一条干净的历史用到的命令是git rebase -i HEAD~3。这个命令可以进入交互式界面把提交改成squash或fixup合并到一起。这个过程很多教程不会仔细讲但你在实际工作中一定会遇到“提交历史太乱想整理”的时刻。建议你把rebase -i当成进阶必学命令它的原理和执行步骤稍长这里先留个引子等你把前面基础命令用顺了再去摸索。我个人在实际使用中的体会是Git的学习曲线并不是从“记命令”开始的而是从“理解仓库、暂存区、提交、分支、远端这些概念”开始的。概念通了命令只是一个查表问题。而这篇文章里提到的安装、配置、提交、分支、修改提交、Gitee密钥配置以及IDE后面的命令解析覆盖了从入门到能独立做小型项目开发的完整链路。把这套东西练熟再去碰cherry-pick、rebase、worktree这些进阶能力就不会发怵了。最后留一句最朴素的建议在你真正敢对一个项目下手之前先自己建一个测试仓库把add、commit、branch、merge、reset都敲一遍推送到Gitee再拉取一次这一套走完你对Git的信任感会完全不同。