团队代码合并指南

基本原则：

• 团队提交PR的单位为每个Issue（以保障针对每个Issue可以快速合并代码）
• 发起名义是组织发起的（维护团队会与组长沟通，PR是否是以组织名义发起的，是否已经经过组织验收并测试、是否承担PR带来的问题）
• 尽快提交PR（为了保障代码可以顺利合并到主库，维护团队可以尽快反馈问题，需要尽快提交PR）
• 持续同步最新代码（为了保障代码与主库代码保持一致，各个团队的库以及各个开发人员的库，需要持续与主库代码同步，频率越高越好）
• PR提交名字格式：组名-IssueId-功能名

审核要求

为了提高PR审核和合并的效率，未来小组成员提交的PR需要满足：

• 提交的PR所触发的CI必须通过，小组成员需要自行检查CI状态，如果失败则需要自行修复。修复完成后再通知维护团队进行Review
• 没有普遍性代码问题，比如：hard-code配置内容，拼写错误，常识性编码问题
• 小组在自己的环境内测试通过（CodeReview、功能测试、集成测试、流水线测试），并在PR附上测试截图
• PR需要关联相关的 Issue

以上满足后，由小组组长发起Review，通过远程方式为维护团队演示所提交的内容的展示效果。演示通过后维护团队根据情况完成合并。 以上过程中如果有任何反馈和沟通，请及时更新PR历史记录，确保任何人都可以通过PR日志了解整个review和合并过程。

合并参考方案：（可参考以下方案，也可自订制方案）

方案一：

团队成员对某个功能认可，可以由任意组织级Repo、或者个人Repo提交PR到idcf主库。

方案二：

1.各个组为每一个功能创建一个分支，组员开发完，往各个组的分支上PR代码，组内做验收。

# 拉取idcf最新代码
git fetch upstream

# 根据idcf主库最新代码创建功能分支
git checkout -b <feature_branch_name> upstream/master

# 推送特性分支到团队folk库
git push -u origin <feature_branch_name>

2.组内验收通过后，接受PR，合并到自己的功能分支中，组内发起某个功能分支往idcf主库的合并。

3.idcf主库验收通过并合并代码到master分支，贡献完成。

# 删除本地特定分支
git branch -d [feature_branch_name]

# 删除远程特性分支
git push origin --delete <feature_branch_name>

4.各个组需持续与idcf主库同步，保持代码为最新代码，避免冲突。

#拉取最新代码
git fetch upstream

#合并主库master代码到folk库master代码
git merge upstream/master master

#签入合并后的代码
git push origin master

常见合并问题 && 建议：

1. 个性化配置文件也提交PR了

由于各个团队的Jenkinsfile配置的参数以及docker-compose-template.yaml里仓库的地址与主库不一致。提交PR的时候有可能会出现把Jenkinsfile以及docker-compose-template.yaml也提交的情况。

这种情况应当避免，因为这样相当于破坏了主库。当然维护团队也会尽量避免有类似这种情况的发生，尽量把这些个人化参数都改为参数化。这样就可以保持各类配置文件一致。

2. 多个Issue同时提交PR

由于各个团队都在各个folk库的Master上做开发，出现了一个团队同时提交多个Issue的PR，这样的PR处理起来就会较为复杂：

• 一个PR多个Issue在代码结构上看起来很乱，搞不清楚代码修改跟哪个业务关联关系。

• 一个PR多个Issue会导致维护团队在Review代码的时候比较复杂。

• 一个PR多个Issue会造成因为某个Issue Review不通过，其他Issue都无法合并的问题。

3. 工程文档缺失 || 格式不规范

• 团队在进行工具链任务制作的过程中，不仅需要完成工程的实现，也需要有详细的描述文档，因为最终所有的流程要在idcf主库运行起来，并且保障任何其他团队也可以通过手册把整个工具链给搭建起来。

• 所有技术文档提交都需要使用Markdown格式，这样在页面上可以直接看，不需要下载

文档提交指南：点击查看

4. 跟源码无关文件的提交

• 编译后的文件提交（编译后的文件与代码无关，不应该提交到代码库）
• 不小心改坏或本地测试的文件提交（自己在本地不小心改坏的文件不应该提交，提交前需要自己看下）
• .gitignore设置到具体的文件（.gitignore尽量忽略掉不需要的文件夹）
• 格式化的代码导致的无效变更

5. 环境不一致导致的代码合并后流水线任务在主库不工作

由于团队在搭建环境的时候可能与主库的环境不一致，导致在团队内测试的流水线任务没问题，合并到主库后出现问题。

6. 团队内没有测试人员、没有CodeReview人员

• 代码合并问题较多（多Issue合并、某个Issue带着其他Issue的相关文件）
• 没有Code Review人员（代码很多小问题，团队内部没有Review过）
• 没有测试人员，很多功能没有开发完成（功能测试、集成测试）

7. 完成一个Issue，造成了新的问题：

• 流水线执行Break（流水线阶段被Break掉，单元测试、UI测试不通）
• 造成了新的业务缺陷（新的约束导致原来的接口变化，前端功能不好用了）

8. 功能没有完成的提交

• 业务功能没有完成（不建议提交这样的PR，最小单位是Issue，如果Issue没有完成建议下一个迭代提交、或者创建技术债Issue，并合并。前提是业务代码已经完成了，只是没有做集成）