Git开发发布缺陷分离模型概述（支持master/develop/feature/release/hotfix类型分支）

Posted 2023-05-15 追逐时光者

Git是什么？

　　Git是一种分布式版本控制系统，它可以记录文件的修改历史和版本变化，并可以支持多人协同开发。Git最初是由Linux开发者Linus Torvalds创建的，它具有高效、灵活、稳定等优点，如今已成为软件开发领域中最流行的版本控制系统之一。Git使用一种名为“仓库”的数据结构来保存代码和它们的变更历史。每个开发人员都可以在本地拥有自己的仓库，并将其与其他人的仓库同步更新。除此之外，Git还提供了强大的分支和合并功能，可以让开发人员在不影响主干的情况下创建和测试新功能。

Git有什么作用？

　　Git的使用范围非常广泛，它不仅可以用于软件开发，还可以应用于任何需要版本控制的项目。当团队存在多人协作开发时，Git可以提高开发效率，减少代码冲突[这个是Git作为分布式版本控制系统一个优势之一，可以避免开发环境产生冲突而导致代码丢失的情况]，同时也可以方便项目管理和维护。

CVS、SVN代码冲突和Git代码冲突哪个更好优势在哪？

• 在CVS、SVN集中式的代码管理工具中，发生冲突时需要首先将文件lock住，即文件锁定，以保证只有一个人在修改该文件，避免多人同时修改导致文件冲突。但是这种方式会影响开发效率，并且无法支持离线工作模式。
• Git分布式管理工具中，由于本地仓库不依赖于中央服务器，因此可以在没有网络连接的情况下继续工作，这也是Git的优势之一。发生冲突时，每个人都可以在本地仓库中解决冲突，然后将结果推送到中央服务器上。Git还可以使用合并和分支功能，使多人协作开发更加容易。另外，Git的分布式结构意味着它具有更高的灵活性和可靠性，可以保证数据的完整性和安全性。同时，Git也支持大规模开发和复杂项目的管理。

Git开发、发布、缺陷分离模型介绍

　　在一些流程完善的公司往往都会有着自己一套比较完善的Git分支管理模型来保障开发和生成环境的代码稳定性，而Git开发、发布、缺陷分离模型是一种流行且适用于大多数团队的Git分支管理模型，它支持master/develop/feature/release/hotfix类型分支。使用这种分支管理模型可以有效地隔离开发、发布和缺陷修复工作，提高代码的质量和稳定性。同时，也可以更好地协作和进行版本管理。如下是一张详细的master/develop/feature/release/hotfix类型分支管理图：

 

master/develop/feature/release/hotfix每个分支的作用

master分支

master分支是主分支，包含了已经发布到生产环境的稳定，可靠版本的代码。一般情况下，master分支应该只用于发布新版本，而不应该直接修改或提交新的功能。

创建流程：

1. 所有的发布代码都在master分支上合并完成。
2. 当develop分支上的所有功能都经过测试并处于可发布状态时，将develop创建的对应测试通过的release-v1.0分支合并到master分支上生成一个新的发布版本。

develop分支

develop分支是开发分支，包含了当前正在进行的所有功能和任务。所有新功能开发、改进、优化等都应该从此分支开始，并最终合并回此分支。

创建流程：

1. 所有的新的功能开发、改进、优化等都在develop分支上完成。
2. 当某个功能被完成并且经过测试后，在一个独立的feature分支上进行开发的功能会被合并回develop分支。

feature分支

feature分支是从develop分支创建的分支，通常用于开发新功能。每个新功能都应该从develop分支开始，并在一个独立的feature分支上进行开发工作。一旦新功能得到完全实现、测试并且可靠，该分支就会被合并回develop分支。

创建流程：

1. 从develop分支上创建一个新的feature分支。
2. 在此分支上进行新功能的开发工作。
3. 当新功能得到完全实现、测试并且可靠时，将其合并回develop分支。

release分支

release分支是从develop分支创建的分支，通常用于为即将发布的版本做准备工作。在此分支上可以进行最终的测试、修复bug、检查文档等操作，以确保发布版本的质量。一旦准备工作完成并且得到完全测试，该分支就会被合并回master分支，并作为新的发布版本。并将该分支合并回develop分支，以便后续的开发工作。

创建流程：

1. 从develop分支上创建一个新的release分支。
2. 在此分支上进行最后的测试、修复bug和更新文档等操作。
3. 将该分支合并回master分支作为新的发布版本。
4. 将该分支合并回develop分支，以便后续的开发工作。

hotfix分支

hotfix分支是从master分支创建的分支，用于在生产环境中紧急修复问题。修复完毕后，该分支将会被合并回master和develop分支。

创建流程：

1. 从master分支上创建一个新的hotfix分支。
2. 在此分支上进行必要的修改和测试。
3. 将该分支合并回master分支以修复问题。
4. 将该分支合并回develop分支以确保将来新版正常工作。

Git可视化管理源代码详细教程

• 最全面SourceTree使用教程详解

  Git 分支模型与开发规范

  01、分支模型

  

  • master：长期分支，一般用于管理对外发布版本，每个 commit 对一个 tag，也就是一个发布版本
  • develop：长期分支，一般用于作为日常开发汇总，即开发版的代码
  • feature： 短期分支，一般用于一个新功能的开发
  • hotfix ：短期分支 ，一般用于正式发布以后，出现 bug，需要创建一个分支，进行 bug 修补。
  • release ：短期分支，一般用于发布正式版本之前（即合并到 master 分支之前），需要有的预发布的版本进行测试。

  master和develop作为主要分支。

  新功能的开发在feature上进行，该分支从develop分支派生，功能开发完毕后merge到develop分支。 一般feature分支都存在与开发者本地，除非该分支需要多方合作才提交到远程仓库。

  如何保证和develop分支的代码同步？每天从develop分支拉去最新的代码，使用rebase命令 不要使用pull，每次合并上游更改时feature 分支都会引入一个外来的合并提交，使用pull会生成一个新的合并commit。

  在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，可以考虑用 git rebase 来代替 git merge；反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支，就不要采用 git rebase 了，避免出现重复的冲突和提交节点。

  release分支是从develop分支派生, bug fix只在release分支上进行，该分支也是QA的测试分支，开发结束后同时合并进develop和master分支

  使用merge request将release分支的提交合并master分支，并打上tag。

  hotfix可以单独出一个分支，也可以直接在release分支上进行。

  所有master上的代码都是从release分支合并进去的。

  追踪远程develop分支

  git checkout -b develop origin/develop

   

  feature 分支操作

  获取dev分支最新代码

  $ git pull --rebase origin dev
  或者
  $ git rebase dev
  
  $ git checkout -b myfeature develop
  
  $ 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

   

  rebase最大的好处是你的项目历史会非常整洁。首先，它不像git merge 那样引入不必要的合并提交。其次，如上图所示，rebase导致最后的项目历史呈现出完美的线性——你可以从项目终点到起点浏览而不需要任何的Fork。这让你更容易使用git log 、git bisect 和gitk 来查看项目历史。 不过，这种简单的提交历史会带来两个后果：安全性和可跟踪性。如果你违反了Rebase黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响。此外，rebase不会有合并提交中附带的信息——你看不到feature分支中并入了上游的哪些更改。

  rebase的黄金法则
  git rebase 的黄金法则便是，绝不要在公共的分支上使用它。 比如说，如果你把master分支rebase到你的feature分支上会发生什么

  release 分支操作

  # 合并到master
  $ 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
  
  # 合并到develop
  $ git checkout develop
  Switched to branch ‘develop‘
  $ git merge --no-ff release-1.2
  
  # 删除release分支
  $ git branch -d release-1.2

   

  hotfix 分支操作

  当产品发布出去之后，有紧急的bug，就需要从master分支中拉出一个hot fix分支。 这么做的好处是develop分支上的同事可以继续进行开发，另一个团队则可以在master分支上进行一个产品修复更新。 修复好之后，合并到mater分支和develop分支。

  这里有一个特殊情况，如果当时的release分支还存在，那么hotfix的更新需要merge到相应的release分支上。 如果release分支已经不存在了，那么就只需要merge到master分支和develop分支。

  创建远程分支

  git push origin local_branch:remote_branch
  local_branch必须为你本地存在的分支，remote_branch为远程分支，如果remote_branch不存在则会自动创建分支。

   

  02、开发规范

  commit规范

  只要坚持做到以下几点就 OK 了：

  1. 提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；
  2. 用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方；
  3. 不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。

  谁说历史不可篡改了？前提是，想要合并的那几次提交还没有推送到远程！

  Commit Message 格式

  <type>(<scope>): <subject>
  <空行>
  <body>
  <空行>
  <footer>

  type

  • feat：新功能（feature）
  • fix：修补bug
  • docs：文档（documentation）
  • style： 格式（不影响代码运行的变动）
  • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
  • test：增加测试
  • chore：构建过程或辅助工具的变动

  Scope
  用来说明本次Commit影响的范围，即简要说明修改会涉及的部分。这个本来是选填项，但从AngularJS实际项目中可以看出基本上也成了必填项了。

  Subject

  用来简要描述本次改动，概述就好了，因为后面还会在Body里给出具体信息。并且最好遵循下面三条:

  • 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
  • 首字母不要大写
  • 结尾不用句号(.)

  Body

  <body>里的内容是对上面subject里内容的展开，在此做更加详尽的描述，内容里应该包含修改动机和修改前后的对比。

  Footer

  footer里的主要放置不兼容变更和Issue关闭的信息

  Revert

  此外如果需要撤销之前的Commit，那么本次Commit Message中必须以revert：开头，后面紧跟前面描述的Header部分，格式不变。并且，Body部分的格式也是固定的，必须要记录撤销前Commit的SHA值。

  03、链接

  • A successful Git branching model-重要
  • 团队中的 Git 实践
  • Git: 教你如何在Commit时有话可说
  • Git Flow

  以上是关于Git开发发布缺陷分离模型概述（支持master/develop/feature/release/hotfix类型分支）的主要内容，如果未能解决你的问题，请参考以下文章

  core部署

  Git分支模型分析

  和Leon一起从头学Git

  软件测试常见概念（软件生命周期软件开发模型软件质量模型软件缺陷管理软件测试概述软件测试分类软件测试与软件开发软件测试原则黑盒测试方法白盒测试方法性能测试）

  软件测试常见概念（软件生命周期软件开发模型软件质量模型软件缺陷管理软件测试概述软件测试分类软件测试与软件开发软件测试原则黑盒测试方法白盒测试方法性能测试）

  Git 分支模型与开发规范