团队的代码仓库地址
GitHub - Meng-XuanYu/JayJay-TeamVersionControl: A public repo for BUAASE2025 course homework: [Teamw](https://github.com/Meng-XuanYu/JayJay-TeamVersionControl)
## 团队完成 **Task. HotFix!** 后新建的代码仓库地址
[GitHub - Meng-XuanYu/final-cleaned](https://github.com/Meng-XuanYu/final-cleaned)
## 代码仓库的分支图示

## 情况说明
**操作失误**
在进行Task.2的一次pr的时候,@孟烜宇 提出pr的时候误将dev分支合并到feature/emoji-2分支,虽然及时发现并且关闭了pr,但是@王怀阳 眼疾手快解决了冲突并允许了这次的pr,导致后续操作出现了一些问题。
发现问题之后,利用reset指令退回并完成了正确合并。
**message未规范**
一开始有些同学未阅读Commit Message的提交规范,后续均规范。
## 团队安排
### DevOps 技术选型
本团队基于初期开发测试及用户量较少的情况,选择腾讯云北京六区单台服务器(2核CPU/4GB内存/3Mbps带宽),搭配220GB SSD存储及包年计费,兼顾性能、成本与扩展性;团队通过飞书实现高效沟通(消息状态追踪、云端文档协作)和GitHub分支管理推进代码开发,并配置了GitHub Actions自动化CI/CD流程(main分支推送触发依赖安装与Django测试),确保低成本、高协同的技术架构支撑项目初期运行与迭代优化。
### 团队代码管理
#### 代码审查与工作安排
总的代码仓库管理由 PM @孟烜宇 负责,拟采用前后端分仓库进行管理开发的模式,同时部署到同一台服务器上,进行持续的部署与开发。 在代码审查方面,团队安排专人进行 Pull Request 的审查,解决潜在的代码冲突问题,具体安排为:
* 前端 Pull Request 审查:@孟烜宇
* 后端 Pull Request 审查:@曹玮琳
#### 分支规范
1. main 分支 `线上在跑的版本`
1. 提供给用户使用的**正式版本** 和**稳定版本**;
2. 🏷️ 所有**版本发布** 和 **Tag** 操作都在这里进行;
3. ❌ **不允许**开发者日常 push,只允许从 release 合并。
2. release 分支 `将要上线的版本`
1. 从 develop 分支检出,只用于发布前的确认;
2. 允许从中分出 fix 分支,修复的 commit 需要 push 回 dev;
3. ❌ **不允许**开发者日常 push,只允许从 dev 合并。
3. dev 分支 `日常开发汇总`
1. 开发者可以检出 feature 和 fix 分支,开发完成后 push 回 dev;
2. 保证领先于 main;
3. ❌ **不允许**开发者日常 push,只允许完成功能开发或 bug 修复后通过 pull request 进行合并。
4. feature 分支
1. 从 dev 分支检出,用于新功能开发;
2. 命名为 `feature/name`,如 `feature/resume_generation`;
3. 开发完毕,经过测试后合并到 dev 分支;
4. ✅ 允许开发者日常 push.
5. fix 分支
1. 从 dev 或 release 分支检出,用于 bug 修复(feature 过程中的 bug 直接就地解决);
2. **特殊情况下**允许直接从 main 直接开 fix 分支进行修复;
3. 命名为 `fix/issue_id`,如 `fix/2` ;
4. 修复完毕,经过测试后合并到原来的分支(dev/release/main),**并且保证同时合并到 dev**;
5. ✅ 允许开发者日常 push.
6. chore 分支
1. 从 dev 分支检出,用于各项修正,如重构、风格优化等;
2. 命名为 `chore/name`,如 `chore/resume_generation`;
3. 开发完毕,经过测试后合并到 dev 分支;
4. ✅ 允许开发者日常 push.
#### 潜在风险与应对措施
##### (一)代码冲突
提到风险,首当其冲的肯定是令人头疼的 conflict。在这次作业 Task 2 的合并任务中,同学们修改了同一文件的同一代码段,导致了 pr 时的冲突。解决方法是借助 git 的冲突解决功能,手动对比冲突部分代码,选择合适的代码保留。为减少这类问题的发生,我们制定了**更加明确的开发规范**,即:
1. 开发新的 feature 前,先 pull 下来最新代码,确保本地代码是最新状态,再检出相应的 feature 分支
2. 分工合作时尽量避免同时修改同一文件的相同区域。如果实在不可避免,那么任务重合的同学们要做好沟通。
3. 在完成自己的代码准备发起 pr时,及时 rebase 准备合并新的分支,方便审查的同学进行整合和 review 。
##### (二)敏感数据
打到这行已经很困很困的时候,将 API 密钥,个人信息等敏感内容误推送到仓库也是有可能的。在此情况下,采用这次作业中介绍的 git-filter-repo 这样的工具也只能作为最终手段,亡羊补牢。
要从根源上防控此类风险,关键还是在于在搭建仓库伊始将可能含有敏感信息的配置文件都写入 .gitignore ,开发的同学时刻保持细心以及审查的同学在 review 时仔细审核、及时止损。
##### (三)数据丢失
虽然是小概率事件,但是不当的删除、故障的硬件、手滑的删库以及坏蛋的攻击都能导致数据丢失。因此,我们有必要对仓库做好**备份** ,以及对 git history 进行适当的**审计** (此时,**规范清晰的 commit message** 就显得尤为重要),有备无患。
##### (四)依赖管理
项目往往依赖大量的外部库、框架和工具,这些依赖项的版本问题、兼容性问题还有其他神奇的小 bug 都可能影响项目的正常运行。对于我们这一意向展开跨平台开发的组而言,更需要关注处理好依赖管理问题。为此需要我们记录好依赖项版本与其他信息;同时,也要做好充分的软件测试,模拟不同的运行场景;最后在引入新的包时进行适当的讨论,不要写到哪加到哪,保障好项目的稳定。
## 心得体会
这次任务大家线下一起完成的,效率还算比较高。下面让我们来一起看看大家有什么心得吧。