当前位置：首页 > news >正文

[T.4.5] 实验课/团队项目

news 2026/4/21 14:00:13

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的需求在哪里	[T.4.5] 实验课/团队项目：团队代码管理准备-Ver.5-final-final-ffffffinal最终版真的绝对不再改了!!(2)_1 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	通过学习软件工程理论与敏捷开发实践，熟悉产品从立项到交付的全流程，提升团队协作与工程开发经验。
这个作业在哪个具体方面帮助我实现目标	学习使用Git管理代码和团队协作，以及了解工程化代码标准

我们的软工实践：从 Git 混乱到工程化协作的蜕变

在项目的起点，我们首先确立了团队的 DevOps 规范。经过讨论，我们选择了 GitHub 作为代码托管平台，并明确了 DevOps 的分工。

技术选型：由于 GitHub 强大的 Issue Forms 和团队协作功能，我们将其作为核心平台。
仓库初始化：我们基于 main 分支建立了 dev 开发分支，并配置了 .gitignore 以及用于记录错误的 error-logs.txt。

规范化提交：每位成员在认领任务（如前端/后端数据重构）后，都严格按照 <type>(<scope>): <subject> 的格式编写提交信息。
初次合并：我们通过 Pull Request (PR) 将各自的功能分支合入 dev。这是我们第一次集体 Code Review，确保了代码风格的统一。

我们发现在发布前检查中 classdata.json 存在拼写错误。我们迅速从 release 分支拉取 fix 分支进行修复，并确保修复后的代码同步合入了 main 和 dev。

挑战来自于彻底抹除 /src/tofix/SUPER-SENSITIVE-DATA.txt 的历史痕迹。

通过实践，我们深刻理解了 rebase 的利弊。它能让分支图看起来像一条直线，非常美观，但在处理公共分支时必须极其谨慎。

起初觉得繁琐的 Commit 规范和分支管理，在最后进行 HotFix 和追溯历史时展现了巨大的威力——我们能通过搜索快速定位到任何一次变动。

旧仓库地址（含泄露数据）：https://github.com/paidaxingKing/BUAASE2026-TeamVersionContro
新仓库地址（纯净版本）：https://github.com/paidaxingKing/NEW-BUAASE2026-TeamVersionControl

平台选择：我们选择了github。因为我们相对熟悉github，而且它的 Pull Request (PR) 界面和冲突解决提示做得很直观，适合我们这种刚开始磨合的团队。
分工与权限：由PM作为团队的仓库管理员（DevOps）。任何人都绝对不能直接往 main和 dev里 push 代码，想合并必须提交 PR。

互相看代码：大家提了 PR 之后，不能自己点合并。管理员在合并前会重点看两件事：
1. 代码有没有跑通、有没有明显的 Bug。
2. 提交信息规范：所有 commit 必须类似 feat(模块): 做了什么 或者 fix(模块): 修了什么。便于后续发现修改BUG
发布流程：我们跑通了一套三步走的发布流：平时大家都在各自的 feature 分支写代码 -> 写完提 PR 合并到 dev -> 攒够一个版本的量后，切出 release 跑一波测试 -> 没问题了再合进 main，并且打上版本号（比如 v1.0.0）。

团队合作写代码，真正的挑战不是写功能，而是不互相覆盖代码。我们总结了这几天遇到的几个最大风险和解决办法：

遇到代码冲突
- 风险：Task 2 里大家都去改同一个文件
- 对策：我们约定，遇到冲突不能暴力覆盖别人的代码，正确做法是把对方的代码和自己的代码手动拼接起来。另外，开发时要勤用 git fetch 和 git rebase 拉取最新代码。
出现敏感数据
- 风险：历史提交记录中出现敏感文件。
- 对策：建项目第一件事就是写好 .gitignore，把密钥文件拦在外面；如果出现泄露事件，使用 git filter-branch 重写仓库历史，然后迁移到新仓库。
分支图凌乱
- 风险：大量使用Merge会导致分支图难以辨别
- 对策：我们现在要求大家在往公共分支合并前，尽量用 git rebase 把自己的修改变基到最新节点，保持团队开发历史是一条干干净净的直线。