github-flow.md

github flow

github flow是轻量的,基于分支的工作流,(相对应的,还有gitliab flow,自定义flow), github flow支持团队协作,适合定期要部署的项目

创建分支

• 创建时间:任何时候
• 创建目的:新特征/新想法
• 分支的结局:可能有效,可能无效
• 不影响master分支,任意提交和实验性想法都可以用

提示:

• git核心概念是分支,整个github flow都是基于分支的
• github flow规则:master分支的任何时候都是可以部署的
• 这一规则也强调了,分支应该从master创建,分支名要见名释义

提交

• 分支创建后,所有想法的落实,最后都体现在commit上
• 提交历史,是透明的,也可以让其他人明白"做了什么,为什么这么做"
• 提交日志,要描述:做了什么/为啥这么做

提示:

• 提交日志写的简洁明了,方便其他人查看

pr

pull request: 用于发起一个讨论,讨论的内容是关于之前的提交, pr和git仓库底层是有交互的,一旦接受了合并请求,其他人都可以看到修改.

在github上叫pull request(pr),在gitlab上叫 merge request(mr), 但都是指同一个东西:合并请求.

什么时候开启一个pr:

• 整个开发过程中的任何时候都可以
• 代码有少许或并无改动但有图片或新想法时
• 卡住了,想要获得帮助或建议时
• 当准备好让某人来review自己的工作时

pr,可以利用github提供的@系统,要求团队或某些人对pr提供反馈

提示:

• 在开源项目中贡献代码时,pr很有作用
• 如果是fork/pull模型中,可以为项目管理者提供变更
• 如果是共享仓库模型,pr可以开始review,或是开始讨论变更

讨论和代码审查

开启一个pr后,审查代码的人或团队可能会有一些问题和评论.

• 代码风格不符合项目规范
• 缺少单元测试
• 也可能所有方面都是ok的

pr就是为了鼓励这类讨论而设计的,根据讨论结果和反馈, 可以继续push分支.如果有人指出缺少了某些东西,或是有bug, 可以在分支上修复,再push变更.github会在同一个pr中显示提交, 和反馈.

提示:

• pr评论都是用md写的

部署

在合并到master之前,部署分支,进行类生存环境的最终测试, 在通过了代码审查/测试,可以在生产环境部署变更,来检查, 如果出了问题,就要回滚到master分支的状态.

合并

当生存环境检查的没问题之后,后面就是合并分支到master, 此时pr记录会被保留,可以去查看,了解why/how.

提示:

• pr中是可以带某些关键字标签的,通过这些可以关联一些issues
• pr被合并时,这些关联的issues就要被关闭