开发模型
定义一款合适自己公司的git开发模型很重要，规定所有开发人员的操作规范，约定处理流程，使得软件的开发流程更加清晰，更易于管理。
1、master 分支
master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性， master 分支一般由develop以及hotfix分支合并，任何时间都禁止直接使用master分支进行代码修改，也禁止直接将代码push到master分支。
2.hotfix 分支
- hotfix/ 开头的为修复分支，线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支。
3.release分支
- release 为预上线分支，发布提测阶段，会release分支代码为基准提测。
- 环境验收通过后，将版本发布生产环境，部署到生产环境后，将release分支代码merge到master分支，并打上tag或里程碑等标志
- 生产环境出现的bug，应该从release分支拉取hotfix分支进行修复，修复完成后，meger回release、master分支
- 禁止直接使用release分支进行代码修改，也禁止直接将代码push到release分支。
4.develop 分支
- develop 为开发分支，始终保持最新完成以及bug修复后的代码，一般开发的新功能时，feature分支都是基于develop分支下创建的。
- 不能随意将dev合并到其他主分支（dev分支可能包含进度不一致的代码或迭代不上线的代码）
分散但集中
在这个模型中，唯?的中?仓库, 命名为origin。
每个成员除了可以在中心查看origin推拉代码外，还可以从其他同行那里提取变化，组成子团队。如上图有Alice和Bob、Alice和David、Clair和David可以相互组成子团队。
Master分支
在中心仓库中存在两个无限寿命的分支：
- master 主分支
- develop 开发分支，平行于master分支
当源代码在develop分支中被开发完成，并准备发布时，所有的提交变更都应该被合并?master分支， 并使
?Tag?具标记?个版本号。
功能分支feature
当我们要开发一个新功能的时候，会基于develop分支创建一个本地分支feature-*，它最终会被合并到develop分支中，或者丢弃删除。
- 来源：develop
- 合并目标：develop
- 命名：feature-*
1.基于develop分支创建一个新功能分支：
$ git checkout -b feature-dzh develop
Switched to a new branch "feature-dzh"
2.将新功能分支合并到develop分支中：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff feature-dzh
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d feature-dzh
Deleted branch myfeature (was 05e9557).
$ git push origin develop
这个–no-ff标志使合并始终创建一个新的提交对象，即使合并可以使用快速转发来执行。这样可以避免丢失有关特性分支历史存在的信息，并且所有组一起提交一起添加的特性，比较：
在右侧图中，新功能分支中的所有提交，都被嵌?到了develop分支中，除了认真阅读提交的?志信
息，没法把他们分离出来。当我们试图回顾这个新功能分支中做了哪些改动时，将是个很?烦的事
情。如果–no-ff标记，则很容易解决。但它将创建更多(空的)提交对象，但收益要比成本大得多。
发布分支(Release branches)
- 发布分支release?于新版本发布前的准备?作，它允许我们在发布前，做最后?点点改动，包括少量
BUG的修改、元数据（如版本信息、编译参数等）的修改等。 - 来源：develop
- 合并目标：develop和master
- 命名：release-*
1.创建?个发布分支：
假设1.1.5是当前的生产版本，我们即将发布一个大版本。状态develop已经为“下一个版本”做好了准备，我们已经决定这将变成1.2版(而不是1.1.6或2.0)。因此，我们退出发行版，并给发布分支一个反映新版本号的名称：
$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)
在创建一个新分支并切换到它之后，我们增加版本号。这里,bump-version.sh是一个虚构的shell脚本，它更改工作副本中的一些文件以反映新版本。(当然，这可能是一次人工更改-重点是一些)文件更改。然后，提交新的版本号。
2.完成发布分支：
当一个发布分支已经准备好发布时，应首先将release分支合并到master分支（所有master分支的提交都代表一个新的发布工作），然后给master一个tag，以便未来对历史进行跟踪。最后将所有发布分支release上的提交都合并会develop分支，确保下一个发布工作中包括了所有的bug修复。
2.1 GIT的前两个步骤：
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
发行版现在已经完成，并为以后的参考做了标记。（最好使用-s或-u 以加密方式对标记进行签名的标志）
2.2 为了保持在发布分支中所做的更改，我们需要将它们合并回develop：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
这个步骤很可能导致合并冲突(甚至，因为我们已经更改了版本号)。如果是的话，修复它并提交。
2.3 现在我们真的完成了，发布分支可能会被移除，因为我们不再需要它了：
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).
紧急修复分支(Hotfix branches)
-
来源：master
-
合并目标：develop和master
-
命名：hotfix-*
紧急修复分支和发布分支相似，但它并不不是计划中的?作。它应?于?产环境中出现的紧急bug
修复。紧急修复分支基于线上运?行的Tag号签出，并以此为基础进?行修改。
这样，此处修复可以不不影响当前的开发?作（在develop分支中），专门抽取?个人力力来快速的
修复生产环境的问题。
1.创建?个紧急修复分支：
紧急修复分支基于master创建。比?来说，现在?产环境运?行的是1.2版本，不不幸的是，它发?了了?
个严重的bug。与此同时，我们的开发?作正在进?行中，还没有准备下?次发布。我们需要创建?个
紧急修复分支，来解决现在?产服务器?上发?的问题：
$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)
建立分支时，别忘了了声明新的版本号, 然后，并通过?两次代码提交?作，来完成bug的修复工作。
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
2.完成紧急修复分支：
当修复工作完成后，代码重新合并?master进?行发布。同时将其合并?develop分支，已确保在下
一次发布?作中正常的包含了了本次修复。合并?作与发布分支操作类似。
2.1 首先切换到master分支，合并，然后标记tag。
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1
2.2 然后，在develop中合并本次分支：
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1
您最好使用-s或-u 以加密方式对标记进行签名的标志。
2.3 接下来，在develop也是：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
特别说明: 如果此时已经创建了了?个发布分支，正准备下?次上线?作，则紧急修复分支应该被
合并至该发布分支，而不不是develop分支。紧急修复的代码将在发布分支完成时，经由发布分支合 并 至develop分支中(如果develop分支也需要立即使用这个紧急修复的代码，则也可以将紧急修复分支
同时合并在develop中）。
2.4 最后，删除临时分支：
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).
参考文献：https://nvie.com/posts/a-successful-git-branching-model/
一些开发规范
1.本公司开发规范
2.敏捷开发
