[T.4] 团队项目：团队代码管理准备

[T.4] 团队项目：团队代码管理准备

项目 内容
这个作业属于哪个课程 首页 - 2025年春季软件工程（罗杰、任健） - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里 [T.8] 团队项目：团队贡献分分配规则 - 作业 - 2025年春季软件工程（罗杰、任健） - 班级博客 - 博客园
我在这个课程的目标是 作为团队完成一个完整的软件开发流程，学习软件工程与软件开发相关流程和技术
这个作业在哪个具体方面帮助我实现目标 确定团队贡献分分配规则

代码仓库与分支图示

  1. 团队代码仓库地址：[JietBrains/BUAASE2025-TeamVersionControl: A public repo for BUAASE2025 course homework: Teamwork - Version Control].
  2. 团队完成 Task. HotFix! 后新建的代码仓库地址：BUAASE2025-TeamVersionControl-2
  3. 代码仓库的分支图示

技术选型与原因

1. DevOps 工具链

工具/技术 用途 选择原因
GitHub 代码托管与协作 完整的 Issue/PR 功能，与 CI/CD 工具天然集成，适合学生团队免费使用
Docker 容器化部署 解决环境一致性问题，简化开发、测试和生产环境的部署流程
Kubernetes 容器编排（可选） 为未来微服务化扩展预留可能性
SonarQube 代码质量分析 强制团队遵守代码规范，检测潜在 Bug 和安全漏洞
Jira 项目管理（可选） 与 GitHub 联动管理任务进度

2. 选型考量

  • 低成本高兼容：优先选择开源工具，避免商业授权问题
  • 学习曲线平缓：选择社区资源丰富的工具（如 GitHub 的官方文档和 Stack Overflow 解决方案）
  • 自动化优先：通过 CI/CD 流水线减少人工操作错误

代码仓库管理规范

1. 分支策略（Git Flow 变体）

main        —— 生产环境代码（仅允许通过 PR 合并）
release     —— 预发布分支（用于测试环境验证）
dev	        —— 集成开发分支
feature     —— 功能开发分支（按 Issue 编号命名，如 feature/ISSUE-12）
fix         —— 紧急修复分支

2. 提交规范

  • 原子性提交：每个提交只解决一个问题
  • 语义化消息：
    feat 新功能
fix 修补bug（在 <body> 里面加对应的 Issue ID）
test 测试相关
style 代码风格变化（不影响运行）
refactor 重构（没有新增功能或修复 BUG）
perf 性能优化
chore 构建过程变动（包括构建工具/CI等）
  • 关联 Issue：在提交消息末尾添加 #Issue编号（如 #12）

3. 代码审查

  • PR（Pull Request）流程：
    1. 开发者在本地创建 feature/ISSUE-12 分支
    2. 完成开发后向 dev 分支发起 PR
    3. 需要 管理员 审核通过
    4. 由项目负责人执行 Squash Merge
  • 审查重点：
    ✅ 代码是否符合规范
    ✅ 是否有完整的单元测试
    ✅ 是否存在安全漏洞（如 SQL 注入风险）

风险管理与应对

风险类型 应对方案
分支冲突 每日同步 develop 分支，feature 分支生命周期不超过 3 天
权限误操作 保护 main/develop 分支，仅允许 PR 合并；限制生产环境部署权限
代码质量滑坡 在 CI 流程中强制运行 SonarQube 扫描，未通过则阻断合并
环境不一致 使用 Docker Compose 定义开发环境，确保本地与 CI 环境一致

实践心得与规范总结

1. 遇到的问题与解决方案

  • 问题 1：多人同时修改同一文件导致合并冲突
    解决方案：

    • 通过 git fetch --all 每日同步最新代码
    • 使用 git rebase 替代 git merge 保持提交历史线性

  • 问题 2：错误代码被合并到 develop 分支
    解决方案：

    • 启用 GitHub 的 Required reviews 和 Status checks 机制
    • 紧急回滚：git revert <commit-id>

2. 流程与规范的重要性

  • 标准化操作：制定《Git 操作手册》明确：
    • 何时使用 merge vs rebase（功能分支用 rebase，集成分支用 merge）
    • 禁止 git push -f 强制覆盖历史记录
  • 工具辅助：
    • 使用 GitHub Actions 自动化运行测试和代码扫描
    • 通过 Git Hooks 在本地提交前检查消息格式

3. 团队协作规范示例

  1. 每日同步：上班第一件事执行 git pull --rebase
  2. 分支管理：
    • 新功能开发必须从 develop 分支切出
    • 分支命名：类型/Issue编号-简短描述（如 fix/ISSUE-15-login-error）
  3. 冲突处理：
    • 责任人：最后提交者负责解决冲突
    • 命令流程：
      git fetch origin  
git rebase origin/develop  
# 解决冲突后继续 rebase  
git rebase --continue

4. 关键 Git 操作理解

操作 适用场景 团队规范
git merge 合并分支（如 PR 到 develop） 保留完整历史，必须使用 --no-ff
git rebase 整理本地提交历史 仅用于 feature 分支同步 develop
git cherry-pick 紧急修复移植特定提交 需团队确认后执行
posted @ 2025-04-13 01:42  JietBrains  阅读(36)  评论(0)    收藏  举报