git规范

开发模型

定义一款合适自己公司的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.敏捷开发