[工具] 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.

原文地址:https://www.cnblogs.com/leokale-zz/p/12127675.html