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标志使合并始终创建一个新的提交对象

其实版本管理的精华还是在第一张图中，从这张图上可以看出所有的版本管理的端倪。