Git 规范与实践
原文中文，约4700字，阅读约需12分钟。
📝
内容提要
本文介绍了规范和管理提交历史的方法，以及常见的工作流程，包括使用Angular规范的commit message和常见的工作流（如GitFlow、GitHubFlow和GitLabFlow）。重点介绍了GitHubFlow的步骤，包括fork项目、clone到本地、同步上游分支、新建分支、开发、合并代码和提交PR。还提到了一些常见的git实践和自定义git命令。
🔎
延伸解读
Commit Message 规范化的实际价值
文章强调统一清晰的 commit message 能帮助管理提交历史，方便查找和回滚。Angular 规范通过 type、scope、subject 等字段结构化信息，使提交记录更易读。在团队协作中，遵循同一规范可以减少沟通成本，也便于自动生成变更日志。
三种工作流的适用场景对比
GitFlow 分支多、流程复杂，适合版本发布项目；GitHubFlow 简化了流程，适合持续发布的中小项目；GitLabFlow 结合两者优点，适用于大型项目且合并后不需立即部署生产。选择时需考虑团队规模、发布频率和部署环境。
GitHubFlow 中的同步与冲突避免
在 GitHubFlow 中，定期同步上游 dev 分支是关键步骤。文章建议开发过程中使用 fetch、merge 或 rebase 保持本地分支与上游一致，提交 PR 前再次同步，以减少合并冲突。这有助于保持代码整洁，提高协作效率。
容易被忽略的 Git 配置细节
文章提到 Windows 下 Git 默认大小写不敏感，可通过 core.ignorecase 配置修改；文件权限变化也可忽略。此外，自定义命令别名能提升操作效率。这些配置虽小，但在跨平台协作中能避免意外问题。
🏷️
