一、开场回答一句话定调“我主要从四个层面来做这件事分支模型设计、提交规范与自动化卡点、PR与Code Review流程、以及异常处理机制。下面我具体说。”二、详细回答内容一分支模型设计“我刚到上家公司的时候团队在Git使用上确实比较混乱——所有人都在一个develop分支上开发经常出现代码覆盖、合并冲突频繁甚至发生过上线前发现功能代码被其他人覆盖的情况。”“针对这个问题我结合团队规模6个前端设计了三分支策略”分支用途来源合并目标生命周期master线上稳定分支不接受直接提交release/hotfix → master永久develop开发集成分支不接受直接提交feature → develop永久feature/xxx具体功能开发从develop拉出合并回develop需求完成后删除“分支命名规则我也做了规范feature/20260115_order_list_optimization这样包含日期和功能描述方便追溯。”“同时约定禁止直接在develop或master上commit所有变更必须通过feature分支进来。”额外补充hotfix策略体现考虑周全“针对线上紧急修复我单独设计了hotfix流程hotfix/xxx分支从master拉出修完后同时合并到master和develop防止修复丢失合并后打tag记录版本号比如v2.3.1并同步更新CHANGELOG。这里比较关键的一点是——hotfix合并到develop时如果冲突必须先解决冲突再合不能强制覆盖。”二提交规范与自动化卡点“有了分支结构还不够提交信息乱的话回滚版本和生成CHANGELOG都很痛苦。所以我推行了Conventional Commits规范要求每个commit必须按格式写text复制下载type(scope): subject比如feat(order): 增加积分抵扣计算逻辑、fix(list): 修复下拉加载时滚动错位问题、perf(table): 优化大列表虚拟滚动渲染性能。”落实到具体的执行方式是这样的1. 配置commitlint“我先在项目里装了commitlint/config-conventional和commitlint然后在根目录建了commitlint.config.js”javascript复制下载module.exports { extends: [commitlint/config-conventional], rules: { type-enum: [2, always, [ feat, fix, docs, style, refactor, perf, test, chore, revert ]], subject-max-length: [2, always, 50] } };2. 配合husky在Git钩子层面拦截“关键是用husky在.git/hooks/层面做强制拦截。我在commit-msg钩子里调用commitlint不符合规范的提交直接报错退出commit根本生不成。这样比‘建议遵守’有效得多——不按规范写就提交不上去团队自然就统一了。”3. pre-commit也做了检查覆盖代码质量“我在pre-commit阶段配置了lint-staged只检查本次修改的文件不是全量扫描否则太慢跑ESLint Prettier如果检查不通过同样commit失败。这样从源头上保证合并到develop的代码至少是格式规范和没有明显语法错误的。”配置文件示例如果面试官追问细节json复制下载{ husky: { hooks: { pre-commit: lint-staged, commit-msg: commitlint -E HUSKY_GIT_PARAMS } }, lint-staged: { *.{js,jsx,ts,tsx}: [eslint --fix, prettier --write] } }三PR与Code Review流程“光有规范和钩子还不够合入develop这个动作必须有人把关。所以我推行了PR Code Review机制所有feature分支合并回develop必须通过GitLab/GitHub发起PR禁止本地直接merge。”PR模板设计“我设计了一个PR模板要求提交者在描述里必须填三块内容需求/修复说明一句话说清楚这个PR是做什么的关联Jira/禅道工单号影响范围改了哪些模块会不会影响其他功能自测结果贴测试截图或测试用例执行结果。模板写好放在.github/PULL_REQUEST_TEMPLATE.md里每次新建PR自动带出来。”Review规则“Code Review方面我定了两个原则至少一名同事Approve才能合并核心模块比如公共组件、权限逻辑需要两个人通过Reviewer的职责不是走形式要关注代码逻辑是否正确、是否有性能隐患、命名是否清晰、是否有单元测试覆盖。”如何让流程变轻量克服阻力“我刚推这个的时候也遇到过阻力——有人觉得‘天天给人看代码耽误时间’。后来我做了几件事让流程变轻量PR尽量拆小单个PR控制在200-300行以内别搞成大几百行的‘巨无霸PR’约定上午11点前提PR下午Review不占用下班时间我自己Review时留言尽量友善给修改建议而不是直接批评慢慢大家就不抵触了。”四合并策略与冲突处理机制“合并策略上我选择禁止直接merge强制使用PR squash merge对feature分支。这样develop上的提交历史是干净的每个功能只对应一个commit回滚的时候按功能粒度回滚即可不用在一堆琐碎的commit里翻。但有个例外——多人协作的同一功能分支我建议用rebase merge --no-ff保留详细的开发过程方便追查问题。”解决冲突的具体流程举例“举个例子有次两个feature分支同时改了同一个页面的状态管理逻辑合并时冲突了。处理流程是这样的先把develop最新代码拉下来在自己分支上执行git rebase develop解决冲突打开冲突文件手工取舍代码git add . git rebase --continue跑一遍项目的单元测试和冒烟测试确保功能没被破坏推送到远程这时候PR已经是可合并状态了。”“为了减少这类冲突我还推动了一个前置动作每天早会前所有feature分支先拉一遍develop。这个习惯养成后冲突频率下降非常明显。”五异常处理与兜底方案“即使流程再完善也可能出意外。我准备了几个应急预案”异常场景应对方案有人误推代码到develop用git revert回滚保留历史禁止用git reset --hard强推因为其他人已经基于这个commit开发了强推会导致别人本地历史错乱develop坏了需要紧急修复从master拉一个fix分支修完再合并回去同时排查develop坏掉的原因合并后发现CI/CD红优先回滚保持develop绿再排查问题不能在红线上继续叠代码hotfix漏合并到develop发现后立即补一个PR把hotfix同步过来同时复盘漏掉的原因六成果数据“这套流程推行三个月后团队内部做了一次复盘合并冲突次数从原来一个迭代平均3-4次降到几乎没有因不规范提交导致的构建失败率降低了80%回滚版本的时间从原来需要30分钟排查提交记录缩短到2分钟看commit log就能快速定位Code Review发现的有效问题潜在的逻辑缺陷或性能隐患累计20个有几次在Review阶段发现了严重的状态管理bug避免了上线后的事故。”三、回答完毕后的总结句“总结来说我做这件事的核心思路是用工具强制兜底 用机制引导习惯 用数据证明价值最终让Git流程从‘外部强加的规则’变成‘团队默认的工作方式’。”四、面试官可能的追问 回答追问回答“怎么保证100%执行”“双重保障一是Git Hook层面直接push到develop或master会被pre-push钩子拒绝自动拦截二是分支保护设置GitLab/GitHub里配置develop和master设置为Protected Branches没有MR合并权限的人根本无法直接push必须提PR。工具层面就兜底了。”“rebase和merge怎么选”“个人分支用rebase保持提交历史线性干净合入目标分支用merge --no-ff保留功能合并的记录节点。公共分支develop/master上禁止执行rebase因为会改写公共历史造成其他人本地和远程不一致。”“冲突时你偏好rebase还是merge”“我偏好rebase因为产生线性历史commit记录更清晰逐个解决冲突也更容易定位。但如果冲突复杂且多我也会用merge因为能保留合并上下文。根据冲突复杂度灵活判断。”“review时你最看重什么”“按优先级第一逻辑正确性功能是否实现、边界条件是否处理第二性能隐患循环里setState、大列表没懒加载第三可维护性命名是否自解释、组件拆分是否合理。代码风格有Prettier不在Review里纠结。”“怎么说服团队接受”“三步走第一步自己先做Demo用实际项目走通全流程第二步挑一个迭代试点只让想尝试的人先用出效果再推广第三步用数据说话三个月复盘数据证明了价值大家尝到甜头更少的冲突、更顺畅的发布自然就接受了。”“流程太严格影响效率怎么办”“初期确实有一点。做了三件事缓解一是commit规范做成VSCode的Snippet模板输入feat自动补全二是PR模板自动加载不用手写三是Husky检查时间控制在1秒以内。流程是帮人提效的不是添堵的。”“分支保护策略具体怎么配置的”“以GitLab为例在Settings → Repository → Protected Branches里把develop和master设为保护分支开启‘禁止直接push’、‘禁止强制推送’、‘合并前必须通过CI’、‘至少1人Approve’等选项。这样从平台层面彻底堵死了违规操作。”完本回答由 AI 生成内容仅供参考请仔细甄别