2018 March 23 Git

引入git flow分支管理

声明: 这篇博客是完全copy这位大牛的,目的是为了自己能够随时查阅使用

阅读目录

两种核心分支
三种临时分支
Git Flow流程示例代码
Git Flow工具
分支命名规范
总结

简介

git flow是Vincent Driessen提出了一个分支管理的策略，非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。
先看下Vincent Driessen提出的分支管理模型图，以便对git flow有个大概的了解。

分析图片

单词翻译:

 master branches ： 主分支
 hotfixes branches： 热补丁分支
 release branches ： 发布分支
 develop branches： 开发分支
 feature branches： 特性分支
 severe bug fixed for productions: 修复生产环境的严重bug
 incorporate bugfix in develop：合并热修复分支到开发分支
 major feature for for next release： 创建一个特征分支对于下一个版本
 feature for future next release： 为未来的下一个版本提供特性分支
 start for release branch for 1.0 ： 开始发布分支1.0 
 Only bugfixes： 仅仅修复bug
 bugfixes from release branch may  be continuously merged back  into develop： 在发布分支可能有很多的bug需要修复，而且会相应很多次合并到开发分支中
 from this point on，“next release” means the release offer 1.0： 从这个点开始，就意味着要提供下一个发布版本1.0 

图片分析：

 1. 开始是一个主分支maser
 2. 拉取一个开分支develop，优化、修改等
 3. 一旦线上版本有了紧急bug，拉取一个热补丁分支（hotfix），解决bug
     1. 合并到主分支master
     2. 打一个tag
     3. 合并到开发分支develop
     4. 删除hotfix分支
 4. 一旦有了新的需求
     1. 从开发分支拉取一个feature特征分支
     2. 需求做完，合并到开发分支develop，然后删除feature分支
     3. 从develop拉取一个发布分支release，用于修改测试测出来的bug
     4. 在release修改bug的同时，每次提交要相应的合并到develop分支
     5. 关键点： 此时如果又有新的需求怎么办？ （正在修第一个需求的bug，还未发布，新需求又来了）    
         1. 先要将release分支合并到develop分支
         2. 然后再从develop分支拉取一个feature分支（之前的那个feature分支早删除了）
         3. 在新的feature分支进行新需求的开发
     6. release分支测试通过
         1. 合并到分支master
         2. 打一个tag
         3. 合并到开发分支develop
         4. 删除release分支

两种核心分支

主分支(Master)：代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。这个分支只能从其它分支合并，不能在这个分支上直接修改。需要注意的是，所有在master上的提交应该标记tag。

开发主分支(Develop)：这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支。该分支应该只是进行一些优化和升级开发，如果有新的需求应该拉出一个feature分支。

三种临时分支

功能(feature)分支：这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release。

预发布(release)分支：当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支。

修补bug(hotfix)分支：当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release。

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

Git Flow流程示例代码

1，创建develop分支

#从master拉出develop分支

#可选，获取最新版本。git pull origin master

git checkout -b develop master

#发布develop分支

git push -u origin develop

2，创建feature分支

#从develop拉出feature_v1.0功能分支

#可选，获取最新版本。git pull origin develop

git checkout -b feature_v1.0 develop

#发布feature_v1.0分支

git push -u origin feature_v1.0

#在feature_v1.0上开发一些功能

3，完成feature，合并到develop分支

#develop分支获取最新

git pull origin develop

#切换到develop分支

git checkout develop

#从feature分支合并到develop分支

git merge --no-ff feature_v1.0

#删除feature分支，也可以不删除

git branch -d feature_v1.0

4，开始release

#从develop拉出一个release分支

#可选，获取最新版本。git pull origin develop

git checkout -b release_v1.0 develop

#fix bugs

5，完成release，合并到master分支和develop分支，在master打上tag标记

#合并到master

git checkout master

git merge --no-ff release_v1.0

#在master打tag标记

git tag release1.0 master

git push --tags

#合并到develop

git checkout develop

git merge --no-ff release_v1.0

6，开始hotfix

#从主线master拉出一个hotfix分支

#可选，获取最新版本。git pull origin master

git checkout -b hotfix_v1.0.1 master

7，完成hotfix，合并到master和develop，并在master上打tag。

#合并hotfix_v1.0.1到master

git checkout master

git merge --no-ff hotfix_v1.0.1

#在master打上tag

git tag hotfix1.0.1 master

git push --tags

#合并hotfix_v1.0.1到develop

git checkout develop

git merge --no-ff hotfix_v1.0.1

Git Flow工具

SourceTree
GitFlow for Visual Studio

分支命名规范

feature分支：以”feature_“开头，如feature_v1.1
release分支：以”release_“开头，如release_v1.1
hotfix分支：以”hotfix_“开头，如hotfix_20160112
tag标记：如果是release分支合并，则以"release_"开头。如果是hotfix分支合并，则以”hotfix_“开头。
master分支每次提交都要打tag，release tag：如release_v1.1，hotfix tag：如hotfix_20160112
命名都统一采用小写。

总结

一定要按git flow的流程去管理分支，如feature分支开发完要合并到develop，如果要发布版本到test环境，则从develop拉出一个release分支，release完成后要合并回master和develop分支，修复生产环境问题需要从master拉出一个hotfix分支，hotfix完成后要合并回master和develop分支，并且在master打上tag。
一定要按分支命名规范来命名，便于管理和维护。
了解了git flow工作流程后，可以不使用git flow GUI工具，手动操作即可，可以是原生git命令+vs配合操作，比如给master打tag就要用git命令，这在vs里操作不了的，比如合并分支，虽然也可以使用git命令实现，但在vs里操作更方便直观
一定要保持分支的纯净，不要随便污染分支。比如，develop分支只包含要发布到下一个release的代码，在没有拉出release分支前不要合并新的feature分支进来。release分支基于develop分支创建，拉出release分支后，我们可以在这个release分支上测试和修复bug，但是，一旦打了release分支后不要从develop分支合并新的改动过来。develop拉出release分支的同时，也意味着develop分支可以开始下一个release的准备工作了。
如果多个版本并行到test环境，怎么解决这个问题？如下图。