[工具] Git版本管理（三）（工作流）

一、冲突解决

Beyond Compare软件

下载BCompare软件，并安装。

删除安装目录下的BCUnrar.dll文件。

使用码：

w4G-in5u3SH75RoB3VZIX8htiZgw4ELilwvPcHAIQWfwfXv5n0IHDp5hv 1BM3+H1XygMtiE0-JBgacjE9tz33sIh542EmsGs1yg638UxVfmWqNLqu- Zw91XxNEiZF7DC7-iV1XbSfsgxI8Tvqr-ZMTxlGCJU+2YLveAc-YXs8ci RTtssts7leEbJ979H5v+G0sw-FwP9bjvE4GCJ8oj+jtlp7wFmpVdzovEh v5Vg3dMqhqTiQHKfmHjYbb0o5OUxq0jOWxg5NKim9dhCVF+avO6mDeRNc OYpl7BatIcd6tsiwdhHKRnyGshyVEjSgRCRY11IgyvdRPnbW8UOVULuTE

View Code

 

二、gitflow工作流

1.标准工作流

在实际的项目开发中，有一套规范的gitflow工作流。如下图所示：

 

注：A、B两个功能分别由两个开发者负责。而Leader来负责代码的Review以及合并。由测试组来进行专业测试。

流程解释：

1）从稳定版本V1中创建dev分支，用于全权管理新功能开发（由Leader管理）。

2）在dev分支的基础上创建A分支，用于开发A功能（分支名一般为功能名或负责人名）。

3）在dev分支的基础上创建B分支，用于开发B功能。

4）A功能开发完毕后，由Leader进行code review，通过后合并到dev分支（D1合并A3），版本为D2。

5）从D2上创建一个Release分支（预发布分支），用于测试组进行测试。版本为R1。

6）R1测试发现BUG，进行修改，提交为R2。

7）R2测试通过后，认为可以上线，则与正式版V1合并，生成正式版V2。

8）由于R2是修改BUG之后的版本，这说明D2也存在相同BUG，所以D2和并R2，修复BUG，生成D3。

9）B功能开发完毕后，由Leader进行code review，通过后合并到dev分支（D3合并B5），版本为D4。

10）从D4上创建Release分支（预发布分支），用于测试组进行测试。版本为R1。

11）R1测试发现BUG，进行修改，提交为R2。

12）R2测试通过后，认为可以上线，则与正式版V2合并，生成正式版V3。

13）由于R2是修改BUF之后的版本，则说明D4页存在相同的BUG，所以D4合并R2，修改BUG，生成D5。

 

通过上述流程，V1、V2、V3分别代表三个正式版本。而dev分支中的版本也是以功能为单位的迭代。

当某个功能开发完毕（例如A分支），并且已经合并到正式版以后，则我们可以将A分支删除。

 

2.简化工作流（不推荐）

在很多中小型公司中，工作流可以不会像上述流程那么复杂。可能会忽略一些步骤：

1）忽略Release分支，不单独在Release分支中测试和修改BUG。而是直接在dev分支中测试和修改bug。

2）忽略Code Review，很多公司的开发者功能开发完毕后，进行自测，自测完后就直接上线（不推荐，隐患很大）。

 

三、实现标准gitflow工作流

1.创建项目

项目名：leeoo

文件夹名：leeoo

git初始化：

git init

提交第一个版本：

touch base.py
git add .
git commit -m "V1 基础版本"

 

2.创建远程仓库

在github上创建leeoo仓库：

https://github.com/leokale/leeoo.git

 

3.邀请其他开发者（个人项目）

当我们开发个人项目时，可以在github上邀请其他人一起来进行项目开发。

进入仓库的setting：

 

输入想要要求的人，然后发起邀请：

被邀请的人会收到一封邮件，如果同意的话就加入了该项目的开发。

 

4.使用组织来开发项目

在公司中，一般会自己搭建gitlab或者使用github上的组织来进行协同开发。

在github中创建一个组织：

 

这里选择免费的开源项目类型：

 

然后，我们可以邀请成员，也可以跳过，以后需要的时候再邀请：

 

创建好组织后，可以看到以下组织信息：

此时，我们就可以在该组织中创建仓库了：

 

 

创建好仓库后，可以看到仓库信息：

 

此时，我们就可以将代码推送到这个仓库地址了。

 

 

5.将V1提交到组织中的仓库

使用命令：

git remote add origin "https://github.com/leeoo-org/leeoo.git"
git push -u origin master

可以看到仓库中已经存在master分支：

 

6.为版本打标签（Tag）

我们在之前都是以提交版本的hash值来区分每个版本。但是hash值很长，不易区分。

我们可以使用命令给其打上一个标签（代表这个版本的hash id），该标签就可以用来直观的操作对应版本。

使用命令：

# 在master分支执行

git tag -a v1 -m "第一版"

该命令会在我们的本地，为master分支中的版本打上标签：

将Tag也推送到远程仓库：

git push origin --tags

在github上可以看到这个Tag：

 

在Release页签中也可以看到版本的信息：

 

7.创建dev分支

执行命令：

git checkout -b dev

相当于：

git branch dev
git checkout dev

 

推送dev分支到仓库：

git push origin dev

在github仓库中可以看到dev分支：

 

 

8.邀请合作开发者（开发员工）

首先开发员工都需要注册github账号（gitlab和码云等平台也是一样）。

进入github组织管理页面，并进入People页面：

 

邀请成员（Invite member）：

 

输入要邀请人员的名称：

 

选择角色：

发送邀请后，被邀请者会收到邮件，点击邮件中的同意加入则可以加入组织。

 

9.组织成员的权限

邀请了成员以后，我们要对其权限进行设置。

查看组织成员权限：

 

 

10.项目权限

进入项目（仓库）的setting：

 

添加开发者，并设置好write权限后，开发者就可以对该仓库里的代码进行push、pull等操作了。

 

11.开发者A开发功能

开发者A克隆代码到自己的本地：

git clone "https://github.com/leeoo-org/leeoo.git"

切换到dev分支，并创建A分支：

git checkout dev
git checkout -b A  # 创建分支A，并切换到A

在A分支下开发A功能：

touch a50.py
git add . 
git commit -m "A功能开发50%" 

touch a100.py  # 开发完毕
git add .
git commit -m "A功能开发100%"

提交A分支到远程仓库：

git push origin A

在github中查看提交的代码：

 

 

12.Code Review配置

要进行Code Review，首先要进行配置。

进入仓库的setting：

 

 选择Add rule添加一条规则：

 

这样配置完毕后，开发者A想将A分支合并到dev之前，就需要申请Pull request review。

 

13.Pull request view申请

开发者A申请Pull request view：

 

点击New pull request：

 

选择将A分支合并到dev分支，并填写申请的信息，包含标题和描述。然后点击Create pull request提交申请。

 

14.Leader进行Code review

在Pull request页签中查看review申请：

如果账号有权限进行review，则会在Review required那一栏出现 "Add your review" 链接：

 

15.执行合并

Code review完毕后，点击Merge pull request执行合并：

 

在合并完成后，可以选择删除A分支（可删可不删，看需求）：

查看合并后的dev分支：

 

可以看到，代码合并成功。

 

16.Leader从仓库同步dev代码

github上已经将A分支合并到了dev分支，那么Leader也应该同步自己本地的dev分支：

git pull origin dev

 

查看本地dev分支：

git checkout dev
git log

 

17.进行测试（dev<---release）

在dev合并了A功能以后，我们要提交测试组进行测试。

在dev的基础上创建一个release分支：

git checkout -b release

将release分支推送给仓库：

git push origin release

 

release分支推送到仓库之后，测试组人员可以克隆代码，并对release分支的代码进行测试。

 

 

测试完毕后，测试人员可以申请Pull request review：

 

申请将release分支合并到master分支中（如果需要review的话，master分支也要配置规则）。

负责人同意合并：

 

如果在release测试过程中进行了bug修复，则需要将release合并回dev中：

git checkout dev
git merge release

合并完后，删除release分支（如果在测试阶段进行了bug修复，则还需要将release分支合并回dev分支）：

 

或者使用命令：

git branch -d release

 

 

18.将master同步回本地

执行命令：

git pull origin master

 

为其添加Tag：

git tag -a v2 -m "第二版 增加A功能"

推送tag到仓库：

git push origin --tags

 

19.运维人员做上线

运维人员可以去下载代码做上线了。

git clone -b v2 "https://github.com/leeoo-org/leeoo.git"

 

 

666.