Github

一、写作内容：介绍主流源代码管理工具Github 。
二、写作人：2352734
三、功能介绍：
GitHub 就像是一个“代码仓库”+“团队协作工具”，专门用来存放和管理代码，同时让团队成员可以一起开发项目，而不会把代码搞乱。

1. GitHub 的核心功能
   存代码：就像网盘一样，可以备份代码，防止丢失。
   多人协作：团队成员可以同时修改代码，GitHub 会自动合并（如果没冲突的话）。
   版本控制：如果改错了代码，可以随时回退到之前的版本。
   代码审查：团队成员可以互相检查代码，确保没有 bug 或安全问题。
   任务管理：可以用 Issues（问题跟踪）来记录待办事项，比如“修复活动报名 bug”。

2、这个校园活动聚合平台项目就像建造一栋数字大楼，GitHub就是项目的"总指挥中心"，协调着整个团队的工作。让我们看看它是如何具体发挥作用的：
（1） 代码的"中央控制塔"
统一保管所有建筑材料：就像项目负责人需要管理Java代码，或是负责Vue前端，GitHub把这些分散的代码统一存放在云端仓库
版本时光机：当调试Spring Boot接口出错时，可以轻松回退到昨天稳定的版本
多工地同步施工：前端组用feat/activity-page分支改页面，后端组用feat/api分支写接口，就像不同施工队在不同楼层作业

（2） 团队协作的"智能对讲机"
代码审查系统：提交服务器部署代码后，系统自动提醒项目相关人员进行审核
问题追踪看板：把"GPS签到不准"这类问题（类似文档中提到的痛点）创建为Issue，分配给对应成员解决
任务分配可视化：用Projects看板管理"虚拟茶话厅"开发进度，就像文档中原型设计环节的跟进

（3）项目质量的"安检系统"
自动化测试关卡：每次代码提交都自动运行测试，检查是否影响：
活动预约功能（解决文档中的"报名效率低"痛点）
跨校活动接口（对应"跨校资源割裂"问题）
安全扫描仪：自动检测代码中的安全隐患，比如文档中提到的签到系统漏洞

（4） 持续交付的"传送带"
自动部署流水线：当崔建业完成"活动回顾"功能开发（文档中80%用户期待的功能），系统自动：
打包成APP
发布到测试服务器
通知团队体验

（5） 项目知识的"智能档案馆"
技术文档库：存放着：
API文档（方便接口开发人员查阅）
部署手册（帮助运维同学快速上手）
解决方案库（记录类似"高并发优化"的处理经验）
决策记录：保存重要技术选择的原因，比如为什么选用Redis缓存活动数据

四、实际应用场景示例
当团队开发"跨校活动互通"功能时（对应文档中的核心功能）：
前端创建feat/cross-campus分支开发页面
后端同时开发对应接口
每日通过Pull Request合并进度
自动测试验证不同学校的数据互通
通过GitHub Discussions与上海海事大学团队讨论对接细节
最终功能合并后自动发布到演示环境
没有GitHub的话，这个项目可能会：
代码版本混乱（"小明你改了我的文件！"）
问题跟踪困难（"那个签到bug谁来修？"）
协作效率低下（"最新代码发我邮箱！"）
通过GitHub，团队实现了文档中提到的"需求澄清-架构设计-代码开发-联调测试"的高效协作流程，让校园活动平台的开发像运转良好的机器一样井然有序。

五、心得体会：GitHub使用心得：我的代码好帮手

（1）为什么用GitHub？
代码不丢失：所有代码存在云端，换电脑也不怕。
团队协作方便：多人一起写代码不会乱，还能互相检查。
版本可回溯：改错了能一键回到之前的版本，就像"后悔药"。

（2）我的使用技巧
✔ 分支管理：
main分支放稳定代码，平时在dev分支开发。
新功能开单独分支，比如feat/login（登录功能）。
✔ Commit备注要清楚：
写明白改了啥，比如："修复了活动报名按钮的bug"，而不是"改了点代码"。
✔ 善用Pull Request（PR）：
代码写完先提交PR，让队友检查后再合并，减少bug。
（3） 踩过的坑
❌ 代码冲突：多人同时改一个文件会冲突，解决方法是：
经常git pull更新代码。
一个功能尽量快写完，别拖太久。
❌ 误删代码：
重要分支（如main）设置保护，禁止直接修改。

（4） 真实体验
团队项目：用GitHub后，6个人写代码再也不用互相传文件，效率翻倍。
个人学习：把自己的练习代码存GitHub，面试时还能当作品集展示。
GitHub就像代码的"网盘+协作平台"，个人能用，团队必备，早点学会早点轻松！