diff --git "a/git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203/Git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203.md" "b/git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203/Git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203.md"
index e788dba8e3a0fa779b9c5c67faeff3098ff5bd3f..d4625e29705ad93626e79167cc81f76d32366093 100644
--- "a/git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203/Git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203.md"
+++ "b/git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203/Git\345\274\200\345\217\221\346\265\201\347\250\213\350\247\204\350\214\203.md"
@@ -51,7 +51,7 @@ Gitlab与GitHub一样，是一个用于仓库管理系统的项目，使用Git
 - 业务模块进行分模块开发，人员之间的业务交叠不大
 - 产品一般在功能全部具备时才发布现场使用
 
-对于产品研发类项目采用Github Flow这种面向开源项目的工作流太过简单，Trunk-Based Development这种非feature分支开发方式不利于任务分配和跟踪，Git Flow这种面向版本的流程虽然满足需要但是太过复杂。而且个人以为这些流程大多都是面向互联网项目的最佳实践。综合分析最终选择Gitlab flow的Production branch with GitLab flow方式，并结合任务管理，持续集成形成满足我们当前需要的产品研发工作流。
+对于产品研发类项目采用Github Flow这种面向开源项目的工作流太过简单，Trunk-Based Development这种非feature分支开发方式不利于任务分配和跟踪，Git Flow这种面向版本的流程虽然满足需要但是太过复杂。而且个人以为这些流程大多都是面向互联网项目的最佳实践。综合分析最终选择Gitlab flow的releaseion branch with GitLab flow方式，并结合任务管理，持续集成形成满足我们当前需要的产品研发工作流。
 
 GitLab工作流十分年轻，2014 年 9月 29 正式发布。由于出现比Git FLow和GitHub FLow晚，因此它集百家之长，补百家之短。GitLab 既支持 Git Flow 的分支策略，也有类似 GitHub Flow 的 Pull Request和 issue tracking，这些对于产品研发类项目都是极好的能力
 
@@ -61,15 +61,15 @@ GitLab工作流十分年轻，2014 年 9月 29 正式发布。由于出现比Git
 
  以下为完整的git开发流程![](https://i.loli.net/2019/02/07/5c5c32ce8cda2.jpg)
 
-1.  在gitlab创建仓库，创建master分支和product分支，master分支初始代码为开发需要的框架代码
+1.  在gitlab创建仓库，创建master分支和release分支，master分支初始代码为开发需要的框架代码
 2.  需求分解，获得feature，粒度3天，使用gitlab的issue对feature进行管理，标记feature标签，命名以Feature_简单描述
 3.  feature开发时从master分支拉feature分支进行开发，开发完成后，本地完成测试，确保代码无误后，提交Merge request
 4.  在进行代码审核通过后，feature分支合并到master分支，触发持续集成（自动编译，代码静态检查，单元测试），成功后发布到持续集成开发环境，删除feature分支
 5.  创建每日集成，每日定时将master分支代码进行自动化集成，完成后发布到每日集成开发环境
 6.  待一个里程碑feature开发完成后，发起里程碑计划，手动触发集成部署到测试环境
 7.  测试环境产生的bug录入fixbug issue在issue进行管理，开发人员从master分支拉取fixbug分支进行bug修复（过程类似feature branch）
-8.  当里程碑测试完成后，product分支与master分支进行merge，在product上产生里程碑版本，并tag为milestone_vx.x
-9.  以上过程随里程碑不断迭代推进，直到产品全部完成， product上将产生最后的产品发布版本
+8.  当里程碑测试完成后，release分支与master分支进行merge，在release上产生里程碑版本，并tag为milestone_vx.x
+9.  以上过程随里程碑不断迭代推进，直到产品全部完成， release上将产生最后的产品发布版本
 
 ### 基本准则
 
@@ -107,7 +107,7 @@ GitLab工作流十分年轻，2014 年 9月 29 正式发布。由于出现比Git
 6. **依赖tags版本进行发布**
 
 ```
-Milestone里程碑版本测试完成后，将Product分支与Master分支Merge，并通过tag（Milestone_vX.X），基于Product分支发布里程碑版本，Product分支就是里程碑版本分支，永远记录当前最新里程碑版本的内容，记住不要直接对其进行任何操作，除了Merge,tag
+Milestone里程碑版本测试完成后，将release分支与Master分支Merge，并通过tag（Milestone_vX.X），基于release分支发布里程碑版本，release分支就是里程碑版本分支，永远记录当前最新里程碑版本的内容，记住不要直接对其进行任何操作，除了Merge,tag
 ```
 
 7. **绝不以重置方式提交变更**
@@ -165,9 +165,9 @@ feature分支和fixbug分支合并master分支时，需要在本地先merge再
 
 ### 分支管理
 
-完整流程中包括master分支，product分支，feature分支，fixbug分支，其中master和product分支是长周期分支，feature和fixbug分支是短分支，在完成合并后删除。
+完整流程中包括master分支，release分支，feature分支，fixbug分支，其中master和release分支是长周期分支，feature和fixbug分支是短分支，在完成合并后删除。
 
-- product分支保存最新可用的里程碑版本，直至最终的产品发布版本，product分支不允许直接修改
+- release分支保存最新可用的里程碑版本，直至最终的产品发布版本，release分支不允许直接修改
 - 开发均在master分支，master分支是所有开发的起点，包括拉feature分支，fixbug分支也是源于master分支
 - feature分支，fixbug分支开发完成必须在本地测试通过，以及在本地完成merge后再提交到master分支merge
 
@@ -184,7 +184,7 @@ feature分支和fixbug分支合并master分支时，需要在本地先merge再
 
 
 
-例如： product 1.10.1.20190215_release
+例如： release 1.10.1.20190215_release
 
 ```
 Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。