1. 环境准备与全局配置先把地基打牢Git这个东西刚接触的人总觉得命令多、概念绕实际上真正天天用的就那么几条。我在带新人或者帮同事排查问题的时候发现九成的手忙脚乱都不是因为Git本身难而是一开始的配置就没弄对后面每一步都在还债。所以这篇文章我不想按文档顺序罗列命令而是按照一个真实项目从零到一的推进节奏把用户名配置、下载代码、提交修改、切换分支、配置密钥这些高频操作串起来讲顺便把我这些年踩过的坑也一并交代清楚。先说第一个问题Git装好之后第一件事不是急着clone代码而是告诉Git“你是谁”。这个身份信息会写进每一次提交记录里别人在代码评审、追溯历史的时候看到的就是这个名字和邮箱。如果这一步随便糊弄后面会出现两种尴尬一是提交记录里显示一堆Unidentified或乱码名字二是同一个人的提交因为邮箱不一致被算成好几个人团队统计贡献和回溯bug时非常头疼。配置分两级全局配置global和仓库级配置local。全局配置作用于当前电脑上的所有仓库适合设置个人默认身份仓库级配置只对当前仓库生效适合公司项目里临时覆盖个人身份的情况。# 全局配置 git config --global user.name 你的名字 git config --global user.email youexample.com # 仓库级配置在仓库目录内执行 git config --local user.name 项目专用名字 git config --local user.email projectexample.com配置完之后一定要验证一下很多人配完就忘等到push上去才发现身份错了。验证命令git config --global --list git config --local --list这里有个细节容易被忽略邮箱不一定要用真实邮箱但必须是一个能收到邮件的地址。因为Git托管平台的通知、代码评审提醒、找回密码都靠这个邮箱如果你随手敲了个不存在的地址遇到账号异常时连找回的入口都没有。还有一个更隐蔽的问题如果你在公司电脑上配了个人邮箱提交到公司仓库后个人邮箱会暴露在内部系统里。我见过有团队强制要求公司项目必须使用公司邮箱通过pre-commit钩子或者服务端规则拦截个人邮箱提交。所以我的习惯是工作电脑全局配置用个人常用账号涉及公司仓库时再用--local覆盖成公司邮箱互不污染。Windows用户还要多做一步换行符检查。因为Windows和Linux/macOS对换行的处理方式不一样Git默认的autocrlf设置如果不对会出现整个文件都被标记为修改的诡异现象。建议执行git config --global core.autocrlf true # Windows 用户 git config --global core.autocrlf input # macOS/Linux 用户这个设置的意义在于提交到仓库时统一转换成LFUnix换行检出到本地时Windows再转回CRLF。不设置的话你在Windows上改了一行代码Git会认为整个文件都变了因为换行符全被改了一遍代码评审时差异列表能把你逼疯。这是我刚参加工作时踩过的坑当时发出去的变更请求里有几百行diff其实只动了三行代码被导师拎出来当反面教材说了很久。2. 配置SSH密钥不用每次输密码的通行证身份配好了接下来要解决的就是“怎么安全地把代码拉下来”。Git托管平台支持的协议主要就两种HTTPS和SSH。HTTPS简单直接但每次push都要输账号密码或被要求输入访问令牌有的平台还需要在网页端勾选一堆权限才能生成令牌用起来很繁琐。SSH密钥的本质是一对加密钥匙私钥留在你电脑上公钥放到Git托管平台后台配对成功之后就能免密操作。关于密钥的生成方式这里我要专门提一句现在网上一搜全是ssh-keygen -t rsa但如果你用的是Git Bash或者新版Windows Terminal直接用Ed25519算法更稳。RSA默认是2048位安全性没问题但Ed25519的密钥更短、生成更快、安全强度也更高而且新版OpenSSH对它的支持已经非常成熟。我用Ed25519生成了几百个密钥从没遇到过兼容性问题。# 生成Ed25519密钥推荐 ssh-keygen -t ed25519 -C youexample.com -f ~/.ssh/id_ed25519 # 生成RSA密钥老系统兼容 ssh-keygen -t rsa -b 4096 -C youexample.com -f ~/.ssh/id_rsa执行过程中会提示你设置passphrase也就是密钥口令。这里大多数人会直接回车跳过图省事。我个人的建议是本地个人电脑可以跳公司电脑强烈建议设置。因为公司电脑存在被其他人使用的可能一旦私钥泄露对方拿着你的私钥就能随意访问你有权限的所有仓库。设置了口令之后即使私钥文件被拷走对方没有口令也白搭。生成完成后公钥文件是id_ed25519.pub私钥是id_ed25519。注意公钥可以到处发私钥连同事都不要给更不要提交到代码仓库里。这个提醒不是开玩笑GitHub上有个著名的爬虫项目专门扫描公开仓库里的私钥文件只要发现BEGIN OPENSSH PRIVATE KEY开头的字符串就自动收集检测到之后平台方一般会直接发邮件警告你。接下来把公钥内容添加到Git托管平台。不管是哪家平台操作路径大同小异进入个人设置Settings找到SSH Keys或者SSH and GPG Keys这个入口把id_ed25519.pub里的整段内容粘贴进去起个名字方便识别是哪台电脑保存即可。添加完密钥之后用这条命令验证连接是否正常ssh -T gitgithub.com不同平台返回的欢迎语不一样有的会显示Hi username! Youve successfully authenticated有的会提示Welcome之类的信息。看到欢迎语就说明密钥配置成功了而第一次执行时如果弹出一个确认指纹的提示输入yes即可。这里有个坑我要特意说一下如果你电脑上配置了多个SSH密钥比如一个用于个人GitHub一个用于公司GitLab直接执行ssh -T gitgithub.com可能会报错Permission denied (publickey)。原因是SSH默认只会去找~/.ssh/id_rsa或id_ed25519找不到就放弃不会自动尝试其他密钥文件。解决办法是编辑~/.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_work配置好之后SSH会根据你连接的域名自动选择合适的私钥彻底告别指定密钥的烦恼。3. 克隆代码与日常提交打通“拉-改-推”的闭环密钥配好了终于到了正式操作环节。把远程仓库的代码下载到本地标准动作就是clonegit clone gitgithub.com:username/repository.git # 或者指定目录名 git clone gitgithub.com:username/repository.git my-project这个命令背后的逻辑是除了把默认分支通常是main或master的代码拉下来还会自动建立一个origin远程连接指向原仓库地址。以后你执行git pull、git push、git fetchGit都知道该跟谁通信不需要你再手动添加远程地址。clone完成之后我强烈建议你先建一个自己专属的分支再动手改代码。原因很简单直接在主分支上修改万一改到一半发现思路不对想回退会污染主分支的历史记录如果多人协作别人pull下来还可能跟你改到同一个文件产生冲突。而新建一个分支改坏了就删掉重来主分支永远干干净净。创建并切换到新分支git checkout -b feature/login-page这个命令是两条命令的合并写法等价于git branch feature/login-page git checkout feature/login-pagecheckout -b带来的分支是本地分支只存在于你电脑上远程仓库里暂时没有。后面你执行push提交时加上-u参数就能在推送的同时建立本地分支和远程分支的追踪关系git push -u origin feature/login-page-u全称是--set-upstream它做的事是告诉Git这个本地分支的默认上游要推送的目标是远程的feature/login-page。设置过一次之后后续再执行git push或git pull就不用带远程仓库名和分支名了直接裸敲命令就行。我见过不少人每次push都要把git push origin xxx完整打一遍其实就是当初少加了一个-u。接下来是日常开发里最核心的三连改文件、暂存、提交。# 查看工作区状态 git status # 查看具体改了什么内容 git diff # 暂存所有改动新增/修改/删除 git add . # 提交并写备注 git commit -m feat: 实现登录页面表单校验git add也分几个层次。git add .会把当前目录下所有变更都加入暂存区适合改动不复杂的场景git add src/可以只暂存某个目录git add src/App.js只暂存单个文件git add -p则进入交互模式逐个hunk地确认要不要暂存。交互模式在你想把一个文件的改动拆成多个提交时非常好用比如一个文件里既有格式调整又有新功能用git add -p就能把这两部分分开提交历史记录会清晰得多。提交信息这块值得多说两句。我见过太多update、fix、aa这种备注过两周回头看根本不知道当时做了什么。好的提交信息最好遵循统一的格式社区通用的写法是feat: 新功能fix: 修复bugdocs: 文档变更style: 格式调整不影响代码运行refactor: 重构不是新功能也不是修bugtest: 添加或修改测试chore: 构建或辅助工具变动比如feat: 增加用户头像上传接口、fix: 修复登录超时后跳转错误。这种结构化的提交信息除了让人看得懂还能配合发布工具自动生成changelog算是一劳永逸的投资。提交流程走完之后把本地提交推送到远程git push如果推送时提示remote contains work that you do not have locally说明远程仓库有别人先推了代码Git出于安全考虑拒绝你的推送避免覆盖别人的提交。这时候的处理顺序应该是先pull再pushgit pull origin main git pushgit pull实际上是两条命令的合并git fetch把远程的更新拉下来但不合并加git merge将拉下来的更新合并到当前分支。如果你的代码和别人的改动互不冲突会自动完成合并如果改了同一个文件的同一块区域就会产生冲突Git会把冲突标记打到文件里让你手工解决。这个过程后面专门讲。这里我还想提一个很多新手不知道的好习惯不要在主分支上直接提交代码。不管是你自己的个人项目还是团队协作主分支都应该保持“随时可部署”的稳定状态。我的常规做法是新建功能分支开发开发完成后切回主分支执行git pull把最新代码拉下来再合并自己的分支。如果合并过程中有冲突就在本地解决掉再推上去。这样主分支的历史永远是干净的不会出现一堆“临时提交”“改一下”“又改一下”的垃圾记录。4. 分支管理与合并策略多人协作不打架的关键分支是Git里最值得花时间理解的概念。网上有个比喻很形象分支就像平行宇宙你可以在自己的宇宙里随便改动改砸了也不影响主宇宙。这个理解方向是对的但实际使用中还有几个容易混淆的操作点需要厘清不然切换分支的时候哭都来不及。先看最基础的三个动作# 查看所有本地分支 git branch # 查看所有远程分支 git branch -r # 查看所有本地远程分支 git branch -a # 切换到已有分支 git checkout main # 或者新版写法 git switch maincheckout和switch在功能上高度重叠新版本Git推荐用switch做分支切换语义更清晰不容易跟git checkout丢弃工作区改动的功能混淆。对于老司机来说用什么无所谓新手我建议直接用switch系列命令git switch -c创建并切换git switch切换。未提交的改动会被带到切换后的分支去这是个特别容易翻车的点。比如你在feature-A分支改了一个文件还没commit直接切到main分支这个未提交的改动会跟着你跑到main分支上。如果两边分支的内容存在差异Git有时候会切不过去提示你Your local changes would be overwritten。这时候有两个选择一是把改动提交到当前分支再切换git add . git stash push -m 临时保存未完成的改动二是用git stash把改动暂存起来git stash push -m 登录页面布局调整中 git checkout main # 等切回来之后恢复 git stash popstash就像一个临时储物柜把你手头没干完的活先锁起来等切回来再取出来接着干。弹出的命令是git stash pop它会恢复最近一次暂存的改动git stash list可以查看当前暂存了几个记录git stash apply stash{1}可以恢复指定的一条记录。我自己处理临时切换需求时基本都用stash比自己复制文件到外面再粘贴回来安全太多了。复制粘贴的方式容易遗漏修改过的文件比如你改了三个文件但只记得复制了两个回到原分支后发现丢掉的那个改动再也找不回来。分支合并常用的两招merge和rebase。它们的差别在于历史记录的形状。# merge把另一个分支的改动合并进来保留完整的历史分岔 git merge feature/login-page # rebase把你的提交按到目标分支的最新提交之后历史变成一条直线 git rebase mainmerge的特点是“真实记录发生过什么”缺点是比较提交历史时会有分岔看起来不是线性的。rebase的特点是整洁像你直接在最新版代码上从零开发一样但代价是它会重写提交的哈希值如果你已经把分支推到了远程并且有别人在基于你的分支开发这时候rebase会把别人搞得很难受。我个人的习惯是自己开发的功能分支在合回主分支前可以考虑用rebase把时间线拉直已经推上远程的共享分支绝对不用rebase。这个原则能避免绝大多数历史混乱的问题。再来说冲突。冲突的本质是两个人改了同一个地方的代码Git不知道该听谁的。冲突文件的标记长这样 HEAD 你当前分支的内容 对方分支的内容 feature/login-page解决方式就是打开文件把不需要的部分删掉保留最终想要的代码然后删掉、、这几行标记保存文件再执行git add和git commit。整个过程不复杂但需要你了解两边的代码逻辑胡乱合并的后果往往是一堆隐藏的语法错误或行为异常。有一个非常实用的避坑方法在每次merge之前先把目标分支的最新代码拉下来。比如你要把feature/login-page合入main先切到main执行git pull再切回feature/login-page执行git merge main把主分支的更新提前合并进自己的分支。这样真正要把功能分支合入主分支时冲突已经在你自己的分支上解决过了主分支的merge操作会非常干净。这个习惯我保持了几年团队里出问题的次数屈指可数。5. 远程仓库协作团队开发必须掌握的同步技巧单人开发时clone、push、pull就够用了但一旦进入团队协作你还会遇到更多跟远程仓库相关的操作。这节我把几个高频场景逐个说清楚配合具体命令和排查思路。第一个是频繁pull导致本地落后太多的情况。假设你的本地分支已经落后远程分支好几个commit同时你本地也有未推送的提交这时候需要小心处理的工作流一般是git fetch origin git rebase origin/main用fetch把远程更新拉到本地暂存区用rebase把自己的提交变基到新的远程提交之后。这样做可以避免产生一个“合并提交”历史看起来更清晰。如果双方的改动没有冲突rebase是静默完成的你甚至感受不到变化。如果产生冲突Git会停下来让你逐个解决解决完执行git rebase --continue继续想放弃就执行git rebase --abort回到rebase之前的状态。fetch和pull的区别值得强调一下。fetch只负责把远程的更新拉到本地但不会自动合并到你的工作区你的代码还是原来的样子pull等于fetch merge拉下来之后立即尝试合并。所以当你不想立刻合并、只想看看远程有什么变化时用fetch更安全。看完之后对比一下差异git fetch origin git log --oneline HEAD..origin/main这条log命令显示的是origin/main上有、但你本地HEAD没有的提交。确认不影响自己之后再决定要不要合并。这套流程在多人同时开发同一个功能分支时格外实用能让你在merge之前就心里有数。第二个高频场景是误操作或推送了不该推送的内容。比如不小心把包含密码的配置文件提交并推送到了远程仓库。很多人第一反应是执行git reset退回之前的提交然后强制推送覆盖远程。这里要分两种情况如果你是在推送到远程之前就发现了处理很简单git reset --soft HEAD~1--soft保留工作区和暂存区的内容只把HEAD指向上一个提交相当于撤销了这次commit但保留所有改动你可以重新组织后再次提交。如果想要同时撤销暂存区但保留工作区用git reset HEAD~1默认mixed模式。如果连工作区的改动都不要了用git reset --hard HEAD~1这条路不能反悔执行前务必确保改动可舍弃。如果已经推送到了远程单纯git reset只在本地生效远程还是旧状态。需要强制推送覆盖git push --force-with-lease origin feature/login-page注意我用的是--force-with-lease而不是裸--force。--force-with-lease会在推送前检查远程分支是否还是你上次fetch时的状态如果这期间别人推了新代码推送会被拒绝避免你覆盖掉同事的提交。裸--force是无条件覆盖危险系数高得多。我在生产环境分支上从来不用裸--force。第三个场景是删除分支。分支合并完成后本地分支可以删掉命令很简短git branch -d feature/login-page如果分支里有未合并的提交-d会拒绝删除需要改用git branch -D feature/login-page强制删除。删除远程分支用git push origin --delete feature/login-page远程分支删了之后本地还会保留一个可以查看的引用origin/feature/login-page但如果别人在你删除远程分支之后执行了git fetch --prune这个引用也会被清理掉。平时我清理分支的习惯是每完成一个功能的合并顺手删除本地和远程对应的分支保持仓库清爽。6. 高频问题排查这些错误信息我全遇到并解决过最后把平时被问得最多、我自己也反复踩过的问题集中梳理一遍做成一个速查表每条附上解决方案和背后的原理。收藏这个列表基本可以应对日常开发中九成以上的Git报错。报错/问题出现原因解决方案fatal: Not a git repository当前目录不是一个Git仓库确认是否进入了正确的项目目录执行git init初始化或cd到已有仓库Permission denied (publickey)SSH密钥未配置或未被识别检查~/.ssh下是否有密钥、公钥是否添加到平台、~/.ssh/config是否配置正确fatal: remote origin already exists当前仓库已经关联了一个远程地址用git remote set-url origin 新地址修改或git remote remove origin删除error: failed to push some refs远程有本地没有的提交推送被拒先git pull再git push或者git fetch后对比差异再处理Merge conflict in xxx双方修改了同一个文件的同一区域打开冲突文件删除冲突标记保留最终代码git addgit commitfatal: refusing to merge unrelated histories两个仓库没有共同的提交历史比如远程是新建的本地是另一个版本如果确认要合并执行git pull origin main --allow-unrelated-historiesLF will be replaced by CRLF换行符自动转换提示确认core.autocrlf设置是否符合你的操作系统这些报错里最典型的还是Permission denied (publickey)出现频率极高。排查思路按照下面三步走# 第一步确认本地有没有密钥文件 ls -la ~/.ssh/ # 第二步确认ssh-agent里有没有加进私钥macOS/Windows都有这个服务 eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519 # 第三步测试连接 ssh -T gitgithub.com如果这三步都正常但还是报错优先检查~/.ssh/config里的IdentityFile路径是不是配错了或者公钥粘贴到平台时多了空格、换行。我还遇到过一种很隐蔽的情况Windows系统下~/.ssh目录的权限设置不正确SSH直接拒绝读取私钥文件。解决方法是右键这个文件夹 - 属性 - 安全给当前用户赋予完全控制权限再重试就能通过。另一个让很多人困惑的问题是**git pull和git fetch之后代码“没变”**。其实不是没变而是fetch不会自动合并。如果你执行的是git fetch发现远程有更新但本地代码没变化这是正常现象再执行git merge origin/main或者直接git pull origin main才会真正合并到工作区。这就像你去快递柜取件fetch是收到取件码通知merge才是打开柜子拿到包裹。有些时候你还会遇到提交信息写错了的情况比如git commit -m feat: 修复登录结果发现这是个bug修复不是新功能想改一下提交说明。如果提交还没推送直接用git commit --amend -m fix: 修复登录超时问题这条命令会替换掉最近一条提交的信息但提交的内容不变。如果已经推送了还是能用--amend改但之后需要强制推送而且必须遵守一个前提这个分支只有你自己在用没有别人基于它开发。有同事在用的分支不要amend不要rebase不要强制推送这三个操作都会让别人的历史记录跟你出现分歧最终只能手工协调费力不讨好。再补充一个几乎每个开发者都绕不开的场景临时切换分支时潜在未提交的代码怎么办。我前面提到过git stash这里把完整流程再走一遍因为这是高频中的高频# 保存当前所有未提交的改动 git stash push -m 购物车样式调整中 # 查看stash列表 git stash list # 切到别的分支干活 git checkout main # 干完活切回来 git checkout feature/shopping-cart # 恢复之前暂存的改动 git stash popgit stash pop和git stash apply的区别在于pop会从stash列表中移除该条记录并应用变更apply会保留记录只应用变更。如果你恢复之后发现改动有冲突pop会停止并保留stash记录你可以解决完冲突再用git stash drop手动删除这条记录。反正我在恢复应用完之后都会顺手看一眼git status确认要恢复的改动都在。7. 日常使用中的几个建议最后写几条我自己摸索出来的使用习惯。这些不是功能讲解而是实际工作中沉淀下来的操作偏好分享出来仅供参考。第一条提交之前先看diff。很多人是改完直接git add .加git commit -m xxx一条龙从来不检查自己到底改了哪些东西。结果经常把调试代码、临时打印、甚至无用文件一起提交上去。我现在养成的固定动作是git add之后、git commit之前看一眼git diff --cached确认暂存区里的每个改动都是自己想要的。这个习惯能过滤掉至少七成的误提交。第二条每次登录新电脑先配置ssh key再接仓库。我在换电脑时遇到过太多次“明明之前的电脑都好好的”这样的困惑其实就是新电脑没有生成密钥。按照文章前面的流程走一遍十分钟内能全部搞定。第三条给提交信息留个规范模板。我见过有的团队用模板引擎来约束提交格式但更多人是靠自觉。如果你管不住自己可以给Git配置一个提交模板文件每次执行git commit时自动加载模板内容git config --global commit.template ~/.git-commit-template.txt模板文件里写好格式说明和示例提交时会自动打开编辑器输入完成保存退出即可。这个办法对团队统一风格非常有效比管理文化管用得多。第四条定期git fetch --prune清理远端分支引用。团队协作一段时间后本地会积累一堆别人已经删除的远程分支引用git branch -a看起来乱七八糟。执行git fetch --prune这条命令会把本地记录的、但远程已经不存在了的分支引用清理掉。实测下来每隔一两周跑一次仓库会清爽很多。第五条也是我反复想在文章里强调的Git只是一个工具它的核心价值不是让你炫技而是让你的代码历史清晰可追踪、让团队协作不失控。很多人学了十几个高级命令就以为自己精通Git了但真正到了生产环境零失误地处理好每一次提交、每一次合并比背下来多少命令参数重要得多。如果这篇文章能帮你少走几步弯路那这些内容就没有白写。Git的文档永远是全面但不亲和的真正让知识落地的永远是实操、踩坑、再实操的循环。