约定一下贡献方式？

[Copay]

组内分工完成不同页面，通过fork ~ pull request ~ merge流程更新
每个pr由两个组织不同成员review后merge入主分支
怎么样?

[iMusynx]

agree

[Copay]

https://github.com/vuejs/vue/blob/dev/.github/COMMIT_CONVENTION.md
commit message 参考

[SenkiTK]

同意

[wa143825]

同意，没问题

…

________________________________ 发件人: 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>.

[Copay]

https://help.github.com/articles/github-flow/

[SukkaW]

@Copay

那就这么约定一下具体的操作方案？

• master 分支构建稳定版本或者可以用在生产环境的版本
• 一个分支比如 canary/dev 作为开发分支
• 新功能都在别的分支做，合并到 canary/dev 中

[SukkaW]

@Copay @Guoli-Lyu

我们最终的流程可以考虑一下这样：

• 在 master 分支下搭建基本框架，同时 master 分支存储最稳定的代码，生产环境实时从 master 同步
• 在 master 上 fork 出 develop 分支，比较小的改动（还有 hotfix 等）可以直接推送到 develop（紧急修复可以推送至 master，但是事后需要 merge 回 develop）
• 较大的新特性、新模块、重构、设计较多的修复时才需要从 develop 分支上 fork 出新的开发分支，并在之后 merge 到 develop
• 当一个阶段的开发完成以后，把 develop merge 进 master，推送到生产环境

和 GitHub Flow 最大的不同我觉得就是 master 存放了最稳定的代码

[SukkaW]

@Guoli-Lyu
嗯，我觉得没问题。
@Copay 如果没有问题的话，这种工作流的我明天就写进 GUIDELINE 里面

[FourierMeow]

既然都用了Angular Commit Message Conventions，可以考虑用semantic-release来自动化changelog什么的