刚进公司那阵子我因为Git的操作问题被导师和同事“教育”了好几回。不是代码写得烂也不是业务理解差而是分支切错了、提交信息写得看不懂、或者干脆把一个带着一堆无关改动的MR丢给了评审人。后来自己也开始review别人的代码才彻底明白在企业里用Git真正考验人的不是命令背得有多熟而是你有没有一套让别人舒服、也让历史清晰的流程习惯。这篇东西我想写给刚入行、或者刚换到一家对代码规范比较较真的公司的朋友也适合那些团队里Git用得很“野”、想慢慢立规矩的组长或者核心开发。我会按一个完整的企业级交付流程来讲——从环境配置、分支模型到日常提交、代码评审再到线上事故怎么回滚、怎么避免把整个仓库搞乱。基本覆盖你在公司里会被骂的所有高危场景。看完不说从此封神至少能在下次提交代码之前多想一想少踩几个坑。1. 环境配置把“你是谁”和对齐工具先搞定1.1 提交身份user.name 和 user.email 别乱填很多人在自己电脑上装完Git就直接开用user.name填个网名user.email填个私人邮箱。这件事拿到企业里就是隐患。因为Git里每一次提交都会记录author信息代码评审系统、CI/CD平台、代码搜索工具全都会拿这个字段来定位“这段代码是谁写的”。如果你把邮箱配成了自己某年注册的QQ邮箱或者一个搞笑昵称轻则别人在代码历史里根本认不出你重则出了问题复盘时责任落不到人头上最后大家只能互相猜。我建议到了新公司第一天第一件事就是问清楚公司要求的提交邮箱格式然后执行git config --global user.name 你的中文或拼音全名 git config --global user.email 你的公司邮箱company.com注意这个配置存放在全局的~/.gitconfig里它影响你本机所有仓库。如果你想在某些个人项目里用另一个身份可以单独在那个仓库目录下用git config --local覆盖。但在公司项目里请始终用公司身份别嫌麻烦。另外一个很现实的点如果你在提交之后才发现邮箱配错了就算改回去历史里已经写错的提交也不会自动更正。企业里一般不让随便filter-branch或者rebase改历史因为一旦推送过后面的同事已经基于这些提交干活了。所以配错邮箱这事唯一的解法就是一开始就配对。1.2 换行符与文本编码被忽略却最容易制造海量diff这一条我提出来是因为它太容易挨骂了你明明只改了一行代码push上去以后整个文件几百行都被标成改动。评审人打开MR一看满屏红色第一反应就是给你打回。问题多半出在换行符上。Windows默认用CRLF换行Linux和macOS用LF。如果你的仓库没有一个统一的换行符约定Git在对比的时候就会认为整个文件都变了。一般的处理方式是在Windows上配置git config --global core.autocrlf true这个配置会在你checkout时把LF转成CRLF在你commit时把CRLF转回LF保证仓库里存的始终是LF。macOS和Linux的同学可以设core.autocrlf input。不过最可靠的还是直接在仓库根目录放一个统一的.gitattributes文件* textauto *.sh text eollf *.bat text eolcrlf.gitattributes是跟仓库走的团队每个成员都会自动使用同一套规则比你挨个通知大家改global配置靠谱得多。这种文件应该在新仓库初始化时由负责人加上如果你们仓库还没有建议尽快补一个你没准能拯救一批被换行符折磨的同事。编码问题同理企业项目里统一UTF-8基本是底线。如果你在Windows记事本里编辑过文件保存成带BOM的UTF-8个别构建工具和脚本可能直接崩那种问题排查起来特别费劲。1.3 SSH Key与Clone方式别总让CI和同事等你的密码企业里Clone代码一般两种方式HTTPS或者SSH。HTTPS虽然在浏览器里输密码很方便但企业普遍开了两步验证或者SSO经常隔一阵就要求重新认证很烦。SSH是一次配置长期使用更推荐。配置SSH的连接链路大概是本地生成密钥对把公钥贴到GitLab/GitHub企业版/Gitee的后台然后本地测试通不通。ssh-keygen -t ed25519 -C youcompany.com ssh-add ~/.ssh/id_ed25519 ssh -T gitgitlab.com如果ssh -T返回欢迎信息说明链路通了。真正到了公司里可能还会遇到网络代理、公司内网域名之类的特殊情况到那时再让运维配合排查。另外说一句如果你在个人电脑上配过SSH里面可能有一堆公私钥。到了公司项目我建议给公司单独生成一个key并考虑往~/.ssh/config里加上对特定域名的IdentityFile指定别把所有项目的密钥都混在一起。这既是安全习惯也能避免“为什么我换了个仓库clone就像换了个电脑”这种问题。2. 分支模型企业项目的交通规则2.1 为什么企业会规定分支命名和流转规则自己在GitHub上玩main分支随便push无所谓毕竟就你一个人。但企业项目是多人协作分支就是一条条并行的车道。如果没有统一的规则就会变成有人在main上直接改代码改到一半另一个同事merge上线结果把半成品带上去了有个线上bug很急结果发现main分支里堆着三天没合的功能代码根本不敢直接发feature分支名字叫dev、test、ceshi满天飞根本不知道里面在干嘛。这些无一例外都会制造混乱混乱的代价就是有人出来背锅、挨骂、写复盘。所以企业里几乎都会约定分支模型。常见的有三种Git Flow最重、适合版本制交付、GitHub Flow极简、适合持续部署、Trunk-Based主干开发、用开关控制功能。绝大多数中小型公司的Web项目我见到的实际落地是保留main和develop两条常驻分支然后根据场景开feature/、release/、hotfix/前缀的分支。下面是一个比较稳妥的约定可以当成模板分支类型命名格式从哪来合到哪去典型场景主分支main / master长期存在可发布版本线上代码永远等于可发布状态开发集成分支develop长期存在稳定功能汇合多feature的集成交互区功能分支feature/需求简述或工单号developdevelop新功能开发发布分支release/版本号developmain和develop版本上线前的回归收敛修复分支hotfix/工单号或简述mainmain和develop线上紧急bug我特别想强调一点分支命名里尽量带上需求/工单/用户故事的编号比如feature/ORD-1234-order-export。为什么因为企业里追踪需求的系统Jira、禅道、TAPD这些和Git是两套系统只有通过编号才能把代码改动和需求背景关联起来。评审人看到一个分支名就能立刻知道这串代码是奔着什么去的。这对后续回溯、查问题、找历史都极其有价值。2.2 保护分支让关键分支不能被“手滑”污染分支规则定得再好如果还是允许直接往main上push那基本等于白搭。企业Git托管平台基本都有“保护分支”功能GitLab里叫Protected BranchesGitHub里叫Branch protection rules。一般至少应该把main和develop设为保护分支规则通常是不允许任何人直接push必须通过Merge Request或Pull Request来合入合入前需要有至少一个维护者或评审人批准合入前要求CI流水线通过如果GitLab/GitHub支持禁止强制推送防止有人用force push覆盖远端历史。为什么这能避免挨骂因为一旦直接push被打断就从“人治”变成了“流程治”。过去同事不小心把未验证代码推到了main你可以骂他没脑子现在平台直接拦下来谁都不能怪只能老老实实走评审。这也是我特别推荐在每个团队落地的第一件事——分支保护是成本最低、见效最快的规范化动作。另外有些团队会纠结合入方式到底是merge、squash还是rebase。我的建议是如果你们希望主干历史是一条偏线性的干净轨迹就默认squash如果希望保留功能分支内的开发过程就用merge如果团队对rebase特别熟悉也可以rebase merge。企业里被诟病最多的往往是“merge commit太多graph跟毛线团一样”。大多数团队选squash能显著改善这个体验。2.3 分支的“保质期”长期分支是负债还有一点企业里很容易被忽略分支开得越久越容易跟develop脱节。你一个星期前从develop切出来的分支develop已经被别人合入了十个功能这时你再合回去冲突会非常酸爽。所以我会建议组员遵循“小步快跑”的原则一个功能或者一个独立任务就开一个分支分支寿命尽量控制在3天内每天开工前把目标分支的最新代码合并进来或者rebase一下功能完成立刻走评审合入尽快删掉远程分支保持仓库清爽。把分支当一次性便签而不是长期摆放的资料这就是一个技术习惯更是一个协作习惯。3. 日常开发流程标准动作越规范越不惹人烦3.1 开工前把本地仓库切到最新“地基”上很多挨骂场景的上游是开工前没把自己本地的代码“地基”更新到最新导致后面一系列冲突、覆盖、无效MR。我在团队里反复灌输一个标准动作从需要基于的分支一般是develop上切新分支之前先确保本地分支和远端一致。推荐的做法git checkout develop git pull --rebase origin develop git checkout -b feature/ORD-1234-order-export这里特意用了git pull --rebase而不是裸的git pull。因为裸pull在背后做的是merge会在本地留下一个“merge branch develop into develop”的无意义提交历史看起来平白多了个分叉。而rebase会把本地基于旧commit的改动重新排到远端最新提交之后历史更接近一条直线。可能有人会顾虑rebase的安全性问题。其实这里rebase的是本地没有发布的分支只要你不是把已经推送过的共享分支随便rebase就没有任何风险。所以请放心用。开工前的两分钟换个角度说就是把你自己的代码永远建立在最新地面之上别让自己一出生就输在起跑线上。3.2 提交原则commit要小、要独立、要说人话提交历史是团队留给未来的“工作日志”。你在企业里写的commit message不只是给你自己看的更是给三个月后回查线上bug的同事看的也是给评审人判断“这段代码为什么在这”的依据。我的建议是每个commit尽量只干一件事并且用统一的格式。业界现在比较通用的是Conventional Commits的简化版type(scope): subject optional body常见的type有feat新功能、fix修bug、docs文档、style格式调整、refactor重构、test测试、chore构建/工具。scope就是模块名或Service名。subject是一句不超过50个字、能说明“做了什么事”的话。实际对比一下会被骂的提交“fix”一般般的提交“修复bug”看着舒服的提交“fix(login): 修复token过期后未跳转登录页的问题”第三种提交在你回滚、发版、做changelog的时候价值直接拉满。说实话很多commit message规范并不是什么高深的东西就是让每个提交能当作一句完整的话被阅读。但是现实中愿意在这上面花时间的人真不多而愿意花时间的人基本都会被团队高看一眼——至少不会被审代码的人追着问“你这个提交到底改了什么”。3.3 别手滑把无关文件提交上去用git add精确添加新手最容易犯的错误是在IDE里点了“Commit All”或者习惯性执行git add -A把一堆重构产生的缓存文件、IDE配置、本地环境配置一起给提交了。企业仓库里一旦混入这种东西轻则仓库越来越乱重则误传本地密码或者密钥酿成安全问题。我强烈建议养成精确添加的习惯git status git add src/order/OrderExportService.java git add src/order/OrderExportController.java git commit -m feat(order): 增加订单导出功能先git status看清楚当前工作区有哪些改动然后只添加与本次提交相关的文件。如果你改了5个文件但只有3个属于当前提交就只add那3个。剩下两个要么留在工作区要么放到另一个commit里。这里还牵扯出一个非常重要的基础设施.gitignore。企业项目必须在初始化时就配好忽略规则一般包括编译产物target/、build/、dist/、*.class依赖目录node_modules/、vendor/IDE配置.idea/、.vscode/有些团队选择纳入共享的IDE配置那另说本地环境.env.local、config.local.*系统文件.DS_Store、Thumbs.db如果你们的仓库还没有写完整一定要尽早补否则每天都在为“哪些文件该提交、哪些不该提交”吵架。3.4 什么时候提交别憋大招也别碎成这样提交频率的尺度其实挺难把握。我在团队里通常给这样的参考每完成一个“即使后面出错也能安全回退的小逻辑块”就可以提交一次。比如一个controller接口、一个service方法、一个配置项、一个页面组件的实现都可以单独成为一个commit。绝对要避免的两种极端憋大招型一个分支上从早干到晚下班前一次性提交当中发生过什么完全无法追踪。出问题回退时只能一把梭回退整段无法精准定位。碎成末型刚写完一行字就commit打开文件就commit历史里一堆没有实际意义的提交评审人刷起来也崩溃。合理的做法是提交前自问一句“如果将来要回滚这个commit我来得及说清发生了什么吗”如果答不上来说明提交包含的东西太多了。3.5 push与准备MR/PR主动把评审人的体验安排好代码开发完成push然后创建Merge RequestGitLab叫MRGitHub叫PR。这一步是整个流程里最能体现“你是不是一个让人省心的同事”的环节。push之前先确认两件事git diff --stat develop...HEAD git log develop..HEAD --oneline第一句看和develop相比你改动涉及哪些文件、规模多大第二句看你在分支上到底多了哪些提交。如果发现你的MR里有本不该出现的文件改动或者提交信息写得稀烂就先在本地处理完再push。创建MR时尽量保证模板包含这些信息本次改动的背景对应哪个需求/工单为什么改改动范围涉及了哪些模块、哪些关键文件测试情况本地怎么测的CI跑了没有没有补测试用例需要评审人重点关注的疑点哪块逻辑是你拿不准的操作演示/截图如果是界面类改动。不要小看这个模板。你想想评审人手里一次可能排着五六个MR如果每个都写得清清爽爽他看完心里有数顺手给你Approve如果点开就是一坨改动、没有说明他大概率会先在群里把人过来问一通浪费双方时间。这其实就是“少挨骂”的核心——帮别人节省时间别人自然不骂你。3.6 冲突解决有人跟你改了同一块代码怎么办开发过程中最普遍的问题就是冲突。尤其是两个人同时改了同一个文件相近的区域。冲突本身很正常但处理不好就是挨骂的重灾区。我的建议是不要在不了解冲突内容的情况下随手把对方代码删掉先用git pull --rebase origin develop把目标分支的最新代码rebase进来顺序会让冲突更集中地暴露出来打开冲突文件系统会显示当前分支和对方分支的不同版本一个块一个块地看搞清楚这段代码是干嘛的才能定去留如果冲突涉及复杂的业务逻辑强烈建议找到冲突的另一位作者两个人当面或者拉个语音对一下。别自己默默猜着解你解错了上线出事故那可比当时问同事要挨骂得多。解决完冲突以后git add .然后git rebase --continue继续走下面的流程。记住处理冲突的原则是“两个人都满意”不是“我能编译过管他呢”。4. 代码评审真正检验你“会不会做人”的地方4.1 MR别嫌小评审人最怕“什么都往里面塞”在企业里评审代码最大的痛苦不是代码写得差而是想搞清楚“你到底改了什么”。一个MR如果混入了自动格式化、文件编码转换、依赖升级、多需求混杂评审人看着看着就放弃了。所以我一直主张一条铁律一个MR只解决一个问题。哪怕是同一个功能如果拆成“先加前端组件再加后端接口最后联调”三个MR也比一个巨大的MR好评审。评审人能在20分钟内看完的MR体验是最好的。估算一下一个MR的改动控制在200到400行以内比较理想。超过了自觉拆掉。这样做还有个额外好处当某个MR引发了线上故障回滚时影响面可控。4.2 评审意见的响应姿势认真回复比沉默要好一万倍作为代码作者收到评审意见是很正常的事。正确姿势是逐条回应哪怕只是“已修改”或者“已采用这个建议”也要明确回复。遇到你不同意的意见不要硬刚而是用证据说话——说出来为什么不能改、改了有什么风险、实测数据是什么、参考文档链接是什么。这种沟通方式在哪个公司都吃香。反过来如果评审人给了意见你一句话不回直接改完重新push会让对方感觉自己被当成了审核机器人。久而久之就没人愿意好好review你的代码了。其实这不光是Git操作问题更是一个基本职场沟通问题。把评审当成一次技术讨论而不是审判心态会好很多。4.3 合入之前让CI帮你守好最后一道门现在稍微正规一点的企业MR合入前都要求跑CI流水线至少包括编译、单测、静态检查。我的经验是push代码之前尽量先在本地跑一遍相关测试别把“让CI红着”当成一种习惯。CI红灯挂在那如果人人视而不见很快整个团队的自动化防线就形同虚设。等CI变绿、拿到至少一个approve以后再执行合入。合入前如果目标分支有更新再次rebase一下把主干最新代码吸收进来。合入之后顺手把已经合并的远程分支删掉——这条很容易被忽略但分支堆积也是仓库混乱的一大来源。在企业里还有个小细节很多团队的MR模板里会要求写“close #工单号”合入代码后需求系统自动跳转状态省掉人工更新。这种细节都是加分项用起来。5. 回滚与事故自救线上挂了怎么操作才不挨骂5.1 已经推送的共享分支别随意reset还要force push这算企业Git使用中最危险的操作没有之一。场景通常是有人不小心把一个错误提交push到了develop然后想着“我把它撤销掉”就执行了git reset --hard HEAD~1 git push --force origin develop如果这个develop分支只有你自己在用问题不大。但一旦其他人已经基于那个错误的提交创建了新分支或者拉取过代码你的--force会把所有人的历史重新洗一遍。别人下次pull的时候会出现一堆莫名其妙的冲突甚至提交丢失。这种事发生过一次基本整个团队都会记住你但记的是坏的印象。在企业环境里对已经推送并且多人共享的分支正确撤销操作是git revert不是git resetgit revert HEADgit revert会生成一个新的、方向相反的提交而不是把历史删掉。这样历史是往前走的其他人都能安全同步而且新提交里明确记录了“这次提交是为了回滚某一次提交”的因果关系。企业里要的可追溯性这才是。5.2 回滚merge提交记住那个parent参数如果线上事故是通过一次merge引发的直接git revert merge的commit-id会有个坑因为merge提交带有两个父提交Git不知道你要撤销到哪个方向。这时要指定主分支方向git revert -m 1 merge-commit-id-m 1代表保留merged from的那个父分支上的代码一般是主分支。这个命令我建议每个开发都提前了解因为你大概率会遇到一次“一个没验证好的feature分支被合进develop导致所有同事的环境崩了”的场面。真到那一步现查文档固然也能搞定但如果手忙脚乱中再操作错线上事故就可能升级成团队事故。5.3 万一真执行了reset还有reflog能捞人说句实话哪怕老手也会有手滑的时候。如果已经执行了reset在远端也有朋友已经被你搞乱可用的救命工具是git reflog。reflog记录了本地所有HEAD移动的历史包括reset之前。git reflog git reset --hard HEAD{2}这个操作能把本地HEAD恢复到reset之前的状态。但请注意reflog是本地日志无法同步给其他人。如果你的reset已经push到了远端远端其他人的本地状态是没办法靠你的reflog来恢复的。所以最稳妥的生存法则还是共享分支上永远revert绝不reset后强推。5.4 线上hotfix的流程一切为了快但不能乱再说一下hotfix的标准流程。线上出bug第一步是从main而不是develop切出hotfix分支git checkout main git pull --rebase origin main git checkout -b hotfix/P0-payment-static修复完提交、走快速评审、合回main、触发生产发布。发布成功后别忘了把hotfix的commit也同步到develop免得下一次发版时这个修复被遗漏。hotfix的精髓在于先保证线上稳定再做双向同步。如果不先发main再同步develop而是先改了develop再逆向往main合很可能把还没验证的feature一并带上线引发二次事故。6. 那些年见过的“被骂现场”企业Git踩坑速查6.1 高频雷区对照表我把企业里最容易引发冲突和“教育”的操作整理成了一张速查表。可以收藏起来提交之前对一下。现象后果正确姿势commit message写“fix bug”无法追溯评审人看不懂按type(scope): subject格式写清楚提交里混入target、node_modules仓库膨胀、评审痛苦配.gitattributes/.gitignore精确add直接把.env或密钥提交上去安全事故严重挨骂甚至通报第一时间撤出密钥并轮换配ignore把一个MR塞入多个需求评审人崩溃难以回滚拆成多个MR一MR一需求不拉最新代码直接push被拒后乱merge历史分叉跟毛线团一样先pull --rebase再push在共享分支上reset后force push别人本地历史全部紊乱用revert而不是reset同一个功能分支用了一周还没合冲突爆炸reviewer头疼分支寿命3天内及时合入删除大文件视频、二进制包直接提交仓库体积无限膨胀、clone超慢用Git LFS或者放对象存储6.2 一周之内让团队“少挨骂”的落地清单如果你想在现有团队里推动这些规范别一上来就开全员大会讲两小时理论效果很差。我建议按下面的顺序一周内潜伏式落地第一天检查并统一全员user.name和user.email配置换行符.gitattributes补全.gitignore。第二天把main和develop设为保护分支禁止直接push强制MR。第三天整理一份简洁的《分支命名与提交信息规范》文档放在仓库README里。不用长两页以内。第四天在MR模板里加上描述、改动清单、测试说明三个段落。第五天约定合入策略推荐squash把CI门禁打开要求至少1个approve才能合入。这套动作成本很低但效果立竿见影。我见过不少团队用这类规范在两周内把主干历史从一团乱麻变成清晰轨迹大家在评审时的火气也小了很多。还可以配合一些工具减轻手动的压力commitlinthusky在本地提交时自动校验commit messageprettiereslint通过pre-commit钩子在提交前格式化避免格式问题在评审阶段争吵GitLab/GitHub自带的merge request模板功能让团队每个MR都踩着同样的结构走。工具是死的习惯是活的。工具能拦住低级的错误但真正决定团队Git质量的是每个人愿不愿意在“让别人省心”这件事上花那点心思。6.3 真到被骂的时候怎么补救说一千道一万总会有犯错的时刻。如果真的因为Git操作搞出了乱子我的建议是第一时间坦诚同步别自己闷头乱试命令。很多Git灾难本质上不是问题本身有多严重而是当事人慌张之下连续操作把小问题滚成了大毛球。把现象截图把操作历史发出来团队里总有经历过类似情况的人大家救场的速度要比你想象中快得多。我刚工作那年有一次在develop上做git rebase -i想改一个历史提交结果中途改错把三天的提交全打散了急得满头汗。最后拉了旁边一个老前辈他看了一眼reflog二十分钟就把分支恢复原样。事后他跟我说了一句话我一直记着“Git不是用来考人的是用来帮人干活的。你自己觉得不拿手的时候就按最省事的流程来别秀操作。”这句话也送给你们。企业里用Git真的不需要你用多华丽的命令把基础流程走得稳稳当当就已经超过了很多人。毕竟“少挨骂”的诀窍从来不是多聪明而是少给别人添麻烦。
企业级Git实战：从分支管理到代码评审的规范流程
刚进公司那阵子我因为Git的操作问题被导师和同事“教育”了好几回。不是代码写得烂也不是业务理解差而是分支切错了、提交信息写得看不懂、或者干脆把一个带着一堆无关改动的MR丢给了评审人。后来自己也开始review别人的代码才彻底明白在企业里用Git真正考验人的不是命令背得有多熟而是你有没有一套让别人舒服、也让历史清晰的流程习惯。这篇东西我想写给刚入行、或者刚换到一家对代码规范比较较真的公司的朋友也适合那些团队里Git用得很“野”、想慢慢立规矩的组长或者核心开发。我会按一个完整的企业级交付流程来讲——从环境配置、分支模型到日常提交、代码评审再到线上事故怎么回滚、怎么避免把整个仓库搞乱。基本覆盖你在公司里会被骂的所有高危场景。看完不说从此封神至少能在下次提交代码之前多想一想少踩几个坑。1. 环境配置把“你是谁”和对齐工具先搞定1.1 提交身份user.name 和 user.email 别乱填很多人在自己电脑上装完Git就直接开用user.name填个网名user.email填个私人邮箱。这件事拿到企业里就是隐患。因为Git里每一次提交都会记录author信息代码评审系统、CI/CD平台、代码搜索工具全都会拿这个字段来定位“这段代码是谁写的”。如果你把邮箱配成了自己某年注册的QQ邮箱或者一个搞笑昵称轻则别人在代码历史里根本认不出你重则出了问题复盘时责任落不到人头上最后大家只能互相猜。我建议到了新公司第一天第一件事就是问清楚公司要求的提交邮箱格式然后执行git config --global user.name 你的中文或拼音全名 git config --global user.email 你的公司邮箱company.com注意这个配置存放在全局的~/.gitconfig里它影响你本机所有仓库。如果你想在某些个人项目里用另一个身份可以单独在那个仓库目录下用git config --local覆盖。但在公司项目里请始终用公司身份别嫌麻烦。另外一个很现实的点如果你在提交之后才发现邮箱配错了就算改回去历史里已经写错的提交也不会自动更正。企业里一般不让随便filter-branch或者rebase改历史因为一旦推送过后面的同事已经基于这些提交干活了。所以配错邮箱这事唯一的解法就是一开始就配对。1.2 换行符与文本编码被忽略却最容易制造海量diff这一条我提出来是因为它太容易挨骂了你明明只改了一行代码push上去以后整个文件几百行都被标成改动。评审人打开MR一看满屏红色第一反应就是给你打回。问题多半出在换行符上。Windows默认用CRLF换行Linux和macOS用LF。如果你的仓库没有一个统一的换行符约定Git在对比的时候就会认为整个文件都变了。一般的处理方式是在Windows上配置git config --global core.autocrlf true这个配置会在你checkout时把LF转成CRLF在你commit时把CRLF转回LF保证仓库里存的始终是LF。macOS和Linux的同学可以设core.autocrlf input。不过最可靠的还是直接在仓库根目录放一个统一的.gitattributes文件* textauto *.sh text eollf *.bat text eolcrlf.gitattributes是跟仓库走的团队每个成员都会自动使用同一套规则比你挨个通知大家改global配置靠谱得多。这种文件应该在新仓库初始化时由负责人加上如果你们仓库还没有建议尽快补一个你没准能拯救一批被换行符折磨的同事。编码问题同理企业项目里统一UTF-8基本是底线。如果你在Windows记事本里编辑过文件保存成带BOM的UTF-8个别构建工具和脚本可能直接崩那种问题排查起来特别费劲。1.3 SSH Key与Clone方式别总让CI和同事等你的密码企业里Clone代码一般两种方式HTTPS或者SSH。HTTPS虽然在浏览器里输密码很方便但企业普遍开了两步验证或者SSO经常隔一阵就要求重新认证很烦。SSH是一次配置长期使用更推荐。配置SSH的连接链路大概是本地生成密钥对把公钥贴到GitLab/GitHub企业版/Gitee的后台然后本地测试通不通。ssh-keygen -t ed25519 -C youcompany.com ssh-add ~/.ssh/id_ed25519 ssh -T gitgitlab.com如果ssh -T返回欢迎信息说明链路通了。真正到了公司里可能还会遇到网络代理、公司内网域名之类的特殊情况到那时再让运维配合排查。另外说一句如果你在个人电脑上配过SSH里面可能有一堆公私钥。到了公司项目我建议给公司单独生成一个key并考虑往~/.ssh/config里加上对特定域名的IdentityFile指定别把所有项目的密钥都混在一起。这既是安全习惯也能避免“为什么我换了个仓库clone就像换了个电脑”这种问题。2. 分支模型企业项目的交通规则2.1 为什么企业会规定分支命名和流转规则自己在GitHub上玩main分支随便push无所谓毕竟就你一个人。但企业项目是多人协作分支就是一条条并行的车道。如果没有统一的规则就会变成有人在main上直接改代码改到一半另一个同事merge上线结果把半成品带上去了有个线上bug很急结果发现main分支里堆着三天没合的功能代码根本不敢直接发feature分支名字叫dev、test、ceshi满天飞根本不知道里面在干嘛。这些无一例外都会制造混乱混乱的代价就是有人出来背锅、挨骂、写复盘。所以企业里几乎都会约定分支模型。常见的有三种Git Flow最重、适合版本制交付、GitHub Flow极简、适合持续部署、Trunk-Based主干开发、用开关控制功能。绝大多数中小型公司的Web项目我见到的实际落地是保留main和develop两条常驻分支然后根据场景开feature/、release/、hotfix/前缀的分支。下面是一个比较稳妥的约定可以当成模板分支类型命名格式从哪来合到哪去典型场景主分支main / master长期存在可发布版本线上代码永远等于可发布状态开发集成分支develop长期存在稳定功能汇合多feature的集成交互区功能分支feature/需求简述或工单号developdevelop新功能开发发布分支release/版本号developmain和develop版本上线前的回归收敛修复分支hotfix/工单号或简述mainmain和develop线上紧急bug我特别想强调一点分支命名里尽量带上需求/工单/用户故事的编号比如feature/ORD-1234-order-export。为什么因为企业里追踪需求的系统Jira、禅道、TAPD这些和Git是两套系统只有通过编号才能把代码改动和需求背景关联起来。评审人看到一个分支名就能立刻知道这串代码是奔着什么去的。这对后续回溯、查问题、找历史都极其有价值。2.2 保护分支让关键分支不能被“手滑”污染分支规则定得再好如果还是允许直接往main上push那基本等于白搭。企业Git托管平台基本都有“保护分支”功能GitLab里叫Protected BranchesGitHub里叫Branch protection rules。一般至少应该把main和develop设为保护分支规则通常是不允许任何人直接push必须通过Merge Request或Pull Request来合入合入前需要有至少一个维护者或评审人批准合入前要求CI流水线通过如果GitLab/GitHub支持禁止强制推送防止有人用force push覆盖远端历史。为什么这能避免挨骂因为一旦直接push被打断就从“人治”变成了“流程治”。过去同事不小心把未验证代码推到了main你可以骂他没脑子现在平台直接拦下来谁都不能怪只能老老实实走评审。这也是我特别推荐在每个团队落地的第一件事——分支保护是成本最低、见效最快的规范化动作。另外有些团队会纠结合入方式到底是merge、squash还是rebase。我的建议是如果你们希望主干历史是一条偏线性的干净轨迹就默认squash如果希望保留功能分支内的开发过程就用merge如果团队对rebase特别熟悉也可以rebase merge。企业里被诟病最多的往往是“merge commit太多graph跟毛线团一样”。大多数团队选squash能显著改善这个体验。2.3 分支的“保质期”长期分支是负债还有一点企业里很容易被忽略分支开得越久越容易跟develop脱节。你一个星期前从develop切出来的分支develop已经被别人合入了十个功能这时你再合回去冲突会非常酸爽。所以我会建议组员遵循“小步快跑”的原则一个功能或者一个独立任务就开一个分支分支寿命尽量控制在3天内每天开工前把目标分支的最新代码合并进来或者rebase一下功能完成立刻走评审合入尽快删掉远程分支保持仓库清爽。把分支当一次性便签而不是长期摆放的资料这就是一个技术习惯更是一个协作习惯。3. 日常开发流程标准动作越规范越不惹人烦3.1 开工前把本地仓库切到最新“地基”上很多挨骂场景的上游是开工前没把自己本地的代码“地基”更新到最新导致后面一系列冲突、覆盖、无效MR。我在团队里反复灌输一个标准动作从需要基于的分支一般是develop上切新分支之前先确保本地分支和远端一致。推荐的做法git checkout develop git pull --rebase origin develop git checkout -b feature/ORD-1234-order-export这里特意用了git pull --rebase而不是裸的git pull。因为裸pull在背后做的是merge会在本地留下一个“merge branch develop into develop”的无意义提交历史看起来平白多了个分叉。而rebase会把本地基于旧commit的改动重新排到远端最新提交之后历史更接近一条直线。可能有人会顾虑rebase的安全性问题。其实这里rebase的是本地没有发布的分支只要你不是把已经推送过的共享分支随便rebase就没有任何风险。所以请放心用。开工前的两分钟换个角度说就是把你自己的代码永远建立在最新地面之上别让自己一出生就输在起跑线上。3.2 提交原则commit要小、要独立、要说人话提交历史是团队留给未来的“工作日志”。你在企业里写的commit message不只是给你自己看的更是给三个月后回查线上bug的同事看的也是给评审人判断“这段代码为什么在这”的依据。我的建议是每个commit尽量只干一件事并且用统一的格式。业界现在比较通用的是Conventional Commits的简化版type(scope): subject optional body常见的type有feat新功能、fix修bug、docs文档、style格式调整、refactor重构、test测试、chore构建/工具。scope就是模块名或Service名。subject是一句不超过50个字、能说明“做了什么事”的话。实际对比一下会被骂的提交“fix”一般般的提交“修复bug”看着舒服的提交“fix(login): 修复token过期后未跳转登录页的问题”第三种提交在你回滚、发版、做changelog的时候价值直接拉满。说实话很多commit message规范并不是什么高深的东西就是让每个提交能当作一句完整的话被阅读。但是现实中愿意在这上面花时间的人真不多而愿意花时间的人基本都会被团队高看一眼——至少不会被审代码的人追着问“你这个提交到底改了什么”。3.3 别手滑把无关文件提交上去用git add精确添加新手最容易犯的错误是在IDE里点了“Commit All”或者习惯性执行git add -A把一堆重构产生的缓存文件、IDE配置、本地环境配置一起给提交了。企业仓库里一旦混入这种东西轻则仓库越来越乱重则误传本地密码或者密钥酿成安全问题。我强烈建议养成精确添加的习惯git status git add src/order/OrderExportService.java git add src/order/OrderExportController.java git commit -m feat(order): 增加订单导出功能先git status看清楚当前工作区有哪些改动然后只添加与本次提交相关的文件。如果你改了5个文件但只有3个属于当前提交就只add那3个。剩下两个要么留在工作区要么放到另一个commit里。这里还牵扯出一个非常重要的基础设施.gitignore。企业项目必须在初始化时就配好忽略规则一般包括编译产物target/、build/、dist/、*.class依赖目录node_modules/、vendor/IDE配置.idea/、.vscode/有些团队选择纳入共享的IDE配置那另说本地环境.env.local、config.local.*系统文件.DS_Store、Thumbs.db如果你们的仓库还没有写完整一定要尽早补否则每天都在为“哪些文件该提交、哪些不该提交”吵架。3.4 什么时候提交别憋大招也别碎成这样提交频率的尺度其实挺难把握。我在团队里通常给这样的参考每完成一个“即使后面出错也能安全回退的小逻辑块”就可以提交一次。比如一个controller接口、一个service方法、一个配置项、一个页面组件的实现都可以单独成为一个commit。绝对要避免的两种极端憋大招型一个分支上从早干到晚下班前一次性提交当中发生过什么完全无法追踪。出问题回退时只能一把梭回退整段无法精准定位。碎成末型刚写完一行字就commit打开文件就commit历史里一堆没有实际意义的提交评审人刷起来也崩溃。合理的做法是提交前自问一句“如果将来要回滚这个commit我来得及说清发生了什么吗”如果答不上来说明提交包含的东西太多了。3.5 push与准备MR/PR主动把评审人的体验安排好代码开发完成push然后创建Merge RequestGitLab叫MRGitHub叫PR。这一步是整个流程里最能体现“你是不是一个让人省心的同事”的环节。push之前先确认两件事git diff --stat develop...HEAD git log develop..HEAD --oneline第一句看和develop相比你改动涉及哪些文件、规模多大第二句看你在分支上到底多了哪些提交。如果发现你的MR里有本不该出现的文件改动或者提交信息写得稀烂就先在本地处理完再push。创建MR时尽量保证模板包含这些信息本次改动的背景对应哪个需求/工单为什么改改动范围涉及了哪些模块、哪些关键文件测试情况本地怎么测的CI跑了没有没有补测试用例需要评审人重点关注的疑点哪块逻辑是你拿不准的操作演示/截图如果是界面类改动。不要小看这个模板。你想想评审人手里一次可能排着五六个MR如果每个都写得清清爽爽他看完心里有数顺手给你Approve如果点开就是一坨改动、没有说明他大概率会先在群里把人过来问一通浪费双方时间。这其实就是“少挨骂”的核心——帮别人节省时间别人自然不骂你。3.6 冲突解决有人跟你改了同一块代码怎么办开发过程中最普遍的问题就是冲突。尤其是两个人同时改了同一个文件相近的区域。冲突本身很正常但处理不好就是挨骂的重灾区。我的建议是不要在不了解冲突内容的情况下随手把对方代码删掉先用git pull --rebase origin develop把目标分支的最新代码rebase进来顺序会让冲突更集中地暴露出来打开冲突文件系统会显示当前分支和对方分支的不同版本一个块一个块地看搞清楚这段代码是干嘛的才能定去留如果冲突涉及复杂的业务逻辑强烈建议找到冲突的另一位作者两个人当面或者拉个语音对一下。别自己默默猜着解你解错了上线出事故那可比当时问同事要挨骂得多。解决完冲突以后git add .然后git rebase --continue继续走下面的流程。记住处理冲突的原则是“两个人都满意”不是“我能编译过管他呢”。4. 代码评审真正检验你“会不会做人”的地方4.1 MR别嫌小评审人最怕“什么都往里面塞”在企业里评审代码最大的痛苦不是代码写得差而是想搞清楚“你到底改了什么”。一个MR如果混入了自动格式化、文件编码转换、依赖升级、多需求混杂评审人看着看着就放弃了。所以我一直主张一条铁律一个MR只解决一个问题。哪怕是同一个功能如果拆成“先加前端组件再加后端接口最后联调”三个MR也比一个巨大的MR好评审。评审人能在20分钟内看完的MR体验是最好的。估算一下一个MR的改动控制在200到400行以内比较理想。超过了自觉拆掉。这样做还有个额外好处当某个MR引发了线上故障回滚时影响面可控。4.2 评审意见的响应姿势认真回复比沉默要好一万倍作为代码作者收到评审意见是很正常的事。正确姿势是逐条回应哪怕只是“已修改”或者“已采用这个建议”也要明确回复。遇到你不同意的意见不要硬刚而是用证据说话——说出来为什么不能改、改了有什么风险、实测数据是什么、参考文档链接是什么。这种沟通方式在哪个公司都吃香。反过来如果评审人给了意见你一句话不回直接改完重新push会让对方感觉自己被当成了审核机器人。久而久之就没人愿意好好review你的代码了。其实这不光是Git操作问题更是一个基本职场沟通问题。把评审当成一次技术讨论而不是审判心态会好很多。4.3 合入之前让CI帮你守好最后一道门现在稍微正规一点的企业MR合入前都要求跑CI流水线至少包括编译、单测、静态检查。我的经验是push代码之前尽量先在本地跑一遍相关测试别把“让CI红着”当成一种习惯。CI红灯挂在那如果人人视而不见很快整个团队的自动化防线就形同虚设。等CI变绿、拿到至少一个approve以后再执行合入。合入前如果目标分支有更新再次rebase一下把主干最新代码吸收进来。合入之后顺手把已经合并的远程分支删掉——这条很容易被忽略但分支堆积也是仓库混乱的一大来源。在企业里还有个小细节很多团队的MR模板里会要求写“close #工单号”合入代码后需求系统自动跳转状态省掉人工更新。这种细节都是加分项用起来。5. 回滚与事故自救线上挂了怎么操作才不挨骂5.1 已经推送的共享分支别随意reset还要force push这算企业Git使用中最危险的操作没有之一。场景通常是有人不小心把一个错误提交push到了develop然后想着“我把它撤销掉”就执行了git reset --hard HEAD~1 git push --force origin develop如果这个develop分支只有你自己在用问题不大。但一旦其他人已经基于那个错误的提交创建了新分支或者拉取过代码你的--force会把所有人的历史重新洗一遍。别人下次pull的时候会出现一堆莫名其妙的冲突甚至提交丢失。这种事发生过一次基本整个团队都会记住你但记的是坏的印象。在企业环境里对已经推送并且多人共享的分支正确撤销操作是git revert不是git resetgit revert HEADgit revert会生成一个新的、方向相反的提交而不是把历史删掉。这样历史是往前走的其他人都能安全同步而且新提交里明确记录了“这次提交是为了回滚某一次提交”的因果关系。企业里要的可追溯性这才是。5.2 回滚merge提交记住那个parent参数如果线上事故是通过一次merge引发的直接git revert merge的commit-id会有个坑因为merge提交带有两个父提交Git不知道你要撤销到哪个方向。这时要指定主分支方向git revert -m 1 merge-commit-id-m 1代表保留merged from的那个父分支上的代码一般是主分支。这个命令我建议每个开发都提前了解因为你大概率会遇到一次“一个没验证好的feature分支被合进develop导致所有同事的环境崩了”的场面。真到那一步现查文档固然也能搞定但如果手忙脚乱中再操作错线上事故就可能升级成团队事故。5.3 万一真执行了reset还有reflog能捞人说句实话哪怕老手也会有手滑的时候。如果已经执行了reset在远端也有朋友已经被你搞乱可用的救命工具是git reflog。reflog记录了本地所有HEAD移动的历史包括reset之前。git reflog git reset --hard HEAD{2}这个操作能把本地HEAD恢复到reset之前的状态。但请注意reflog是本地日志无法同步给其他人。如果你的reset已经push到了远端远端其他人的本地状态是没办法靠你的reflog来恢复的。所以最稳妥的生存法则还是共享分支上永远revert绝不reset后强推。5.4 线上hotfix的流程一切为了快但不能乱再说一下hotfix的标准流程。线上出bug第一步是从main而不是develop切出hotfix分支git checkout main git pull --rebase origin main git checkout -b hotfix/P0-payment-static修复完提交、走快速评审、合回main、触发生产发布。发布成功后别忘了把hotfix的commit也同步到develop免得下一次发版时这个修复被遗漏。hotfix的精髓在于先保证线上稳定再做双向同步。如果不先发main再同步develop而是先改了develop再逆向往main合很可能把还没验证的feature一并带上线引发二次事故。6. 那些年见过的“被骂现场”企业Git踩坑速查6.1 高频雷区对照表我把企业里最容易引发冲突和“教育”的操作整理成了一张速查表。可以收藏起来提交之前对一下。现象后果正确姿势commit message写“fix bug”无法追溯评审人看不懂按type(scope): subject格式写清楚提交里混入target、node_modules仓库膨胀、评审痛苦配.gitattributes/.gitignore精确add直接把.env或密钥提交上去安全事故严重挨骂甚至通报第一时间撤出密钥并轮换配ignore把一个MR塞入多个需求评审人崩溃难以回滚拆成多个MR一MR一需求不拉最新代码直接push被拒后乱merge历史分叉跟毛线团一样先pull --rebase再push在共享分支上reset后force push别人本地历史全部紊乱用revert而不是reset同一个功能分支用了一周还没合冲突爆炸reviewer头疼分支寿命3天内及时合入删除大文件视频、二进制包直接提交仓库体积无限膨胀、clone超慢用Git LFS或者放对象存储6.2 一周之内让团队“少挨骂”的落地清单如果你想在现有团队里推动这些规范别一上来就开全员大会讲两小时理论效果很差。我建议按下面的顺序一周内潜伏式落地第一天检查并统一全员user.name和user.email配置换行符.gitattributes补全.gitignore。第二天把main和develop设为保护分支禁止直接push强制MR。第三天整理一份简洁的《分支命名与提交信息规范》文档放在仓库README里。不用长两页以内。第四天在MR模板里加上描述、改动清单、测试说明三个段落。第五天约定合入策略推荐squash把CI门禁打开要求至少1个approve才能合入。这套动作成本很低但效果立竿见影。我见过不少团队用这类规范在两周内把主干历史从一团乱麻变成清晰轨迹大家在评审时的火气也小了很多。还可以配合一些工具减轻手动的压力commitlinthusky在本地提交时自动校验commit messageprettiereslint通过pre-commit钩子在提交前格式化避免格式问题在评审阶段争吵GitLab/GitHub自带的merge request模板功能让团队每个MR都踩着同样的结构走。工具是死的习惯是活的。工具能拦住低级的错误但真正决定团队Git质量的是每个人愿不愿意在“让别人省心”这件事上花那点心思。6.3 真到被骂的时候怎么补救说一千道一万总会有犯错的时刻。如果真的因为Git操作搞出了乱子我的建议是第一时间坦诚同步别自己闷头乱试命令。很多Git灾难本质上不是问题本身有多严重而是当事人慌张之下连续操作把小问题滚成了大毛球。把现象截图把操作历史发出来团队里总有经历过类似情况的人大家救场的速度要比你想象中快得多。我刚工作那年有一次在develop上做git rebase -i想改一个历史提交结果中途改错把三天的提交全打散了急得满头汗。最后拉了旁边一个老前辈他看了一眼reflog二十分钟就把分支恢复原样。事后他跟我说了一句话我一直记着“Git不是用来考人的是用来帮人干活的。你自己觉得不拿手的时候就按最省事的流程来别秀操作。”这句话也送给你们。企业里用Git真的不需要你用多华丽的命令把基础流程走得稳稳当当就已经超过了很多人。毕竟“少挨骂”的诀窍从来不是多聪明而是少给别人添麻烦。
