Git 管理branch model
分支管理
小组作战,灵活,变量
origin 是最终的原repo, 每一个开发人员都可以从origin 拉出分支,但是,除了集中的推拉关系之外,每个开发人员还可以从其他同伴那里拉出变更以组成子团队。 例如,在将进行中的工作过早地推向市场之前,与两个或多个开发人员一起使用一项重要的新功能可能很有用。 在上图中,有Alice和Bob,Alice和David以及Clair和David的子团队。
从技术上讲,这仅意味着Alice定义了一个名为bob的Git遥控器,该遥控器指向Bob的存储库,反之亦然。
两个主要的branch
一般在代码仓库中最主要的是下面两个repo
- master
- develop
每一个开发都知道 master 分支,和master 分支并行的是develop 分支。
产品的每一个版本开发都是在origin:master 开始,到origin:master 的结束上,这是一个闭环。
develop 仓库一般称为“整合分支”, 也就是我们说的"integration".当develop分支中的源代码达到稳定点并准备发布时,所有更改都应以某种方式合并回master,然后用发布号标记.因此,每次将更改合并回主版本时,根据定义,这是一个新的生产版本。 我们往往对此非常严格,因此从理论上讲,每当有主服务器提交时,我们就可以使用pipline自动将软件构建和推出到生产服务器。
其他分支
除了主要分支机构的掌握和开发之外,我们的开发模型还使用各种支持分支机构,以帮助团队成员之间进行并行开发,简化功能跟踪,为生产发布做准备并协助快速解决生产中的实际问题。 与主要分支不同,这些分支的生命周期总是有限的,因为它们最终将被删除。
-
Feature branches
-
Release branches
-
Hotfix branches
这两个branch 的做法其实是差不多的,只是在不同的时间点做出来的
Feature branch 从develop 中拉出来,然后再merge 回develop 分支
Release branch 是从develop 分支拉长,准备给版本发布最终的稳定版本准备,可以从它拉出小的hotfix 版本,解决零时问,最后会同时merge 回master 和develop
Hotfix branch 从master 中拉出来,然后同时回到master 和develop 分支
注意问题
最终都会回归到develop 分支,但是在merge的过程中需要特征参数 --no-ff, 如下:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
和没有–no-ff 相比较的, --no-ff标志使合并始终创建一个新的提交对象
其实版本管理的精华还是在第一张图中,从这张图上可以看出所有的版本管理的端倪。