团队协作与代码评审
Git、代码规范与项目工程化#Python全栈#第六阶段#Git、代码规范与项目工程化#团队协作与代码评审约 601 字 · 2 分钟阅读
追问显示点击任意追问卡片可收起 / 展开
个人功能分支、主分支与发布分支应该承担什么职责？
追问 小团队短周期交付与长期维护多个版本，分支策略为什么可能不同？
开始一项新功能前，应怎样检查仓库状态和任务范围？
追问 本地未提交修改、基线版本、验收条件与相关模块，分别需要确认什么？
一次 Pull Request 或 Merge Request 应包含哪些信息？
追问 如何写清触发条件、修改后行为、验证方式与兼容性影响，让评审者独立理解？
代码评审除了看格式，还应关注什么？
追问 正确性、边界条件、权限、异常处理、性能与可维护性，如何根据修改范围排序？
为什么大规模格式化容易干扰功能评审？
追问 怎样安排格式化和业务修改的提交，使真正的行为变化更容易检查？
评审意见应该怎样表达，作者又应该怎样响应？
追问 确定的缺陷、需要澄清的疑问和个人偏好怎样区分？存在分歧时依据什么做决定？
主分支保护和合并前检查能防止哪些协作问题？
追问 评审通过后又追加提交，之前的检查结果是否足够？怎样确保检查对应待合并版本？
误把数据库密码或 API 密钥提交进仓库，应该怎样处理？
追问 为什么删除当前文件还不够？凭据撤销或轮换、历史处理和访问排查应怎样协调？
紧急修复如何同步到正在开发和维护的其他分支？
追问 怎样避免修复只存在于线上对应分支，下一次发布又把问题带回来？
如何确保代码、需求记录与问题记录可以相互追踪？
追问 任务编号、提交说明、评审链接与变更记录怎样帮助定位问题？如何避免记录敏感数据？