09.07
gitlab使用教程--eclipse
目录
1）在Eclipse中新建一个项目，此处新建测试用的项目是GitPro1
12）新建分支与master分支进行合并请求（Merge Request）
16）自建工程push到远端后本地git没有远端追踪的解决方案
一、基本操作
1.登录：
在浏览器地址栏输入http://10.6.2.160/ 回车，进入登陆界面。
在上图红框区域登陆自己的账户密码。
2.修改密码：
登录成功后点击左侧工具栏目Profile Settings ------ Password -------修改密码-------Save password。
Tips：
点击GitLab的logo，可以从任何界面回到本页
二、项目管理
可以根据需要选择新建项目、新建组合新建用户
1.新建项目
如下图所示新建项目：
创建时可以选择在自己用户下创建或者某个群组内创建
a. 项目名称，项目名称可以为字母、数字、空格、下划线、中划线和英文点号组
成，且必须以字母或数字开头，不能使用中文
b. 项目描述
c．可见性（库类别）
私有库：只有被赋予权限的用户可见
内部库：登录用户可以下载
公开库：所有人可以下载
根据实际情况填写完各项之后，点击创建项目，项目创建成功
提示通过SSH方式拉取推送项目代码必须要导入SSH key，这个稍后再介绍。
项目地址有HTTP和SSH两种方式-------可发送给开发人员下载和初始化项目
2.编辑或删除项目
主页左边菜单栏--------Project
右上角的齿轮状按钮--------编辑项目
右下角删除项目。
或者点击Admin Area
三、用户管理（管理员使用，非管理员跳过此步骤）
1.新建用户
点击顶端的Admin Area按钮
可以进入管理页面
1) 姓名（可以是中文）
2) 用户名（可以为字母、数字、空格、下划线、中划线和英文点号组成，且必须以字母或数字开头，不能使用中文）
3) 邮箱地址（首次接收密码）
4) 建项目的数量限制
5) 是否可以创建组
6) 是否是管理员
7) 选填内容（个人联系方式）
2.编辑和删除用户
四、组管理（管理员使用，非管理员跳过此步骤）
1.新建组
菜单栏Group------New Group
1). 组名称，组名称可以为字母、数字、空格、下划线、中划线和英文点号组成，
且必须以字母或数字开头，不能使用中文
2). 组详情
2.编辑或删除组
在此页面可以编辑和删除组
3.添加组成员
添加组用户并赋予相应的权限。
4.修改成员的权限（owner用户操作）
点击左侧的Groups，然后点击当然的组。
然后点击左侧Members菜单进入。
修改想要修改的用户的权限并save
5.从组管理添加项目
从组里添加项目可免去再添加项目用户的步骤，因此我们选择从组内添加工程。
点击左侧Group，然后点击齿轮按钮。
然后点击Project，接着点New Project
按步骤填写最后点击Create Project创建项目。
此时组内成员都能看到这个项目已经被创建。
五、权限说明
Guest(匿名用户) - 创建项目、写留言薄
Reporter（报告人）- 创建项目、写留言薄、拉项目、下载项目、创建代码片
段
Developer（开发者）- 创建项目、写留言薄、拉项目、下载项目、创建代码
片段、创建合并请求、创建新分支、推送不受保护的分支、移除不受保护的分
支 、创建标签、编写wiki
Master（管理者）- 创建项目、写留言薄、拉项目、下载项目、创建代码片
段、创建合并请求、创建新分支、推送不受保护的分支、移除不受保护的分
支 、创建标签、编写wiki、增加团队成员、推送受保护的分支、移除受保护
的分支、编辑项目、添加部署密钥、配置项目钩子
Owner（所有者）- 创建项目、写留言薄、拉项目、下载项目、创建代码片
段、创建合并请求、创建新分支、推送不受保护的分支、移除不受保护的分
支 、创建标签、编写wiki、增加团队成员、推送受保护的分支、移除受保护
的分支、编辑项目、添加部署密钥、配置项目钩子、开关公有模式、将项目转
移到另一个名称空间、删除项目
六、Gitlab在eclipse中的使用
1.生成SSH key
我们用的是eclipse自带的生成key的工具，windows->preferences->General->Network Connections->SSH2，点击SSH2。
在key management处点生成RSAkey
后面输入key的说明和密码，密码也可以空着。点save private key. 把生成的key文件存到用户目录的.ssh目录下。（像第一张图中SSH2 Home指定的目录）
会生成两个文件，一个id_rsa是私钥，一个id_rsa.pub是公钥。
2.发布公钥到服务器
用记事本打开刚刚保存的id_rsa.pub文件，能看到如图所示的类似内容，将他们复制下来。
用你的用户登录到GitLab, Profile Settings->ssh keys->add ssh key. 给用户添加全局的公钥文件。
把刚刚复制的内容粘贴到页面上，add key。
3.相关的具体操作
1）在Eclipse中新建一个项目，此处新建测试用的项目是GitPro1
2）新建GitPro1项目的仓库
在项目上右键 -> Team ->Share Project -> Git -> Next
Create->自定义仓库名称->Finish
在D:\Program Files\Git\GitPro1目录下可以看到GitPro1仓库了
同时，eclipse中的project也建立git版本控制，此时未创建分支，处于NO-HEAD状态
文件夹中的”?”表示此文件夹处于untracked状态，这样就成功创建Git仓库。
3）配置.gitignore来过滤不需要上传的文件
这种情况针对带maven依赖的工程！！（因为.classpath .settings .project | clone下来时会有影响造成无法下载jar包依赖）
普通工程暂时不用过滤文件
在工程实现过程中，会生成一些中间文件，或者在项目中的部分文件是不需要进行版本管理的。对于这些文件应该对于Git来讲是透明的。Git提供这种功能，可以自己指定哪些文件可以不被管理。具体方法是在版本管理的根目录下（与.Git文件夹同级）创建一个 .gitignore（gitignore是隐藏文件，所以前面有个点）
右键工程->new file->输入.gitignore 生成.gitignore文件
在界面上输入.classpath .settings .project 保存。可以在仓库视图的Working Directory中看到这个文件。此时你commit时会自动过滤掉这三类文件。若本来工程下面就有这个文件里面如果有/bin/类似的文字不要删除，直接换行添加你需要过滤的文件。
这个在项目里看不到，可以仓库视图的work
4）将项目Commit到本地仓库
尝试提交GitPro1项目，右键->Team->Commit
提示验证信息，将自己用户名和邮箱填写进去，点OK. 下次就不需要填写了。
点击 Commit。我们就把上图中status选中的文件提交到本地git库中了。这些文件从此受git的版本监控了。并且提交注释为version1.0（这个以后用到，当作状态标记）。
接下来打开git repositories视图（Window->show view->other->Git->Git Repositories->OK）
此时，来看看git repositories视图：
这个就是我们在本地git仓库的结构。
5）修改文件后commit
当我们修改GitTest.java的时候。文件状态会发生改变
选中修改过的文件。右击Team->commit. 提交时注释信息为”version 1.1”。
提交完成后，git状态如图
6）添加新文件后的处理
SecondFile.java是我新建的类，“？”表示这个文件未受git库版本监控。要想加入监控：选中这个文件，右击 team > add to index. 之后commit。
7）查看历史提交记录
项目->Team -> Show in history 可以查看版本历史提交记录
8）Push到Gitlab
将本地的git库中的内容push到服务器端的远程仓库
项目->Team -> Remote -> Push填写相关信息后 -> next -> Add All Branches Specs ->Finish
Tips: URI在登陆后的Project栏点击，复制中间的地址。
填写好后，点击next –>Add All Branches Spec->Finish.
完成后：
提示项目已经push到服务器。
我们可以在Gitlab中点击Browse Files查看已经上传的代码。
9）使用.gitkeep来追踪空的文件夹
Git会忽略空的文件夹。如果你想版本控制包括空文件夹，根据惯例会在空文件夹下放置.gitkeep文件。其实对文件名没有特定的要求。一旦一个空文件夹下有文件后，这个文件夹就会在版本控制范围内。
10）clone 在GitLab中已有项目
为演示，先删除刚刚在eclipse里创建的GitPro1项目
客户端Eclipse上，打开git Repositories视图。点击 . clone a git Repository.
输入信息后点击next，我们会看到服务端git库的分支master出现了
Next
点击Finish. 我们的clone就完成了。
现在在自己的工作空间创建了服务器端的项目。
克隆服务器端仓库后，会在本地建立一个一样的仓库，称本地仓库。
如果clone带有过滤文件的maven+git工程时，clone下来时是无法直接到工作空间的。需要从仓库视图里导入。
当clone下来带有过滤后的Maven+git工程时在git仓库视图右键—>Import projects—>Import as general project—>next—>finish,此时eclipse工作空间就导入了项目，但现在是没有maven的，右键工程—>Configure—>Convert to maven project，现在工作空间的工程就是一个完整的maven+git工程了。
11）新建自己的分支进行开发并push到远程分支
Team->Switch To->New Branch
此时，刚刚clone下来的分支已经切换成自己的分支，我们就能在自己的分支上任意开发了
在自己分支上开发，修改文件并commit提交到本地仓库。
接下来要push到远程的新建分支
Team->Remote->push->Next->Add Spec->Next->Finish
成功将自己修改后的代码提交到远程新建的自己的分支
现在在Gitlab上就能看到两个分支，一个master主分支（保护状态，developer无法push）和yjx新建分支
12）新建分支与master分支进行合并请求（Merge Request）
登陆自己的Gitlab账户。点击Project或进入工程点击Branch会看到创建合并请求的标签：
点击Merge Request
此时，管理员登陆Gitlab后点左侧Projects->GitPro1->Merge Requests
管理员任何新建分支提交的代码，审阅后没有问题的情况下点击Accept Merge Request
此时我们看到合并到master分支后的情况
Tips： matser用户可以直接push到master分支。Developer无法直接push到受保护的master分支，必须先建立自己的分支，再提交，推送，请求合并。
13）退回历史版本
远程仓库和本地仓库都存放有我们提交的每一个历史版本。
打开工程的历史，在要退回的历史版本上右键reset->Hard->yes，工程就退回历史版本了
14）推送冲突的解决
对于master用户来说：
假定咱们clone到本地的工程分支保持不变是1.1版本，但是服务器远程分支已经被更新到1.3版本了，此时就会产生冲突，无法提交：
此时我们要将工程pull到最新 team->pull将远程的修改pull到本地git库：
点ok。你回发现工作空间的项目出现冲突的标志。
此时，选择冲突的文件GitTest.java右击，Team > merge tool .
选择第二项，ok。
根据比较修改左边的文件，也就是你工作空间中的文件。解决完冲突之后。保存。如图状态。
现在你可以提交这个文件了。选中GitTest.java 右击team > add to index .
此时工作空间中的图标有所变化。
当出现灰色的雪花符号时，你就可以进行提交并 push到服务器端。
commit 状态
之后，push。
现在成功push
15）自建分支开发前获取远程master更新并与本地合并
作为developer用户在自己的分支上先右键->fetch from upstream将远程master分支的最新版本更新到本地，ok。 接着右键->team->merge ,如图选择下面远程仓库的master分支，Merge，选择最新的版本，点ok，则当前自己的分支已更新到远程master分支同步。
Merge之后当前分支已经和服务器端远程仓库的master分支一致了，就可以继续开发了。
16）自建工程push到远端后本地git没有远端追踪的解决方案
这种情况发生在我们自己建立的工程，并且在该工程下继续开发时。本地新建工程后
进行commit-push，将代码推送到服务器端后，会发现本地git视图的远程追踪是空的，只有本地追踪。此时，如果有人参与该工程，并且远端分支修改，你需要fetch时，在IDE中时无法操作拉远程分支的。
如何解决这个问题？我们切到git仓库视图，在下图中的Remotes仓库的小图标上右键，点击Create Remote，再点击configure fetch，点ok。
然后将服务器web端的工程URL粘贴在下图中，并填上主机地址。点finish。接下来再点击左下角的save and fetch。然后大功告成，最后一张图中我们就看到方框中远程追踪已经出现了，接下来你就可以任意的fetch远程分支了。
Git分支管理规范
关于Git的一些分支管理规范。。。
一、分支与角色说明
Git 分支类型
master 分支（主分支） 稳定版本
develop 分支（开发分支） 最新版本
release 分支（发布分支） 发布新版本
hotfix 分支（热修复分支） 修复线上Bug
feature 分支（特性分支） 实现新特性
Gitlab 角色与项目角色对应关系
Owner（拥有者） Git 管理员
Master（管理员） 开发主管
Developer（开发者） 开发人员
Reporter（报告者） 测试人员
Guest（观察者） 其他人员
二、分支简明使用流程
1、每开发一个新功能，创建一个 feature 分支，多人在此分支上开发；
2、提测时，将 master 分支和需要提测的分支汇总到一个 release 分支，发布测试环境；
3、发现bug时，在feature分支上debug后，再次回到2；
4、发布生产环境后，将 release 分支合并到 master 分支，删除release分支；
三、创建新项目（master分支）
开发主管提交代码初始版本到master 分支，并推送至Gitlab系统；
开发主管在Gitlab 系统中设置master 分支为Protectd 分支（保护分支）；
Protected 分支不允许Developer 角色推送代码，但Master 角色可以推送代码；
四、进行项目开发（develop分支）
开发主管在master 分支上创建develop 分支（开发分支），并推送至Gitlab系统；
master 分支与develop 分支一样，有且仅有一个；
对于非并行项目可以使用develop分支开发方式，对于多人并行开发项目，使用feature分支开发方式，但develop和feature开发方式不应同时使用；
五、开发新特性（feature分支）
每个新需求或新的研究创建一个feature 分支；
命名规范：
f-分支创建日期-新特性关键字，例如：f-20150508-满立减；
推荐使用feature 分支，但feature 分支的生命周期不能跨一次迭代；
六、发布测试环境（release分支）
开发负责人需完成以下任务：
1. 确认要发布的feature 分支上的功能是否开发完毕并提交；
2. 创建release 分支（发布分支），将所有要发布的分支逐个合并到release分支，有如下情况：
①.feature分支（可能有多个）
②.master分支（期间可能有其他release版本更新到了master）
3. 命名规则：r-分支创建日期-新特性和待发布版本号，例如：r-201505081712-买立减v1.0.0，版本可根据需要添加;
4. 删除本次发布的所有feature分支;
5. 发布到测试环境，通知测试;
七、修复待发布版本中的Bug（feature分支）
如果发现bug，开发人员在feature 分支上修复测试人员提交给自己的bug，修复完成后，由负责人再次创建 release 分支，发布测试环境。
八、发布正式环境
开发负责人需完成以下任务：
1. 根据修复后的release分支再次将master合并，打包发布生产环境;
2. 确认发布成功，并线上验收通过后，将release分支合并到master分支;
3. 在master分支上创建标签，命名规则：tag-日期-新特性和版本号，例如：tag-201505081712-买立减v1.0.0，版本可根据需要添加，作为发版里程碑标记;
4. 删除对应release 分支;
九、修复线上Bug（hotfix分支）
线上的不同版本出现了bug怎么办？开发负责人需完成以下任务：
1. 从master 分支某个tag 上创建一个hotfix 分支（热修复分支），一般是最新的tag应该和当前生产环境对应；
命名规则：h-分支创建日期-bug名称和待发布版本号，例如：h-201705081614-购物车点击没反应v1.0.1;
2. 开发人员完成Bug 修复，提交hotfix分支到测试环境验收通过;
3. 再次发布正式环境流程;
4. 将hotfix 分支合并到master分支;
5. 在master分支上创建标签，命名规则：tag-日期-新特性和版本号，例如：tag-201505081712-买立减v1.0.0，版本可根据需要添加，作为发版里程碑标记;
6. 删除hotfix 分支;
十、Git 的特别注意事项
由于 git 分支是基于指针的概念，所以分支速度非常快，当多个分支时，实际指针指向的是同一个文件，当文件被修改时，使用的是暂存区保存修改，此时并未提交到相应分支。
所以切换分支的时候，暂存区只有一个，所以切换分支之前，一定要将所有修改commit到当前分支，否则会在其他分支看到修改的内容，引起误解。
以上规范仅供参考，具体实践请依据团队具体情况自行调整。。。
Has anything you've done made your life better?
如果你严肃对待编程，就必定会使用"版本管理系统"（Version Control System）。
眼下最流行的"版本管理系统"，非Git莫属。
相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。
但是，太方便了也会产生副作用。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。
Vincent Driessen提出了一个分支管理的策略，我觉得非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。理论上，这些策略对所有的版本管理系统都适用，Git只是用来举例而已。如果你不熟悉Git，跳过举例部分就可以了。
一、主分支Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
二、开发分支Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
Git创建Develop分支的命令：
git checkout -b develop master
将Develop分支发布到Master分支的命令：
# 切换到Master分支
git checkout master# 对Develop分支进行合并
git merge --no-ff develop
这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《Understanding the Git Workflow》。
三、临时性分支
前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
* 功能（feature）分支
* 预发布（release）分支
* 修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
四、 功能分支
接下来，一个个来看这三种"临时性分支"。
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支：
git checkout -b feature-x develop
开发完成后，将功能分支合并到develop分支：
git checkout develop
git merge --no-ff feature-x
删除feature分支：
git branch -d feature-x
五、预发布分支
第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
创建一个预发布分支：
git checkout -b release-1.2 develop
确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
六、修补bug分支
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master
修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1
最后，删除"修补bug分支"：
git branch -d fixbug-0.1