---

• 注意

1. 严禁所有人员在master节点和develop节点修改提交代码
2. master和develop节点只允许合并
3. master分支推送必须打上标签，并说明此次详细更改信息

各分支命名规范

1. hotfix：以当前master版本最后一位加1,开发完成后合并至master和develop分支， master主分支打标签
   如：master版本为V5.0.1,此时的hotfix分支版本为V5.0.2
2. feature：从develop分支创建，最后的版本号可自由定义，如1.0.0为当前功能的1.0.0版本
   a. 如：feature/wgz_liteflow_1.0.0
   b. 另一个同事开发的功能即为：feature/lnc_ordersBug_1.0.0
   c. 当feature分支合并至develop分支后，从develop分支拉出release分支，要求加版本号
3. release：当feature分支合并至develop分支后，拉出新的release分支进行测试，如果出现问题可以release分支进行bug修复，进到bug修复完成，经负责人确定上线后进行合并至master和develop节点，如果暂时不上线，可先合并至develop分支。
   a. 命名如：release/wgz_liteflow_V5.1.0

gitee基本开发流程及定义

gitflow工作流

gitflow工作流是一种依赖于Git版本管理工具，按特定规范对项目开发、测试、上线流程进行管理的工作方式。它是一种为实现规范化管理的约定，它明确了各个分支的意义，使整个团队的分工协作更加清晰。

gitflow工作流常用分支

1. 【master】
   ○ 主分支 , 产品的功能全部实现后 , 最终在master分支对外发布
   ○ 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 , 不能在此分支修改
   ○ 另外所有在master分支的推送应该打标签做记录,方便追溯
   ○ 例如release合并到master , 或hotfix合并到master
2. 【develop】
   ○ 主开发分支 , 基于master分支克隆
   ○ 包含所有要发布到下一个release的代码
   ○ 该分支为只读唯一分支 , 只能从其他分支合并
   ○ feature功能分支完成 , 合并到develop(不推送)
   ○ develop拉取release分支 , 提测
   ○ release/hotfix 分支上线完毕 , 合并到develop并推送
3. 【featrue】
   ○ 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发
   ○ 功能开发完毕后合到develop分支(未正式上线之前不推送到远程中央仓库!!!)
   ○ feature分支可同时存在多个 , 用于团队中多个功能同时开发 , 属于临时分支 , 功能完成后可选删除
4. 【release】
   ○ 测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆
   ○ 主要用于提交给测试人员进行功能测试 , 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag
   ○ 属于临时分支 , 功能上线后可选删除
5. 【hotfix】
   ○ 补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复
   ○ 修复完毕后合并到develop/master分支并推送 , 打Tag
   ○ 属于临时分支 , 补丁修复上线后可选删除
   ○ 所有hotfix分支的修改会进入到下一个release

主要工作流程

1. 初始化项目为gitflow , 默认创建master分支 , 然后从master拉取第一个develop分支
2. 从develop拉取feature分支进行编码开发(多个开发人员拉取多个feature同时进行并行开发 , 互不影响)
3. feature分支完成后 , 合并到develop(不推送 , feature功能完成还未提测 , 推送后会影响其他功能分支的开发)，【合并feature到develop , 可以选择删除当前feature , 也可以不删除 . 但当前feature就不可更改了 , 必须从release分支继续编码修改】
4. 从develop拉取release分支进行提测 , 提测过程中在release分支上修改BUG
5. release分支上线后 , 合并release分支到develop/master并推送，合并之后 , 可选删除当前release分支 , 若不删除 , 则当前release不可修改 . 线上有问题也必须从master拉取hotfix分支进行修改
6. 上线之后若发现线上BUG , 从master拉取hotfix进行BUG修改
7. hotfix通过测试上线后 , 合并hotfix分支到develop/master并推送，合并之后 , 可选删除当前hostfix , 若不删除 , 则当前hotfix不可修改 , 若补丁未修复 , 需要从master拉取新的hotfix继续修改
8. 当进行一个feature时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上【即合并develop到当前feature分支】
9. 当进行一个release分支时 , 若develop分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上， 即合并develop到当前release分支 (!!! 因为当前release分支通过测试后会发布到线上 , 如果不合并最新的develop分支 , 就会发生丢代码的情况)

命名规则

● master分支由项目架构、技术leader合并操作，任何人不可在此主分支开发。hotfix分支从master分支拉取
● develop分支由项目架构、技术leader、指定开发组长操作，只读，任何人不在此分支上开发。
● feature分支，由开发人员创建，多个分支，命名规则： feature/姓名_版本号_功能名称，开发人员每日都要从develop合并代码到自己的feature分支，开发完成后，再合并到develop。
● release待提测分支，从develop拉取release版本分支，命名规范：release/版本号，在此分支进行测试，bug修复，完成后打待上线tag，合并代码至develop，----->>>发布上线版本时再合并至master,打tag：规则为：版本号_上线日期_主要需求
● hotfix线上修复版本：从master拉取hotfix分支、命名规则： hotfix/版本号，修复完成，合并到develop和master
注：>>> 开发分支一旦合并至develop分支，即删除当前分支。

gitflow工作流程图

---

Git分支开发管理策略

主分支Master

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

开发分支Develop

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。

Git创建Develop分支的命令：

git checkout -b develop master

将Develop分支发布到Master分支的命令：

# 切换到Master分支　　
git checkout master　　
# 对Develop分支进行合并　　
git merge --no-ff develop

这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。

使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。

临时性分支

• 前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
  但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

• 功能（feature）分支
• 预发布（release）分支
• 修补bug（fixbug）分支

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。

功能分支

• 接下来，一个个来看这三种"临时性分支"。
  第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
  
  功能分支的名字，可以采用feature/开发人员名称_功能名_版本号的形式命名。如：feature/wgz_dictionary_1.1

创建一个功能分支：

git checkout -b feature/wgz_dictionary_1.1 develop

开发完成后，将功能分支合并到develop分支：

git checkout develop　　
git merge --no-ff feature/wgz_dictionary_1.1

删除feature分支：

git branch -d feature/wgz_dictionary_1.1

预发布分支

• 第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
  预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release/开发人员名称_功能名称_版本号称的形式。如：release/wgz_add-user_1.2

创建一个预发布分支：

git checkout -b release/wgz_add-user_1.2 develop

确认没有问题后，合并到master分支：

git checkout master　　
git merge --no-ff release/wgz_add-user_1.2　
# 对合并生成的新节点，做一个标签　　
git tag -a 1.2

再合并到develop分支：

git checkout develop　　
git merge --no-ff release/wgz_add-user_1.2

最后，删除预发布分支：

git branch -d release/wgz_add-user_1.2

修补bug分支

• 最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
  修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug/开发人员名称_bug_版本名称名称的形式。如：fixbug/wgz_add-user_1.1
  

创建一个修补bug分支：

git checkout -b fixbug/wgz_add-user_1.1 master

修补结束后，合并到master分支：

git checkout master　　
git merge --no-ff fixbug/wgz_add-user_1.1　　
git tag -a 0.1.1

再合并到develop分支：

git checkout develop　　
git merge --no-ff fixbug/wgz_add-user_1.1

最后，删除"修补bug分支"：

git branch -d fixbug/wgz_add-user_v1.1

---

git开发版本号命名规范

命名原则

1. 项目初版本时，版本号可以为 0.1.0；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1;
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1;

示例：

1. 主版本号改动：一期项目用0.1.0；二期项目用1.1.0；三期项目用2.1.0；
2. 子版本号改动：增加了权限管理功能模块，版本号由0.1.3改为0.2.0；
3. 修正版本号改动：修正了一个页面显示字符串，版本号由0.1.3改为0.1.4

---

git 全局设置用户名、密码、邮箱

• git config命令的–global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

查看git配置信息

git config --list

查看git用户名、密码、邮箱的配置

git config user.name
git config user.password

设置git用户名、密码、邮箱的配置

git config user.name “wugz”
git config user.password “123456”
git config user.email “1053295500@qq.com”

设置git全局用户名、密码、邮箱的配置（全局配置）

# git config --global user.name 用户命
git config --global user.name wugz
# git config --global user.password 密码
git config --global user.password abc0506abc
# git config --global user.password 邮箱
git config --global user.email “1053295500@qq.com”

修改git用户名、密码、邮箱的配置（跟设置语法一样，没有用户名就添加，有了用户名就修改）

git config user.name “wugz”

修改git用户名、密码、邮箱的配置（全局配置）

git config --global user.name “wugz” 

---

使用git-flow分支管理模型和Jenkins多分支流水线的应用

目前存在的问题

• 在开发过程中，团队中不同成员经常会同步开发不同的功能，可能会出现以下问题：

● 它们提交测试和部署到线上的时间往往不一样，如何清晰所属分支的职责？
● 不同功能可能会有相互依赖的代码，假设分属于不同的分支，如果其中一方想提交测试，必须先和另外一方合并，但另外一方还没到提交测试的时候，如果没有一个好的分支管理策略，就容易造成分支管理的混乱。
● 不同分支是否应该对应不同的环境，应该如何对应，jenkins 应该如何实现。

主分支

● master
● develop

• master 对应着生产环境的代码。
  develop 为开发分支，当 develop 的代码达到稳定点并准备发布时，需将其合并至 master，然后使用版本号标记该次合并。

临时分支

• 不同于主要分支，临时分支的生命周期有限，当使用完后需将其删除，临时分支可分为：

● feature
● release
● fixbug

• 这些分支中的每一个都有特定的用途，并受严格的规则约束，即哪些分支可能是其原始分支，哪些分支必须是其合并目标。

feature - 功能分支

• 从 develop 检出，必须合并回 develop。
  当开发某一功能时，从 develop 中检出 feature 分支，feature 分支在开发未完成时一直存在，直到开发完后合并到 develop，然后删除该分支。

创建订单功能分支：

git checkout -b feature/wgz_order_1.1 develop

完成订单功能后，切换到 develop，合并 feature-order:

# 切换到 develop
git checkout develop
# 合并
git merge --no-ff feature/wgz_order_1.1.0
# 删除 feature/wgz_order_1.1.0
git branch -d feature/wgz_order_1.1.0
# 推送 develop
git push origin develop

• 该–no-ff 标志使合并始终创建一个新的提交对象，即使合并可以通过快进来执行。这样可以避免丢失有关要素分支历史存在的信息，并将所有添加了要素的提交分组在一起。

release 预发布分支

• 从 develop 检出，必须合并到 develop 和 master。
  预发布分支通常用于在发布到测试环境的代码，出现问题直接在此版修复，待测试完成后，合并到 develop 和 master。
  创建 release 分支。从 develop 分支创建 release 分支。如当前 master 上的代码版本为 1.1.0，即将发布一个大版本，develop 已经准备就绪，创建一个带版本号的 release 分支：

# 创建 release/wgz_order_2.0.0 分支
git checkout -b release/wgz_order_2.0.0 develop

• release/wgz_order_2.0.0 分支会存在一段时间，直到它可以发布时。不能在此分支上面开发新的功能，要开发新的功能，应该在 develop 分支上检出新的 featrue 分支，或者在 feature/* 主功能分支上检出。
  可以发布时，将release/wgz_order_2.0.0 合并到 master，并标记该次提交，另外还需要将其合并到 develop，以同步在 release/wgz_order_2.0.0 上作的修改：

# 切换到 master
git checkout master
# 合并 release/wgz_order_2.0.0
git merge --no-ff release/wgz_order_2.0.0
# 标记版本号
git tag -a 2.0.0
# 切换到 develop
git checkout develop
# 合并
git merge --no-ff release/wgz_order_2.0.0
# 删除 release/wgz_order_2.0.0
git branch -d release/wgz_order_2.0.0

fixbug 修复 bug 分支

• 从 master检出，必须合并回 master、develop。
  如果在生产环境发现重大 bug，需要立即解决，可以创建 fixbug/wgz_order_2.0.1 分支，然后开始解决问题：

# 检出 fixbug/wgz_order_2.0.1
git checkout -b fixbug/wgz_order_2.0.1 master

• 完成修复后合并分支：

# 合并 master
git checkout master
git merge --no-ff fixbug/wgz_order_2.0.1
git tag -a 2.0.1
# 合并 develop
git checkout develop
git merge --no-ff fixbug/wgz_order_2.0.1
# 删除 hotfix-2.0.1
git branch -d fixbug/wgz_order_2.0.1

git-flow 使用

• 上面功能介绍的是如何使用 git-flow，发现操作过程还是有些繁琐的，其实业内存在一个库 gitflow，它是 git-flow 模型的具体实践。
  在它的 github README 中根据文档安装好 git-flow 和集成进 shell。- 查看 Installing git-flow & integration with your shell 小节
  安装好后执行 git flow init [-d] 初始化，然后将刚创建的本地分支都推送到远程 git push origin --all。

开发新功能

• 如要同步开发账单、订单等功能，先创建一个主功能分支，再创建副功能分支：

git flow feature start feature/wgz_1.0
git flow feature start feature/wgz_order_1.0
git flow feature start feature/wgz_bill_1.0

• 列出/开始/结束 feature 分支：

git flow feature
git flow feature start feature/wgz_1.0
git flow feature finish feature/wgz_1.0

• 开发完成后：

git flow feature finish feature/wgz_1.0

其它类型的分支类似。

git-flow 在 CI/CD 中的应用

• 假设接下来要开发版本为 v1.0.2，功能包含订单和财务模块，当前默认的分支只有 develop 和 master，首先创建 feature/wgz_order_1.0.2 和 feature/wgz_finance_1.0.2:

git flow feature start feature/wgz_order_1.0.2
git flow feature start feature/wgz_finance_1.0.2

# 推送到相应的 feature 分支
git flow feature publish feature/wgz_order_1.0.2
# 拉取相应的 feature 分支
git flow feature pull feature/wgz_order_1.0.2

• 当订单先开发完成，想先部署到测试环境给到测试人员，需执行以下步骤：

# 完成订单功能开发，自动合并到 develop 并删除 feature-order
git flow feature finish feature/wgz_order_1.0.2
# develop 中的订单功能准备就绪，检出预发布分支，推送时会触发 jenkins 的构建任务，
# 自动部署到测试环境
git flow release start release/wgz_order_1.0.2

• 在测试的过程中，需要修复问题，可以直接在 release/wgz_order_1.0.2 上修改，修改后提交会自动触发构建任务。当测试完没有问题时，这时候就需要部署到线上了，执行以下步骤：

# 合并到 master，删除 release/wgz_order_1.0.2
git flow release finish release/wgz_order_1.0.2

• 部署到线上环境后，遇到需要紧急修复的 bug 时，在 master 上检出 fixbug 分支，用于修复 bug：

# 检出 hotfix/wgz_order_1.0.2
git flow hotfix start fixbug/wgz_order_1.0.2
# 合并到 master
git flow hotfix finish fixbug/wgz_order_1.0.2