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

项目 内容
这个作业属于哪个课程 2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里 [T.4] 团队项目：团队代码管理准备
我在这个课程的目标是 学习软件工程的基础知识，和团队成员们实践各种软件工程的方法与流程，开发一个让我们值得骄傲的项目
这个作业在哪个具体方面帮助我实现目标 熟悉了团队代码管理相关工具的操作方法

一、📦 团队的代码仓库信息

二、🌲 分支管理图示

我们使用 功能分支法（Feature Branch Workflow），仓库中主要维护以下分支：

  • main: 稳定版，所有正式发布版本代码汇总
  • dev: 开发主干分支，合并所有功能分支后测试稳定后合入 main
  • feature/*: 按功能创建，开发阶段代码分支
  • hotfix/*: 修复 bug 或紧急补丁分支
  • chore/*: 项目结构、依赖管理等杂项

📊 分支示意图

三、📐 DevOps 技术选型与使用方式

类别 技术 选用原因 使用方式
沟通平台 飞书 高效讨论+在线文档 日常沟通、会议纪要、任务分配
代码托管 GitHub 开源共享 + 团队协作便利 版本管理、代码审查
分支模型 Git Feature Branch 易于多人协作 按功能建分支、合并至 dev
Git 工具 Git + gitk 可视化 + 强大命令行 分支管理、冲突解决、历史回溯
自动检查 Pre-commit Hook 格式统一 使用 .pre-commit-config.yaml 保证提交规范性

四、📂 代码管理与协作规范

分支命名规范：

  • feature/功能名：功能开发
  • hotfix/bug描述：修复 Bug
  • chore/描述：结构调整、脚本更新等

提交信息规范（采用 Conventional Commits）：

text复制编辑feat: 添加新功能
fix: 修复问题
chore: 项目结构优化
test: 增加测试代码

合并流程：

  1. 每位成员基于 dev 创建自己的 feature/* 分支开发
  2. 完成开发后推送 PR（Pull Request），由指定审核人 Review
  3. 审核通过后合并至 dev 分支
  4. 当 dev 稳定后合并入 main

五、🧱 风险识别与解决方案

风险 解决方案
合并冲突频繁 保持小粒度提交；合并前及时拉取最新分支
分支混乱 严格遵循命名规范与合并策略
审查效率低 设立 Review 机制，使用 GitHub Review 工具
提交风格混乱 配置 Pre-commit Hook 自动规范格式

六、🧠 团队实践总结与心得

1. 实践中遇到的问题与解决方法：

  • 问题：多人同时修改核心文件导致冲突
    解决：约定核心文件需提前协调，并在合并时优先解决冲突，保留双方有效逻辑并注释说明
  • 问题：成员分支命名不统一
    解决：统一制定命名规范并在 README 中说明

2. 协作中除工具外，还需关注流程和文化：

  • 需要提前规划版本迭代周期
  • 定期组织版本审查会议
  • 保持开放的沟通文化，减少重复劳动

3. 合作规范建议：

  • 每次提交说明任务点
  • 每周定期合并并 Review 分支
  • 在团队文档中维护一个 Feature 分支任务分配表

4. 对 Git 的深入理解：

  • git merge：将两个分支的历史合并为一条主线，保留两者的 commit 历史
  • git rebase：将一个分支的提交记录“平移”到目标分支之后，更利于保持提交历史的线性
posted @ 2025-04-09 23:59  Dvorag  阅读(21)  评论(0)    收藏  举报