- 别在main分支上瞎折腾
见过太多新手犯这毛病------直接在main分支上吭哧吭哧写新功能。开源项目最忌讳这个，万一你代码出bug，整个项目都得跟着崩。正确的打开方式是：从最新main分支切新功能分支，命名最好带特征，比如或。之前有个兄弟把分支命名为，结果半年后全员看到十几个test分支集体懵逼（笑cry）。
- 提交记录必须说人话
最烦那种提交信息写"修复bug"的------这特么跟没写有啥区别？好的提交信息要三要素：类型（feat/fix/docs）+模块+概要。举个栗子：
记住，以后维护代码的人可能半夜三点看着你的提交记录抓狂，做个人吧（狗头保命）。
- PR模板才是救命稻草
现在正规开源项目都有PR模板，别头铁非要自己写。模板里要填的功能说明、测试步骤、关联issue都是维护者最关心的。有次我偷懒没填测试步骤，结果被维护者连环十八问："这功能在安卓平板上测过吗？""极端网络情况会闪退吗？"......直接给我问跪了。
- 变基(rebase)的骚操作
合并分支前先rebase主分支，这操作能让你提交历史变成直线。具体操作：
遇到冲突别慌，用看哪些文件打架，解决后再。记住：永远别rebase公共分支，除非你想被团队群殴（认真脸）。
- 紧急修复要走hotfix流程
生产环境出bug时，别慌慌张张直接改代码。正确姿势是从发布标签切hotfix分支：
修完同时合并到main和develop分支，打上新标签。这套路能保证修复代码不会在下次发布时丢失。
- 善用保护分支规则
现在GitHub/GitLab都能设置保护规则：要求PR必须通过CI检查、禁止force push、必须代码审核等。虽然有时候觉得麻烦，但真是为项目好。我就曾被强制要求通过SonarQube代码质量检测，改了三遍才过关，现在回头看真香。
- 代码审查要会玩
审查别人代码时别光说"这里不行"，得给出替代方案。比如："这个循环查询数据库可能会慢，要不要改成批量查询？" 被审查时也别玻璃心，我曾经被指着代码说"这写法太骚了，我们凡人看不懂"，改完发现性能确实提升200%（捂脸）。
最后啰嗦句：多用看分支图谱，养成查改动的好习惯。在开源社区混，规范的Git操作比写炫酷代码更重要------毕竟谁都不想要一堆神仙都理不清的提交记录对吧？（溜了溜了）