关于git:Git-工作流程

团队多人合作，必须要有一个适宜团队的，标准的工作流程

合作必须有一个标准的工作流程，让大家无效地单干，使得我的项目东倒西歪地倒退上来。” 工作流程 ” 在英语里，叫做 ”workflow” 或者 ”flow”，原意是水流，比喻我的项目像水流那样，顺畅、天然地向前流动，不会产生冲击、对撞、甚至漩涡。

市面上次要有 3 中工作流 Git flow，Github flow，Gitlab flow。这里咱们采纳Git flow 工作流。

上面具体介绍该工作流

次要特点

首先，我的项目存在 两个长期分支。

• 主分支 master
• 开发分支 develop
  前者用于寄存对外公布的版本，任何时候在这个分支拿到的，都是稳固的散布版；后者用于日常开发，寄存最新的开发版。
  （两个长期分支）

其次，我的项目存在三种 短期分支。

• 性能分支（feature branch）
• 补丁分支（hotfix branch）
• 预发分支（release branch）（可用集体开发分支代替）

日常开发

• 创立集体开发分支，基于近程 dev 创立

  git checkout -b feature-a origin/dev

• 同步 dev 分支

  git rebase origin/dev

• 实现开发，commit，push 近程。
• 发动合入 dev 分支申请（应用 gitlab 新建合并申请）
• 管理者承受合并申请，代码合并进入 dev 分支。

预公布版本测试、正式发版

• 创立预公布分支（如：release-1.0.0），基于 dev 分支创立预公布分支
• 测试预公布分支代码
• 测试通过后，合入 master 分支
• 正式公布版本，打版本 tag

bug 修复

预公布版本 bug 修复

• 创立 bug 分支，基于预公布版本分支创立。（假如预公布版本分支为：release-1.0.0）

  git checkout -b 15-release-1.0.0-bug-a origin/release-1.0.0

  倡议 bug 分支命名标准：与 issue 的名字保持一致，并且以 issue 的编号起首。如 ”15-release-1.0.0-bug-a “。
  开发实现后，在提交阐明外面，能够写上 ”fixes #14″ 或者 ”closes #67″。Gitlab 规定，只有 commit message 外面有上面这些动词 + 编号，就会敞开对应的 issue。
  如未创立 issue，去掉头部的编号。

• 实现修复 bug，本地提交（commit），push 近程。
• 发动合入预公布版本分支（应用 gitlab 新建合并申请）。

• 发动合入 dev 分支（应用 gitlab 新建合并申请）。

  留神：bug 修复实现后，同时须要合入 dev 分支

• 管理者承受合并申请，代码合入指标分支。

master（线上）bug 修复

流程同 “ 预公布版本 bug 修复 ” 流程

区别在于

• 分支名为 15-master-1.0.0-bug-a
• bug 修复实现后，发动合入 master 分支和 dev 分支。