5.3 KiB
5.3 KiB
Snow 项目 Git 管理规范
1. 版本控制基础
本项目使用 Git 进行版本控制，并遵循以下基本原则：
- 所有代码更改必须通过 Git 提交并推送到远程仓库。
- 每次提交都应包括清晰、简洁且具描述性的提交信息，便于团队成员理解变更目的。
- 严禁直接在
main分支上进行开发，所有功能开发应通过分支进行。
2. 分支管理
本项目采用以下分支策略以高效管理代码：
2.1 主分支 (main)
- 用途：
main分支始终保持项目的稳定版本，该分支的代码可随时部署到生产环境。 - 更新规则：仅允许经过充分测试并审核的代码合并至
main分支。每次从dev或release分支合并到main时，需打上版本标签。
2.2 开发分支 (dev)
- 用途：
dev分支作为所有开发工作的集成分支。所有新功能开发应首先合并至dev分支，经过集成测试后再合并到main。 - 更新规则：团队成员应从
dev分支拉取最新代码，完成开发后将功能合并回dev。
2.3 功能分支 (feature/*)
-
用途：每个新功能开发应从
dev分支创建独立的功能分支。 -
命名规范：
feature/功能描述，例如：feature/AST、feature/user-cli。 -
开发流程：
- 从
dev分支拉取最新代码。 - 完成功能开发后，在本地提交代码并推送至远程仓库。
- 创建拉取请求（PR），合并至
dev分支。
- 从
2.4 修复分支 (bugfix/*)
-
用途：用于修复 bugs。修复分支可从
dev或main分支创建。 -
命名规范：
bugfix/bug描述，例如：bugfix/fix-AST-error。 -
开发流程：
- 从
dev或main分支拉取最新代码。 - 完成修复后，提交修改并推送至远程仓库。
- 创建 PR，合并至相应分支。
- 从
2.5 发布分支 (release/*)
-
用途：当
dev分支的功能开发完成并准备发布时，应创建release分支。 -
命名规范：
release/vX.X.X，例如：release/v1.0.0。 -
开发流程：
- 从
dev分支创建release分支。 - 在
release分支上完成版本发布的最终准备工作，如文档更新和版本号调整等。 - 完成发布准备后，将
release分支合并至main并打上版本标签，随后合并回dev分支。
- 从
3. 提交规范
为确保提交信息清晰且易于理解，遵循以下提交规范：
3.1 提交信息格式
提交信息应简洁且具有描述性，格式如下：
[类型] 描述
详细描述（可选）
提交类型
feat：新增功能（feature）fix：修复 bugdocs：文档更新style：代码格式调整（不影响功能）refactor：代码重构test：增加/修改测试chore：工具配置等其他杂项任务
示例
feat: 添加 IR 折叠功能fix: 修复 IR 折叠错误docs: 更新 API 文档refactor: 优化 AST 逻辑
3.2 提交实践
- 提交时请确保代码已完成并通过所有相关测试。
- 每次提交应包含少量且相关的变更，避免一次性提交过多内容。
4. 合并和拉取请求（PR）
在多人协作开发过程中，拉取请求（PR）是确保代码质量和功能完整性的核心工具。所有的代码合并都必须经过严格的代码审查和测试验证。
4.1 拉取请求流程
- 开发者在完成功能或修复后，创建 PR，将其分支合并至
dev或main分支。 - 其他团队成员进行代码审查，重点检查代码质量、功能完整性及测试覆盖率。
- 审查通过后，PR 将被合并。
- 合并时，推荐使用 Squash and Merge 方式，避免留下过多冗余的提交历史。
4.2 代码审查
-
所有 PR 必须经过至少一名开发者的代码审查。
-
审查时应关注以下方面：
- 代码是否符合项目的编码规范。
- 是否提供了足够的单元测试覆盖。
- 是否存在冗余代码或复杂度过高的部分。
- 功能是否按预期工作。
5. 版本发布
版本发布基于 Git 标签，发布流程如下：
5.1 打标签
每当版本准备发布时，应在 main 分支上打上版本标签：
-
版本号规则：采用语义化版本控制（SemVer）格式，版本号由三部分组成：
主版本号.次版本号.修订号（例如：v1.0.0）。 -
标签命令：
git tag v1.0.0 git push origin v1.0.0
5.2 发布流程
- 确保所有功能已合并至
dev分支，并通过集成测试。 - 从
dev分支创建release分支，进行版本发布的准备工作。 - 在
release分支上完成最终修改，如文档更新和版本号调整。 - 将
release分支合并至main并打上版本标签。 - 合并
release分支的变更回dev，确保所有修复和改动在开发分支中得到同步。
5.3 发布后
- 发布版本后，团队成员应确保将
main分支的最新代码拉取到本地，以保持代码库的同步。 - 如出现生产环境问题，应及时创建
hotfix分支进行紧急修复。
6. 合作与沟通
- 团队成员应保持良好的沟通，特别是在合并大型功能时，确保不会出现冲突。
- 定期进行团队会议，回顾代码审查过程并讨论开发流程和工具的改进建议。