进入大三，课程项目从“单打独斗”变成了“小组作战”。刚开始合作时，我们组没少在代码合并上栽跟头——A同学改了这个文件，B同学删了那个文件，最后git push时一片红，光是解冲突就花掉半天时间。痛定思痛，我决定系统性地学习和规范我们的Git工作流。
一、 摒弃“在主分支上直接开发”的坏习惯
以前觉得Git就是用来备份代码的，大家都在main分支上commit、push，效率“极高”，直到冲突爆发。我首先在组内推行了分支管理策略。
我学习到的新规则是：
- Main分支是神圣不可侵犯的，只存放稳定、可发布的代码。
- 任何新功能开发，必须先基于main切出一个新分支，例如feature/login-page。
- 严禁直接向main分支推送代码。
二、 掌握核心命令：不仅仅是add和commit
为了配合分支策略，我强迫自己熟练使用以下命令组合：
• git fetch + git rebase origin/main：这是我个人最推崇的更新方式。相比于git pull（默认是merge），rebase能将我的提交“变基”到远程最新代码之后，保持提交历史是一条干净的直线，避免了无数个无意义的“Merge branch...”提交记录。
• git stash：救命神器。当我在开发一半时，需要紧急切换到别的分支修Bug，git stash能暂存我的改动，让我瞬间切换到一个干净的工作区，修完Bug回来git stash pop，一切恢复如初。
三、 规范Commit Message（提交信息）
以前我的commit message经常是“修复了一个bug”、“又改了一下”，过两天自己都看不懂。现在，我参考了业界规范，要求自己（和组员）遵循格式：
• Type(Scope): Subject
例如：feat(login): 增加用户登录表单验证功能
例如：fix(api): 修复用户信息接口500错误
虽然刚开始觉得麻烦，但当我们回溯历史，想看看某个功能是什么时候加进去的时候，规范的commit message简直就是宝藏。
四、 引入Pull Request (Merge Request) 机制
我们利用GitHub/GitLab的Pull Request功能，建立了代码审查（Code Review）机制。当功能开发完成后，我们不直接合并，而是发起一个PR。
在这个PR里，我们会：
- 描述本次修改的内容和动机。
- 关联Issue，例如“Close #12”。
- 邀请队友进行Review。
队友在Review时不仅能发现逻辑错误，还能互相学习编码风格。通过CI/CD工具（如GitHub Actions）配置自动测试，只有测试通过且有人批准后，代码才能合并进main分支。
五、 总结
通过这一个月的Git规范化实践，我们小组的代码冲突率下降了90%以上，开发效率反而提升了。更重要的是，我意识到工具的使用方式直接反映了工程素养。作为一名准软件工程师，不仅要写出能跑的代码，更要写出“好维护、好协作”的代码。