1. 为什么第一天就要跟Git死磕1.1 苍穹外卖项目里Git到底在管什么很多同学做苍穹外卖这类项目时第一天习惯性去敲代码结果敲到第三天发现改崩了只能靠IDE的本地历史找回一点是一点或者干脆重新来过。这是最典型的没把Git前置的后果。苍穹外卖是一个标准的前后端分离实战项目涉及用户端、管理端、服务端多个模块日常要改的东西非常多光是菜品管理、分类管理、订单流转这些核心业务代码量动辄几万行起步。如果没有版本控制你根本不知道自己某次改动到底动了哪些文件也说不清某个功能是什么时候变对的。Git在这里干的活简单说就是三件事记录每一次代码变更、支持随时回溯到任意历史版本、给多人协作哪怕是你一个人在不同电脑上写提供安全边界。它不是备份工具不是把整个项目文件夹复制几份改上日期后缀而是基于内容寻址的版本快照系统。每一份提交都保存完整的项目状态哪怕你删了文件、改了配置、推进了错误的分支只要提交记录还在就能恢复。所以我对第一天安排的理解是这样的先花半天把Git的核心逻辑吃透再花几个小时把环境配好、项目拉下来、跑通一次完整的提交推送流程。磨刀不误砍柴工后面写业务代码时你会感谢这个决定。1.2 工作区、暂存区、版本库一次讲明白如果只看Git命令会觉得很碎一会儿add一会儿commit一会儿push记不住也容易搞混。我建议你把Git想成一个带审稿流程的写作场景。工作区就是你电脑上能看到的项目目录你在这里写代码、改配置所有改动都是未记录的草稿状态。暂存区相当于是“待发布的草稿清单”你用git add把想纳入本次提交的文件放进去表示“这几位我确认过了准备提交”。版本库则是Git真正存储所有历史快照的地方git commit会把暂存区的内容固化成一个版本节点这个节点包含完整元信息作者、时间、提交说明、父节点指针以及一棵完整的文件树快照。理解这三者的关系后很多操作就顺了。比如git status看的是工作区和暂存区的差异git diff看的是还没暂存的改动内容git diff --staged看的是已经暂存但还没提交的内容git log看的是版本库里的历史记录。第一天最需要建立的就是这个心智模型而不是急着背参数。注意git commit只固化暂存区内容。很多人改了文件直接 commit结果发现改动没进去就是因为忘记git add。我第一天就在这上面犯过错后来养成了每次提交前先git status的习惯确认要提交的文件都在暂存区里再动手。2. 装好Git并把环境配到顺手2.1 各平台安装Git的要点Git的安装本身不复杂但有几个细节值得说。Windows用户建议直接从官网下载安装包一路Next安装有两个地方需要注意一是安装路径别带中文和空格否则某些终端工具解析会有问题二是建议选择“Use Git from the Windows Command Prompt”而不是默认的“Git Bash only”这样在CMD和PowerShell里也能直接用git命令。笔者实际测试下来Git Bash和PowerShell里混用容易在PATH和脚本执行策略上踩坑统一走CMD或PowerShell更省心。macOS用户优先用homebrew install git或者从官网下载pkg安装包。Homebrew装的是最新稳定版后续更新也方便适合追求版本较新的开发者。Linux用户则根据发行版走apt、yum、dnf这些包管理器CentOS等老版本系统默认源里的Git版本偏低可能不支持部分新语法建议先git --version查一下。装完第一件事在终端里执行git --version能输出版本号说明装好了。严格来说Windows下还有个操作容易被忽略Git会自带一个凭证管理器首次做HTTPS操作时可能会弹窗让你输入账号密码。我建议第一天就把它配好安装时选上“Git Credential Manager”后续推送就不用来回输入账号了。2.2 核心全局配置与SSH密钥配置装好Git后的第一步设置全局身份信息git config --global user.name your-name git config --global user.email your-emailexample.com这两项会写入每次提交的元信息里团队协作时别人才能知道某次改动是谁做的。我见过不少人跳过这一步提交时系统用默认主机名充当作者后续回溯时完全对不上人。另外建议把默认分支名设置成maingit config --global init.defaultBranch main然后是SSH密钥配置。用SSH协议克隆和推送项目相比HTTPS最大的优势是不用每次输入账号密码只要你把公钥加到代码托管平台GitHub/Gitee等即可。生成密钥ssh-keygen -t rsa -b 4096 -C your-emailexample.com一路回车默认生成路径是~/.ssh/id_rsa.pub。然后把公钥内容复制到托管平台的SSH Keys设置里。如何确认配置成功执行ssh -T gitgithub.com看到Hi xxx! Youve successfully authenticated就代表通了。需要注意不同平台的验证域名不一样GitHub是gitgithub.comGitee是gitgitee.com。我在第一天就卡在了SSH认证失败上后面专门用了整节来排查这个问题这里先提个醒公钥一定要带完整后缀复制有些终端复制会截断最后几个字符容易造成误配置。3. 拉取苍穹外卖项目与IDEA里的日常操作3.1 用IDEA从远程仓库拉取项目做苍穹外卖项目多数情况是跟着教学视频操作或者从某个仓库先把代码clone下来再自己迭代。打开IDEA后在欢迎页选择“Get from VCS”弹窗里填远程仓库的SSH地址或HTTPS地址选择本地存放目录点击Clone即可。这里建议优先用SSH地址原因前面说了免密、安全、稳定尤其后续每天多次推送拉取时体验差距非常明显。如果是从零开始创建自己的苍穹外卖项目并推到远程流程就是反过来的先在本地创建一个Spring Initializr项目写几行基础代码后用git init初始化为仓库关联远程地址后推送git remote add origin gitgithub.com:your-name/cangqiong-waimai.git git branch -M main git push -u origin main-u参数会把本地main分支和远程main分支建立追踪关系后续执行git push和git pull就不需要再带参数了。第一天容易犯的错是IDEA里新建项目后没有初始化Git结果写到一半想提交才发现目录不是仓库。IDEA其实会在新建项目时询问是否初始化注意别跳过。3.2 每天的高频提交与推送流程项目进入正轨后我每天的工作流基本是这样的到达开发机先git pull拉取最新代码上午写一个功能模块后在IDEA里Review一下改动确认没问题就提交推送一次下午继续写代码收工前再提交一次推送。这样远程仓库始终保持有当天的成果即使本地电脑出问题代码也不会丢。具体到操作层面IDEA的Git集成做得已经相当顺手。修改文件会变色右键可以选择提交自动帮你区分新增、删除和修改。提交时最好写清楚的提交信息我个人的规矩是动词开头、说清楚做了什么feat: 完成菜品分页查询功能 fix: 修复订单状态更新后缓存未刷新问题 docs: 补充README中环境变量说明像“11111”、“asdf”这种提交信息等到回滚定位时就是灾难。搞不清某个功能在哪次提交引入的只能一条条翻历史。注意提交前一定看一眼.gitignore是否生效。苍穹外卖项目的target/、.idea/等目录如果被提交进仓库会拖慢clone速度还会把本机特定配置传给队友导致环境不一致。检查命令是git status看到里面出现target目录就赶紧补进.gitignore。我在第一天踩了这个坑删掉误提交文件还要额外清理远程记录相当麻烦。4. 分支管理一个人也要玩转分支4.1 第一天就要定好的分支策略很多刚接触Git的人觉得“我就一个人开发用不着分支吧”。实际做苍穹外卖这样的项目分支策略是非常值得投入时间去规划的。最稳妥的方案是参考业界常用的模式main分支始终保证是可运行的稳定版本feature分支承载具体功能开发。比如我要做“新增菜品”这个功能就先从main拉出一个分支git checkout -b feature/add-dish在这个分支上专心写代码哪怕写到一半思路崩了、代码改得面目全非也不会影响主分支的稳定性。等测试通过后再把分支合并回maingit checkout main git pull git merge feature/add-dish git push这套流程看起来多敲了几个命令但好处非常明显main分支随时可以打包部署不会因为某个功能开发到一半把整个项目的可用状态搞坏。我做苍穹外卖的管理端模块时就靠这个策略保住了底有一次订单统计功能写到一半发现思路有问题直接在feature分支上回滚重来主分支完全没受影响。4.2 合并冲突第一次遇到别慌分支合并时最常遇到的拦路虎就是冲突。所谓冲突本质是两个分支修改了同一个文件的同一段代码Git不知道该听谁的只能请你来做裁决。比如A分支改了菜品表结构B分支也改了同一块SQL映射合并时就会提示CONFLICT (content): Merge conflict in src/main/resources/mapper/DishMapper.xml出现冲突后不要慌。IDEA里会弹出冲突解决窗口左右分栏展示两个分支各自的版本中间是合并结果区。你需要做的是逐段选择保留哪边或者干脆两边都保留再手动调整。处理完所有冲突后右键标记为“已解决”然后提交即可。我处理冲突的经验是先看业务含义再动手不要机械地选“Accept Yours”或“Accept Theirs”。比如配置文件通常以线上环境叫准功能代码则要结合双方改动的意图来判断。第一次处理冲突慢是正常的但多经历几次就会发现冲突大部分都是因为同时改了同一块地方解决起来也就十几分钟的事。提示合并之前务必先git pull把远程最新代码拉回来在本地把冲突解决掉再推送。强迫自己每次合并前先同步可以避免很多无谓的分支分叉和重复解决冲突。5. 第一天最容易踩的坑SSH失败、乱码与回滚5.1 SSH认证失败从头排查SSH认证失败是第一天出现频率最高的问题。报错通常是gitgithub.com: Permission denied (publickey).这说明服务器拒绝了你的公钥。排查路径按顺序来第一确认当前用户家目录下的.ssh文件夹存在且包含id_rsa和id_rsa.pub第二确认公钥是否完整添加到托管平台第三确认你用的是SSH地址而不是HTTPS地址第四检查是否存在多个密钥导致Git选错了key。很多人卡在第四点上。系统里如果有多个密钥Git默认会尝试~/.ssh/id_rsa如果你把项目对应的密钥存在了别的文件里认证就会失败。解决办法是给这个仓库单独指定keygit config core.sshCommand ssh -i ~/.ssh/company_ed25519 -F /dev/null或者更优雅的方式在~/.ssh/config里给不同域名配置不同密钥。我用过最省心的一招是直接用ssh -T gitgithub.com先做基础连通测试这一条命令能告诉你到底是网络问题、key问题还是权限问题节省大量盲猜时间。5.2 提交信息乱码与换行符问题Windows环境下第一天很容易遇到提交记录中文乱码原因通常是Git默认的核心编码配置和IDEA不一致。表现为终端里git log看到的提交说明全是\xxx\xxx这种转义序列或者IDEA提交面板里中文正常、终端里全乱。解决办法很简单git config --global core.quotepath false git config --global gui.encoding utf-8 git config --global i18n.commit.encoding utf-8 git config --global i18n.logoutputencoding utf-8另外Windows上的换行符问题也相当折磨人。Windows环境默认行尾是CRLFLinux和macOS是LFGit的自动换行转换逻辑不熟悉的话会出现“我什么都没改但是git status显示整个文件都变了”的怪现象。我的建议是Windows用户显式配置git config --global core.autocrlf true让Git在提交时自动把CRLF转成LFcheckout时再转回CRLF。这样既能保证仓库内部统一用LF又不影响Windows本地编辑。团队协作时再配一份.gitattributes文件明确强制规则就能从根上避免这类分歧。5.3 Git误操作回滚与踩坑心得第一天的学习里还有个重要的安全网知识改错了怎么办。最常用的几个命令先记住git status随时查看工作区状态判断哪些文件改了、哪些文件暂存了git log --oneline查看简洁提交历史定位要回退的版本git checkout — file丢弃工作区某个文件的改动回到最近一次提交状态git reset --soft HEAD~1撤销最近一次提交保留改动内容在暂存区相当于后悔药git reset --hard HEAD~1彻底回退并丢弃改动谨慎使用。另外强烈推荐了解一下git stash。有时候写到一半需要临时切换到别的分支去改个紧急bug但当前代码还没到提交的阶段这时git stash会把所有未提交改动暂时保存起来等处理完再git stash pop恢复。第一天学会这个后续开发能省掉很多不必要的commit。我做苍穹外卖第一天就在这上面吃过亏写用户登录功能时改了一半临时要看订单模块的代码直接git checkout切分支结果改动的代码全丢了。后来才反应过来切换分支前先确认工作区是否干净不干净就用stash保护起来。这个习惯我现在一直在用已经成了肌肉记忆。最后分享一个小技巧在做苍穹外卖的过程中我每天结束前都会执行三个命令git status git add . git commit -m day-xx: 项目进展 git push不要小看这一步日积月累下来你的提交历史本身就是一份完整的项目开发日记。哪天项目出了问题需要排查顺着提交记录一步步回看比对着视频重新敲一遍效率高太多了。另外还有一点建议第一天就把Git的别名配置上比如git log美化输出。git config --global alias.lg log --oneline --graph --decorate --all git config --global alias.st status -sb这些别名不会改变Git的功能但能大幅提升日常操作的顺滑度尤其看分支图和提交记录时一眼扫过去比默认输出清晰得多。把工具磨顺手后面的项目之路自然会顺不少。