gitlab使用

开发操作指引

安装 Git

Windows 系统，从http://msysgit.github.io/下载，然后按默认选项安装即可。

生成 SSH KEY

使用下面的命令，列出电脑上已有的 SSH KEY

ls -al ~/.ssh

使用下面的命令，一直按回车键，生成 SSH KEY

ssh-keygen-t rsa

上图中在生成 KEY时，显示在目录” C:/User/cyj/.ssh/ “下新增了两个文件(idrsa , idrsa.pub)，这两个文件分别为私匙和公匙。

登录Gitlab

打开浏览器输入地址：http://***/users/sign_in

用域账号登录

添加 SSH KEY 到 GitLab

在 “个人资料设置”中找到 “ADD SSH Keys”的页面，页面如下：

点击 ADD SSH Keys，并将上一步中的 id_rsa.pub文件使用记事本打开，复制所有内容。将复制的内容粘贴在当前网页，如下图：

点击 ADD KEY添加成功。

现在进行连接测试，使用下面的命令，填入“yes”,如果测试通过将显示 ” Welcome to Gitlab “。

ssh-T git@172.18.220.56

Clone 项目到本地

打开一个在 GitLab上的项目，复制项目的 Git链接

在命令行中执行以下命令，等待片刻，即可完成项目的Clone

提交代码

为了保证代码不丢失，当你觉得完成一小部分功能后一定要及时提交代码。

提交代码请按照下述流程操作：

1.    show diff

o    show diff这个操作是为了提交之前仔细检查代码，防止注释掉重要的代码。

2.    commit

o    commit操作是将变动提交到本地的 Git库；

3.    push

o    push操作是将本地未提交到远程 Git代码库的 commit提交到远程Git 代码库里；

补充说明

有关创建，修改仓库属性等操作建议在 GitLab网页版进行，而进行文件上传，删除，代码更新等操作建议使用本地的命令行或客户端。

二．管理员操作

1.新建仓库

点击界面右上角的+ 按钮，新建项目

并输入此工程的名字，介绍。

进入工程后，点击右上角的设置按钮，并设置可以参加此工程的成员(Members)。

根据工程下方的提示，在本机上新建本地仓库。其中 <URL> 是此工程的地址，可以在工程界面上找到。

2.基于Development分支创建Feature分支

 

打开项目首页，按下图所示进行两步操作。

进入创建分支界面，按图示输入框提示填写Feature分支名称和基于的Development分支。

填完后的图示

点击CREATE BRANCH按钮完成操作。clone远程库或在已有的本地代码库中执行pull操作即可以将新创建的Feature分支同步到本地，检出该分支后就可以开始功能开发。

三．Git 建立分支流程介绍

分支模式

以下两种模式作为不同开发的工作模式的选择：

Ø  主干开发

开发人员只在主分支上提交代码，每天至少提交一次。

Ø  Release分支

每次发布都基于上一个分支创建分支，允许创建次分支，但是必须尽快合并回release分支。

Ø  Feature/Hotfix分支

保留功能分支，每次发布后都要合并到master分支，确保主分支为可发布状态。

涉及到的分支有如下几条： 

1. Master 主分支 

2. Develop 分支 

3. Feature 功能分支 

4. Release 预发布分支 

5. Hotfix 分支

以上各分支之间的逻辑关系见下图；

主分支

Master 主分支

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。Git 主分支的名字，默认叫做 Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

Develop 分支

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做 Develop分支。 

 

次分支

Feature 功能分支

Feature（功能） 分支，有时候也叫 Topic 分支。在这种分支上去开发新的功能。当开发功能的时候，这个功能属于哪个目标发行还不知道。功能如果一直在开发，对应的这个功能分支就可以一直存在，不过到最后还是要合并到 develop 分支上，或者如果不想要开发的这个功能了，可以直接扔掉它。 

Hotfix 修复bug分支

最后一种是修复生产bug分支。软件正式发布以后，如果有紧急缺陷，需要创建一个分支，进行bug修复。修复bug分支是从Master分支上面分出来的。修复结束以后，再合并进Master和Develop分支。它的命名，可以采用hotfix的形式。 

四．软件版本命名规范

主版本号+次版本号+修订版本号+紧急版本号+_阶段说明

 

1.版本号修改规则

（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本号由项目决定是否修改。

（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。

（3）修订版本号：一般是QA Bug 的修复或是一些小的变动或是一些功能的扩充（new feature），要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。

（4）紧急版本号：用于记录修改生产环境紧急缺陷的hotfix版本。

（5）阶段说明：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否添加。

2.软件版本阶段说明

Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。

Alpha ：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者 内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。

Beta ：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为 beta版。

RC ：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。

Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的 版本，是最终交付用户使用的一个版本。该版本有时也称标准版。

 

3.版本号修改举例说明

如此时版本号为：1.0.0.0_alpha ，此时为内部测试阶段

（1）开发人员修复了生产环境的bug并经测试人员测试验证关闭bug之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为：1.0.0.0_beta 。

（2）如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版，如1.0.1.0_beta。

（3）如果对软件进行了一些功能上的改进或增强，进行了一些局部变动的时候要修改次版本号，如：1.1.0.0_beta（上一级有变动时，下级要归零）。

（4）当功能模块有较大变动，增加模块或整体架构发生变化时要修改主版本号，如新增加了退款功能，则版本号要改为：2.0.0.0_beta 。