Pospal

Appearance

GitHub flow 流程 ​

工作流 ​

采用git flow + GitHub pull request 方式进行日常代码开发

分支说明 ​

两种 模型中定义了主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；

master 分支 ​

  • master 主分支是线上当前发布的版本，是稳定可用的版本
  • 必须设置分支保护，并且由专人管理
  • 只有 pull、merge 权限，没有 push 权限
  • 发布后需打上 tag

dev 分支 ​

dev 分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码。

release 分支 ​

使用规范：

  • 可以从 dev 分支派生
  • 主要作用是给当前版本提测以及修复 bug 使用
  • 在一次迭代开发完成后，将所有自测通过的功能分支代码合并 release 分支，并设置分支保护
  • 只能 merge，不能直接 push
  • 一旦封版，release 分支必须冻结，不允许任何形式的代码改动

feature 分支 ​

feature 分支通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回 dev 分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。

使用规范：

  • feature 分支作为完成某个特定功能的分支，从 dev 拉取
  • feature 分支的划分应综合业务和技术模块垂直切分，彼此互不影响
  • 只有开发自测通过的 feature 分支可以合并 release 分支
  • 项目发布生产环境后，需删除相应的 feature 分支

hotfix 分支 ​

当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从 master 分支上指定的 TAG 版本派生 hotfix 分支来组织代码的紧急修复工作。

使用规范：

  • 从 master 或者 dev 分支派生
  • 为了修复线上版本紧急的 bug 拉的分支
  • hotfix 分支的命名应该与项目 bug 管理系统的 bug 号关联起来

需求开发 ​

  • 将新需求/迭代拆分成不同的功能模块后，按模块从 dev 新建功能分支 feature/功能分支名
  • 每天至少一次拉取、合并、提交操作，使代码分支与远程同步
  • 功能开发完毕，合并进相应的 release 或者 dev 分支
  • 当有新迭代上线，dev 分支代码发生变化时，未上线的分支必须同步一次

Pull Request 工作方式 ​

Pull Request 可以和功能分支工作流、 Git flow 工作流或 Forking 工作流一起使用。 但一个 Pull Request 要求要么分支不同要么仓库不同，所以不能用于集中式工作流。

在不同的工作流中使用 Pull Request 会有一些不同，但基本的过程是这样的：

  • 开发者在本地仓库中新建一个专门的分支开发功能(一般是 feature 或者 hotfix 分支)。
  • 开发者 push 分支修改到公开的 GitHub 仓库中。
  • 开发者通过 GitHub 发起一个 Pull Request。
  • 团队的其它成员 review code ，讨论并修改。
  • 项目维护者合并功能到官方仓库中并关闭 Pull Request。