团队项目中使用 GitHub 进行协作的实践总结

一、背景与选型
我们团队正在做一个在线考试系统的课程项目，共四人。最初代码通过QQ传来传去，经常出现版本覆盖、修改丢失的问题。于是我们决定引入源代码管理工具。可选的有 GitHub 和 TFS。考虑到我们是学生团队，需要免费私有仓库、轻量级、社区支持好，最终选择了 GitHub。GitHub 基于 Git，分支模型成熟，并且提供 Issues、Projects 看板，可以同时管理任务和代码。

二、仓库结构与分支策略
我们建立了一个组织级别的仓库，命名为 online-exam-system。仓库目录分为 backend（Spring Boot）、frontend（Vue）、docs（设计文档）。分支策略没有照搬复杂的 GitFlow，而是采用简化版本：

主分支 main 始终处于可部署状态。所有新功能从 main 切出新分支，命名规则为 feature/功能简述，例如 feature/login、feature/exam-paper。每个开发者在自己的分支上完成开发后，推送到远程仓库，然后在 GitHub 上发起 Pull Request（简称 PR）。要求至少一位队友进行代码审查，通过后再合并到 main。

这种分支策略对我们这种小团队足够清晰，没有引入过多的长期分支（如 develop），减少了合并时的认知负担。

三、日常工作流程
每个成员开始一天的工作前，先同步主分支的最新代码：git pull origin main。然后切换到自己的功能分支（如果远程还没有该分支，第一次推送时需要加上 -u 参数）。开发过程中，频繁做小步提交，提交信息采用“动词+模块”的格式，例如“修复登录接口空指针异常”。完成功能后，执行 git push，然后在 GitHub 网页上创建 PR。

PR 模板我们事先写好了固定格式，包括修改内容、测试情况、关联的 Issue 编号。审查者会检查代码规范（是否有关键信息硬编码、命名是否合理）以及逻辑是否正确。审查通过后，由作者自己合并（如果团队要求严格，也可以指定一人负责合并）。合并后立即删除远程功能分支，本地分支也删除，保持仓库干净。

四、遇到的实际问题与解决方法
第一个问题是冲突。有一次两位同学分别修改了同一个文件的不同位置，Git 能够自动合并。但有一次两人修改了同一行代码，产生了冲突。解决方法是：在本地 main 分支拉取最新代码，然后切换到自己的分支，执行 git merge main，用 IDE 的冲突解决工具手动选择保留哪一段，或者协商修改。解决后提交并推送，PR 就会自动更新。

第二个问题是提交信息随意。初期有人提交信息只写“update”，过了一周完全看不出改了什么。我们约定提交信息必须说明“为什么改”而不仅仅是“改了什么”，并且要求关联 Issue 号（例如“fix #12: 修复试卷计算总分时小数精度丢失”）。这样 git log 就会变成清晰的变更历史。

第三个问题是 GitHub Actions 自动化测试。我们写了一些简单的单元测试，并在仓库中配置了 .github/workflows/maven.yml 文件，每次 push 或 PR 时自动运行测试。如果测试失败，PR 页面会显示红色叉号，审查者可以要求作者修复后再合并。这帮助我们提前发现了多次回归性 bug。

五、项目任务与代码的关联
我们使用 GitHub Issues 来管理任务。每个功能或 bug 对应一个 Issue，指定负责人、标签（如 enhancement、bug）、里程碑。开发时，在分支名中包含 Issue 编号，例如 feature/12-exam-paper。在 PR 描述中写上 “Closes #12”，合并后该 Issue 会自动关闭。同时我们启用了 Projects 看板，分为“待处理”“进行中”“待审查”“已完成”四列。每个人每天更新卡片状态，进度非常直观。

六、效果与反思
引入 GitHub 后，再也没有出现代码覆盖的情况。分支并行开发效率明显提高，代码审查也提升了代码质量。偶尔的冲突通过沟通很快解决。不足之处是，部分同学对 Git 命令不熟悉，遇到 rebase 或撤销 commit 时感到困惑。我们后来统一使用 GitHub Desktop 图形工具，降低了入门门槛。另外，PR 审查有时会延迟，我们约定每天下午五点为审查时间，避免堆积。

七、与 TFS 的对比（简要）
TFS（现 Azure DevOps Server）也提供 Git 仓库，并集成了工作项和流水线。但对非 Windows 环境不够友好，配置相对重。GitHub 的 Web 操作更流畅，社区资料多，学生团队上手更快。如果将来团队进入企业环境且使用 .NET 技术栈，可能会考虑 TFS。但目前而言，GitHub 是最适合我们的选择。

八、总结
源代码管理不是可有可无的辅助工具，而是团队协作的基石。通过这一个月的实践，我们深刻体会到：分支模型宁简勿繁、提交信息要清晰、代码审查不能流于形式、自动化测试能减少低级错误。如果你也在做团队项目，建议尽早引入 Git 和 GitHub，不要等到代码混乱了再补救。