约定一下贡献方式？
Copay opened this issue · comments
组内分工完成不同页面，通过fork ~ pull request ~ merge流程更新
每个pr由两个组织不同成员review后merge入主分支
怎么样?
agree
https://github.com/vuejs/vue/blob/dev/.github/COMMIT_CONVENTION.md
commit message 参考
同意
同意，没问题
…________________________________
发件人: SenkiTK <notifications@github.com>
发送时间: Thursday, July 26, 2018 1:05:53 PM
收件人: DanmakuFrontendProject/ProjectHasfun
抄送: Subscribed
主题: Re: [DanmakuFrontendProject/ProjectHasfun] 约定一下贡献方式？ (#1)
同意
―
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#1 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Ac09wUY0aFif-6MCFUHVWIjX7PNpy0tUks5uKU4xgaJpZM4VgnY7>.
那就这么约定一下具体的操作方案？
- master 分支构建稳定版本或者可以用在生产环境的版本
- 一个分支比如 canary/dev 作为开发分支
- 新功能都在别的分支做，合并到 canary/dev 中
@Copay @Guoli-Lyu
我们最终的流程可以考虑一下这样：
- 在 master 分支下搭建基本框架，同时 master 分支存储最稳定的代码，生产环境实时从 master 同步
- 在 master 上 fork 出 develop 分支，比较小的改动（还有 hotfix 等）可以直接推送到 develop（紧急修复可以推送至 master，但是事后需要 merge 回 develop）
- 较大的新特性、新模块、重构、设计较多的修复时才需要从 develop 分支上 fork 出新的开发分支，并在之后 merge 到 develop
- 当一个阶段的开发完成以后，把 develop merge 进 master，推送到生产环境
和 GitHub Flow 最大的不同我觉得就是 master 存放了最稳定的代码
既然都用了Angular Commit Message Conventions，可以考虑用semantic-release来自动化changelog什么的