文章目录

• 各分支命名规范
• gitee基本开发流程及定义
• • gitflow工作流
  • gitflow工作流常用分支
  • 主要工作流程
  • 命名规则
  • gitflow工作流程图
• Git分支开发管理策略
• • 主分支Master
  • 开发分支Develop
  • • Git创建Develop分支的命令：
    • 将Develop分支发布到Master分支的命令：
  • 临时性分支
  • 功能分支
  • • 创建一个功能分支：
    • 开发完成后，将功能分支合并到develop分支：
    • 删除feature分支：
  • 预发布分支
  • • 创建一个预发布分支：
    • 确认没有问题后，合并到master分支：
    • 再合并到develop分支：
    • 最后，删除预发布分支：
  • 修补bug分支
  • • 创建一个修补bug分支：
    • 修补结束后，合并到master分支：
    • 再合并到develop分支：
    • 最后，删除"修补bug分支"：
• git开发版本号命名规范
• • 命名原则
  • 示例：
• git 全局设置用户名、密码、邮箱
• • 查看git配置信息
  • 查看git用户名、密码、邮箱的配置
  • 设置git用户名、密码、邮箱的配置
  • 设置git全局用户名、密码、邮箱的配置（全局配置）
  • 修改git用户名、密码、邮箱的配置（跟设置语法一样，没有用户名就添加，有了用户名就修改）
  • 修改git用户名、密码、邮箱的配置（全局配置）
• 使用git-flow分支管理模型和Jenkins多分支流水线的应用
• • 目前存在的问题
  • 主分支
  • 临时分支
  • • feature - 功能分支
    • • 创建订单功能分支：
      • 完成订单功能后，切换到 develop，合并 feature-order:
    • release 预发布分支
    • fixbug 修复 bug 分支
  • git-flow 使用
  • • 开发新功能
  • git-flow 在 CI/CD 中的应用

• 注意

各分支命名规范

gitee基本开发流程及定义

gitflow工作流

gitflow工作流常用分支

主要工作流程

命名规则

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。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
  但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：

这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有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开发版本号命名规范

命名原则

示例：

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多分支流水线的应用

目前存在的问题

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

主分支

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

临时分支

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

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

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