全局gitignore .DS_Store设置
https://0xmachos.com/2020-01-22-Eradicating-.DS_Store-From-Git/
1. 总则
1.1 目的
为了有效的帮助团队更简洁，更统一的管理好源码，加强源码主提交历史的清晰可读，从源头强化开发过程管理，更有效的保证产品质量。
1.2 适用范围
适用于中心全部软件开发人员以及参与中心软件开发的外部合作商的开发人员。软件开发人员包括：架构师、开发工程师、测试工程师以及需要使用源码仓库的相关人员。
2. 规范说明
2.1 源码仓库
根据项目的保密级别和参与人员范围，可以选择在以下两个仓库选择：
- 内部仓库，地址为：
- 联合开发仓库，地址为：
2.2 分支说明
分支分类
源码仓库的分支按照生命周期分为：
-
长期分支：
master,dev -
临时分支：
feature/*,release/*,hotfix/*源码仓库的分支按照用途又可分为：
-
发布/预发布分支：
master，release/* -
开发分支：
dev -
功能分支：
feature/* -
热修复分支：
hotfix/*
分支用途
-
dev：开发分支，所有最新的功能都在该分支下进行开发。 -
master：发布分支和版本基线分支，与生产环境保持一致。在生产环境上发现的问题，必须以master为基准创建hotfix/*分支来修复问题。 feature/*：作为新功能的特性开发分支，只能从dev创建，开发完毕并经过测试之后必须重新合并到dev。- 命名规则：
feature/xxx_v2.4.0_0507_blowsysun，xxx是功能描述，v2.4.0是版本号，0507是分支创建日期，blowsysun是创建人
- 命名规则：
-
release/*：命名规则release/v+发布的版本号，作为预发布分支，只能从dev创建。 hotfix/*：作为热修复分支，只能从master分离出来。仅用于修复在生产环境上发现的 bug，修复完成并测试通过后需要将该分支合并回dev及master上，并删除该分支。- 命名规则：
hotfix/xxx_v2.4.0_0507_blowsysun，xxx是bug描述，v2.4.0版本号，0507是分支创建日期，blowsysun是创建人，
- 命名规则：
分支保护
根据项目管理级别分为两类保护策略：
- 通用策略：
master分支由管理角色Master负责管理，其他人员无权限修改。 - 严控策略：
master和dev分支均由管理角色Master负责管理，其他人员无权限修改。
3. 工作流程
3.1 功能开发
标准流程
开发新功能都应遵循以下流程：
- 建议每一个功能分支
feature/*应与TAPD上的feature有明确的对应关系 - 从
dev拉取最新的分支，然后以最新的 develop 为基准创建新的功能分支，以 feature/f1 为例：
git pull origin dev
git checkout -b feature/f1 dev
- 开发人员在各自的功能分支上进行开发工作。
- 当前功能分支开发完之后，在代码仓库中提起MR（Merge Request），申请将feature分支合并回dev分支。
- MR Code Reviewer代码审查通过后，合并代码，并删除feature/f1分支。
git branch -d feature/f1
3.2 发布与预发布
标准流程
提交到预发布和生产环境应遵循以下流程：
-
从 dev 分支创建新的预发布分支
release/v0.1.0，并部署到预发布环境上测试。 -
在预发布过程中发现问题，则从对应的预发布分支
release/v0.1.0拉fix/*分支进行问题修复。issue本地修复后，提MR合并到 release/v0.1.0 分支 -
预发布分支
release/v0.1.0在预发布环境中完全测试通过，在部署到生产环境之前，需要将分支合并回dev及master，并在master打一个正式发布版本的 tag v0.1.0，最后删除release/v0.1.0
生产环境发现Bug，需要Hotfix时应遵循以下流程：
- 从 master 上分离出一个热修复分支
hotfix/*，在此分支修复
git checkout -b hotfix/queryBug_v2.4.0_0507_blowsysun master
- 验证通过之后，首先将分支重新合并回
dev及master，然后在master上打一个热修复 tag v0.1.1，最后删除hotfix/*
4. 提交与合并
4.1 Git commit message
遵循 Git 官方使用手册 中给出的 commit 书写规范：
本次提交 commit 的摘要（50 个字符或更少）
每次提交建议添加关键词前缀，用于指示本次改动的主题： 例如：feat: 增加xxx功能
- feat: 新功能（feature）
- fix: 修补 bug
- revert: 回滚上一次 commit
- docs: 文档（documentation）
- style: 格式（不影响代码运行的变动）
- refactor: 重构（即不是新增功能，也不是修改 bug 的代码变动）
- perf: 性能优化
- test: 增加测试
- build: 编译相关的修改（例如 webpack, npm, gulp 等）
- ci: CI 相关的修改（例如 Travis, Circle 等）
- chore: 构建过程或辅助工具的变动
4.2 Merge Request (MR)
- 建议在提交时需在标题中添加
[MR]前缀用于邮件推送时区分 MR 和 ISSUE. - 每个 MR 应该仅包含针对单一主题的一系列变更，不要在一个 MR 中包含多个主题。举例来说：假设你开发了 X 和 Y 两个不同主题的相关内容，若此时将所有 commit 以同一 MR 的形式进行提交，如若 Reviewer 仅认可与 X 相关的变更但不同意 Y 主题的相关变更——这将导致我们将无法对此 MR 进行合并操作。
- 每个 MR 提交人必须指定一名 Code Reviewer 进行代码审查，并由 Code Reviewer 进行合并。
5. 定制项目维护和ISV定制开发
5.1 定制项目代码
- 定制项目开发分支单独由指定tag版本拉出。
- 定制项目开发的feature，由产品评估是否合并到主流版本。
其他说明待添加
5.2 ISV定制开发
- ISV定制开发版本代码从版本tag克隆，交付给ISV做三方开发。
- 定制开发版本代码由ISV自行维护
6. 其他说明
6.1 冲突解决
特性代码开发过程中，在提交MR或push代码时，在本地应先做rebase，解决可能存在的冲突后，再提交代码或MR
git rebase dev
6.2 多模块项目管理
使用git submodule 管理多个代码仓库
版本交付包通常包含多个模块，每个模块由单独的git仓进行管理。可以使用git submodule管理多仓代码。
- 入门文档： git submodule入坑指南
- 常用命令
```bash
初始化
git submodule init
初始化&拉取代码
git submodule update –init –remote
添加模块
git submodule add https://xx.git src/xx
对子模块批量执行某项git操作
git submodule foreach
example
git submodule foreach git checkout master
> 版本交付时，应在**所有模块的git master 分支打tag**
-
```bash
git submodule foreach git tag v0.1.0