站内链接:

Develop Model

master

master：主分支，HEAD 的源代码所在地，随时都是预备生产状态

develop：开发主分支，该分支下的 HEAD 源码始终体现了下一个发布版本的最新软件变更

assist

feature branches：功能分支，可以有好多个，毕竟一个软件是由各种各样的功能累加的

Release branch：为新产品的发布做一些准备，允许小范围的 bugs 修改和元数据的发布

Hotfixes branch：类似于 Release-branch，该分支一般在生产环境处于异常状态时产生，和 tag 一一对应

Legend

所有的分支以并行的方式从西到东, 但最终都通过一个入海口汇入太平洋.

frame

Distributed

Introduction

GIT 本身就是一个分布式版本管理系统，没有一个中心版本，origin 团队默认指向 master 主分支.

设立假设其他子团队有：alice, bod, david, clair, 团队内部可以互相获取版本的
变更信息，不用过早的向 origin 提交工作内容(比如 bamboo 每天、每小时一次的工作提交),
当然所有上述前提是项目前期就应该有非常明确的团队功能划分、软件基本架构逻辑，不然就 GG 了！

Legend

5 个团队, 其中主控团队(origin), 虽然是去中心化, 但是实际上仍旧有一个标准的, 权威团队,
整体结构图: distributed

Master

master

主分支(宇宙第一集团总指挥部，总新闻办公室), 有时候也命名为 Production(生产环境, 非对外开源项目)

devloper

开发主分支，负责新功能的钩子记录(拓荒中的 Featurer，一野集团军)、旧版本的 BUGS 修复(苦逼的开发者-BUGer，辅助 4 野集团军)

命令:

1
2
git checkout -b develop master
git merge --no-ff develop(合并)

注意：develop 分支源码到达一个稳定状态时，所有的代码变更需要合并到 master 分支，以便新闻部对外通知

Legend

master and develop

其中, 图中各个交接点含义:

  • 每一个蓝点都是一个负责人的男人标签，我叫宇宙第一集团总司令，堂堂正正的决斗吧！
  • develop 版本中每一个大功能的提出、研发阶段也伴随的之前版本的 BUG 修复(决斗失败?再来！)

Feature

功能分支, 宇宙集团月球研发组-1-10101-2FGEX

Intro

从 develop 中分离出来的某一个新功能(最强独立团，负责烧火、做饭、砍柴)，该功能分支一般是在某一个开发者或者开发者团队内部，该分支有两种结局(生-合并，死-去死).

这个分支是开发过程中最频繁创建的项目逻辑, 项目中每一个开发者持有一个功能分支, 每天凌晨从 develop 同步新的 bugfix 数据到当前分支, 每晚 12 点 pull 数据到自己的分支, 于是世界走向一片和谐, 于是世界走向末日.

在确保功能划分明确的情况下, 一般很少会发生冲突问题, 任何一个功能的完成(某一个分支的开发测试结束), 都会执行合并该分支到 develop, 然后团队内其他成员再合并 develop 代码到自己的功能分支, 以 develop 为中转同步控制器, 于是世界走向一片和谐, 于是世界走向繁荣.

Legend

feature branch

no-ff

独立第一团的历史功绩，谁都不可以遗忘.

默认情况下, git merge 会使用 fast-forward, 直接将 feature 上的改动以一次 commit 的方式归入 develop, feature-a 分支则会被删除. no-ff 选项则会保留 feature-a 的路径记录.

Release

Intro

认真、严禁的 Girl coder——宇宙集团质量审查部，某一个小 bugs 所有者——搞什么飞机

Release 分支从 Develop 分支分离，最终合并到 Develop 或者 Master 上，为新产品的发布做一些必须要的准备：

  • 细小的修改
  • 小 bugs 修复，之后归并到 develop 中
  • 发布一些元数据(版本号、开发时间等等)

When to create?

Develop 分支到达了理想的状态，即当前版本的所有 Feature 都已经 merge 到 develop 中，此时会定下版本号等信息，此时如果出现一些重大 BUGS：

  • 一旅回家种地-重修，多读点书-再等下一次军事活动再考察考察你们
  • 功能有一些不足, 需要打回

Process

  • 创建 Release branch—执行某些脚本，从而显示的声明版本信息—-提交版本信息—-修复小 bugs(重复该过程)
  • 完成 Release branch—设置 tag 标签(版本号)—-合并到 master—-合并到 develop 从而作用于下一版本

注意：整个过程从 master 分支 checkout 一个新的分支, 大范围修复, 在准备合并到 master 之前做一次同步 master 到当前分支操作, 最终才合并到 master

Hotfix

Intro

宇宙集团-公关部、市场部

从 master 从分离出来(出现生产环境 bugs)，用于快速的解决和修复 bugs，最终将修复的信息归并到 master 和 develop 中.

Process

  • 创建 hotfix branch—-提交版本信息—–修复 bugs
  • 完成 hotfix branch—-设置标签信息(小版本)—-合并到 master 和 develop 中

例外: 如果存在 release branch(不会吧?)，此时应该合并到 Release 中，最终合并到 develop 中

Legend

hotfix