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

团队的代码仓库地址

[GitHub - Meng-XuanYu/JayJay-TeamVersionControl: A public repo for BUAASE2025 course homework: Teamw

团队完成 Task. HotFix! 后新建的代码仓库地址

GitHub - 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 审查：@曹玮琳

分支规范

main 分支 线上在跑的版本
1. 提供给用户使用的正式版本和稳定版本；
2. ️ 所有版本发布和 Tag 操作都在这里进行；
3. 不允许开发者日常 push，只允许从 release 合并。
release 分支 将要上线的版本
1. 从 develop 分支检出，只用于发布前的确认；
2. 允许从中分出 fix 分支，修复的 commit 需要 push 回 dev；
3. 不允许开发者日常 push，只允许从 dev 合并。
dev 分支 日常开发汇总
1. 开发者可以检出 feature 和 fix 分支，开发完成后 push 回 dev；
2. 保证领先于 main；
3. 不允许开发者日常 push，只允许完成功能开发或 bug 修复后通过 pull request 进行合并。
feature 分支
1. 从 dev 分支检出，用于新功能开发；
2. 命名为 feature/name，如 feature/resume_generation；
3. 开发完毕，经过测试后合并到 dev 分支；
4. 允许开发者日常 push.
fix 分支
1. 从 dev 或 release 分支检出，用于 bug 修复（feature 过程中的 bug 直接就地解决）；
2. 特殊情况下允许直接从 main 直接开 fix 分支进行修复；
3. 命名为 fix/issue_id，如 fix/2 ;
4. 修复完毕，经过测试后合并到原来的分支（dev/release/main），并且保证同时合并到 dev;
5. 允许开发者日常 push.
chore 分支
1. 从 dev 分支检出，用于各项修正，如重构、风格优化等；
2. 命名为 chore/name，如 chore/resume_generation；
3. 开发完毕，经过测试后合并到 dev 分支；
4. 允许开发者日常 push.

潜在风险与应对措施

（一）代码冲突

提到风险，首当其冲的肯定是令人头疼的 conflict。在这次作业 Task 2 的合并任务中，同学们修改了同一文件的同一代码段，导致了 pr 时的冲突。解决方法是借助 git 的冲突解决功能，手动对比冲突部分代码，选择合适的代码保留。为减少这类问题的发生，我们制定了更加明确的开发规范，即：

开发新的 feature 前，先 pull 下来最新代码，确保本地代码是最新状态，再检出相应的 feature 分支
分工合作时尽量避免同时修改同一文件的相同区域。如果实在不可避免，那么任务重合的同学们要做好沟通。
在完成自己的代码准备发起 pr时，及时 rebase 准备合并新的分支，方便审查的同学进行整合和 review 。

（二）敏感数据

打到这行已经很困很困的时候，将 API 密钥，个人信息等敏感内容误推送到仓库也是有可能的。在此情况下，采用这次作业中介绍的 git-filter-repo 这样的工具也只能作为最终手段，亡羊补牢。

要从根源上防控此类风险，关键还是在于在搭建仓库伊始将可能含有敏感信息的配置文件都写入 .gitignore ，开发的同学时刻保持细心以及审查的同学在 review 时仔细审核、及时止损。

（三）数据丢失

虽然是小概率事件，但是不当的删除、故障的硬件、手滑的删库以及坏蛋的攻击都能导致数据丢失。因此，我们有必要对仓库做好备份，以及对 git history 进行适当的审计（此时，规范清晰的 commit message 就显得尤为重要），有备无患。

（四）依赖管理

项目往往依赖大量的外部库、框架和工具，这些依赖项的版本问题、兼容性问题还有其他神奇的小 bug 都可能影响项目的正常运行。对于我们这一意向展开跨平台开发的组而言，更需要关注处理好依赖管理问题。为此需要我们记录好依赖项版本与其他信息；同时，也要做好充分的软件测试，模拟不同的运行场景；最后在引入新的包时进行适当的讨论，不要写到哪加到哪，保障好项目的稳定。

心得体会

这次任务大家线下一起完成的，效率还算比较高。下面让我们来一起看看大家有什么心得吧。

https://kcndrjeyd269.feishu.cn/sync/SrfBdlj6SsNrpxbod85cNUManWe

https://kcndrjeyd269.feishu.cn/sync/KM3vdEJQEsHtwtbZ55NcCe4RnVh

我之前使用Git bash进行操作，导致分支变动等信息无法可视化，有些git操作理解起来略微困难，再加上我总找到种种借口不去系统学习Git，因此我对许多git操作都不理解。当遇到问题时，我只能删除本地仓库后重新克隆。但这次实践中，我在队友的帮助下使用VScode进行git操作，发现分支变动等信息都被可视化了，理解起来很方便，我也因此对git更熟悉了。

此外，关于团队如何使用版本管理系统进行协作，我有了更深的理解。每个分支都有其特定的功能和操作规范，每次commit信息要遵循特定的格式，每次分支合并要提出申请后由专门的审核人员进行操作......可以说，“如何协作”本身就是一门学问。

——小呆呆（卢裕轩）

最初接触Git是学习面向对象的时候，只需要add,commit,push和pull。后来是数据库的组队，虽然也是团队合作，但是没有使用到分支，而是两个人都向同一个分支做修改。这次的Git任务让我对于Git有了更新的认识，之前远远没有挖掘到Git的强大之处--分支。”Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次“。我通过这次任务，将会深刻地改变以后的开发方式。以往我会比较抗拒使用分支，感觉一不小心就会把所有事情弄乱。而当我真正开始尝试使用分支，发现一开始的磕磕绊绊都是值得的。这会让团队开发更加高效。

除此之外，各种规范也让我感受很深。在一个严肃的开发任务中，bug的提交，commit message的格式，分支的命名都是有一个格式的。可能一开始大家不喜欢这种条条框框，但是随着项目的推进，这是让一切变得有条不紊的保障。这次任务真的可以说是收获满满。

——迷糊老师（周佳琪）

这次任务中主要是学习了与git分支相关的知识，涉及到git branch, git checkout, git pull, git merge, git rebase等指令。

我之前使用github管理项目时，虽然能暂存，提交，并push到时候仓库里去，但一涉及到多人协作（比如自己从仓库里直接动一下文件），就进入到知识盲区。

但通过这次任务，我意识到git真正的强大之处其实恰恰在于多人协作的方便。首先是git pull，其实相当于一次刷新操作，将当前分支中别人的改动更新过来。git rebase是换基操作，只要理解了rebase就可以理解这条指令，也就是将当前分支原本基于的“底座”换成新的“底座”，主要用于在上传自己的分支前同步别人对底座的更改，这对于同步并行开发来说非常重要。git branch可以查看分支，git checkout可以切换分支，-b则也可以创建分支。merge则用于在提出pr后真正将两个分支内容合并。这一套指令大致形成了一套同步并行开发的方案。

在实际任务中，我认真读了git rebase指令的介绍，并在团队做task2时，遇到了分支合并问题的时刻提出了自己的解决方案，也就是将每个人新创建的分支先rebase到dev分支，手动修改后保留他人信息后上传，并提出pr请求，由管理员审核后合并分支，与大家商讨后解决了问题。

——猪猪侠（曹玮琳）

在本次任务中学习了很多关于分支管理和冲突处理的知识，以前学习git由于是个人项目的管理，也没有涉及pull request方面的知识。在这次项目中，感谢同学们帮助了我让我了解到了对比git bash更方便的，对分支和commit更加可视化的VSCode工具，此外，附录中的分支规范和commit message规范也给我留下了深刻的印象，该在哪个分支开发，又该在哪个分支debug，哪个分支是只用来发布产品，还有commit message用的规范比起以往我随意的命名可以让队友简单直观的了解这次commit的功能。

此外，团队协作也包括了安全性的保障，比如说每次pr都需要团队的管理员进行审核，在分支合并时候解决冲突，或者是出了问题之后回退到哪个版本，这些都需要管理员来协调。总体而言，本次任务学到了很多关于分支的知识，收获很大。

——阿托士（尹祺霖）

分支管理和合并冲突：在多名成员同时修改同一文件时，产生了合并冲突。我们通过团队讨论和实际操作，学会了如何解决冲突，使用 git merge 和 git rebase 确保代码合并的正确性，尽量避免在主分支上直接操作。协作流程和规范：除了使用 Git，我们还需要明确团队的协作流程和规范。每个成员需要遵守提交信息规范（如使用 feat、fix 等标签），并按照分支规范（如 feature、dev、release）进行操作。每个任务完成后都需要提交 Pull Request（PR）并进行代码审查。软件操作理解：我们通过实践深入理解了 git merge 和 git rebase 的差异。git merge 会将两个分支的历史保留并合并，而 git rebase 会将分支的提交“重写”到目标分支的顶端，使历史更清晰，适合保持主分支整洁。任务分配与责任：每个成员都需负责自己的任务，并且协同完成合并和修复工作。出现问题时需要及时沟通，避免错误影响整体进度。

——波比（王寅）