-
Notifications
You must be signed in to change notification settings - Fork 92
团队代码合并指南
- 团队提交PR的单位为每个Issue(以保障针对每个Issue可以快速合并代码)
- 发起名义是组织发起的(维护团队会与组长沟通,PR是否是以组织名义发起的,是否已经经过组织验收并测试、是否承担PR带来的问题)
- 尽快提交PR(为了保障代码可以顺利合并到主库,维护团队可以尽快反馈问题,需要尽快提交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
由于各个团队的Jenkinsfile配置的参数以及docker-compose-template.yaml里仓库的地址与主库不一致。提交PR的时候有可能会出现把Jenkinsfile以及docker-compose-template.yaml也提交的情况。
这种情况应当避免,因为这样相当于破坏了主库。当然维护团队也会尽量避免有类似这种情况的发生,尽量把这些个人化参数都改为参数化。这样就可以保持各类配置文件一致。
由于各个团队都在各个folk库的Master上做开发,出现了一个团队同时提交多个Issue的PR,这样的PR处理起来就会较为复杂:
-
一个PR多个Issue在代码结构上看起来很乱,搞不清楚代码修改跟哪个业务关联关系。
-
一个PR多个Issue会导致维护团队在Review代码的时候比较复杂。
-
一个PR多个Issue会造成因为某个Issue Review不通过,其他Issue都无法合并的问题。
-
团队在进行工具链任务制作的过程中,不仅需要完成工程的实现,也需要有详细的描述文档,因为最终所有的流程要在idcf主库运行起来,并且保障任何其他团队也可以通过手册把整个工具链给搭建起来。
-
所有技术文档提交都需要使用Markdown格式,这样在页面上可以直接看,不需要下载
文档提交指南:点击查看
- 编译后的文件提交(编译后的文件与代码无关,不应该提交到代码库)
- 不小心改坏或本地测试的文件提交(自己在本地不小心改坏的文件不应该提交,提交前需要自己看下)
- .gitignore设置到具体的文件(.gitignore尽量忽略掉不需要的文件夹)
- 格式化的代码导致的无效变更
由于团队在搭建环境的时候可能与主库的环境不一致,导致在团队内测试的流水线任务没问题,合并到主库后出现问题。
- 流水线执行问题(流水线阶段被Break掉,单元测试、UI测试不通)
BoatHouse@IDCF 2020