Git的安装和使用

Gitlab是一种仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。现今在国内外大中型互联网公司广泛使用。Git和SVN最大的区别就是Git是分布式(版本库可以存放在每个人的电脑中)，SVN是集中式(版本库集中存放在中央服务器中)

Git ：分布式（版本库可存放在每个人的电脑里）
SVN：集中式（版本库集中存放在中央服务器

Git，Gitlab，Github

git 是一种基于命令的版本控制系统，全命令操作，没有可视化界面

gitlab 是一个基于git实现的在线代码仓库软件，提供web可视化管理界面，通常用于企业团队内部协作开发

github 是一个基于git实现的在线代码托管仓库，亦提供可视化管理界面，同时免费账户和提供付费账户，提供开放和私有的仓库，大部分的开源项目都选择github作为代码托管仓库

在Mac OS及Linux下用终端工具(Terminal)来使用Git，而在Windows平台下用Git Bash工具

Gitlab的ssh key配置

在gitbush里产生密钥，在gitlab中找到ssh key并输入

运行命令测试连接：ssh -T git@gitlab.com

成功的会看到You’ve successfully authenticated字样。如果是连接公司的GitLab，可能有其他限制，输入命令测试连接后会显示git@gitlab.com: Permission denied (publickey)，一开始以为是权限问题，检查了一遍权限发现没问题，直接跳过先继续往下走了

gitlab使用流程

1. 克隆 Git 资源作为工作目录。

2. 在克隆的资源上添加或修改文件。

3. 如果其他人修改了，你可以更新资源。

4. 在提交前查看修改。若有修改先拉再推。

5. 修改完成后，若发现错误，可以撤回提交并再次修改并提交

 idea+gitlab

 使用git管理项目的方式

在github仓库中存在两个（master，develop）具有无限生命周期的主要分支，就是说这两个分支从项目开始到项目结束都会存在

主分支master 

所有用户可见的正式版本，都从master发布（也是用于部署生产环境的分支，确保master分支稳定性）。
主分支作为稳定的唯一代码库，不做任何开发使用。
master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码

开发分支develop

开发分支（develop）。这个分支维护了当前开发中代码的主线，始终保持代码新于master以及bug修复后的代码。
持续集成、最新隔夜版本的生成等都是基于这个分支。由于当前版本迭代较快，开发分支只提供拉取，不进行实际开发。一般开发的新功能时，feature分支都是基于develop分支下创建的

在主要分支和开发分支后，项目仍然需要一些分支来维护，这些分支支持开发成员并行工作，修复实时生产问题，与主要分支不同，这些分支的生命周期是有限的，最终都会被删除

功能分支feature

临时性多个功能分支（feature）

开发新功能时，以develop为基础创建feature分支。

从develop拉取。开发feature完成，merge回develop。为了降低对其他feature的影响，一般在提测前merge回develop分支。

分支命名: feature/*开头的为特性分支， 命名规则: feature/user_module、 feature/order_module

hotfix（修补bug分支）

它们产生于需要立即对现场制作版本的不良状态采取行动。当必须立即解决生产版本中的关键错误时，修补程序分支可能会从标记生产版本的主分支上的相应标记分支出来。

临时性多个bug修复分支（fixbug），用于修复线上问题。
从master拉取，修复并测试完成merge回master和develop。如果修复期间，有其他版本合并入master ，需要同步到fixbug版本，并进行测试。
分支命名: hotfix/*开头的为修复分支，它的命名规则与 feature 分支类似

 release(预发布分支)

临时性多个预发布（测试）分支（release）

release 为预上线分支，发布提测阶段，会release分支代码为基准提测

用于QA测试。从develop拉取，测试完成merge回master和develop。如果测试期间，有其他版本合并入master，需要同步到release版本，并进行测试

dev包和rb(release branches)包都是功能测试包，最终都会合并到master分支去发布上线生产环境。

普遍的应用场景是，master永不上线，每次有新需求会从master拉一个以需求名_日期的新dev分支（dev_A），待需求开发完成后，再从master拉一个上线release分支（releaseA），将这段时间内团队各成员开发的各需求dev分支(如dev_A、dev_B)合并到releaseA，releaseA作为当前版本上线部署，并在上线后合并代码到master分支。
 

大局图

配合IDEA使用 

首先进入项目组后，将公司GitLab中的项目fork到自己的GitLab仓库中，这样就可以操作在自己仓库中的项目，而不是公司仓库里的。

 第一步，配置Git，Test后出现Git的版本说明配置成功。

第二步，从远程库中clone项目

点击File-New-Project from Version Control弹出如下窗口，输入远程库地址以及空的本地目录点击Clone按钮

在命令行ping域名可以得到ip地址 

等待完成即可 

第三步，配置remote(因为是clone的自己仓库的项目，所以需要设置公司项目的remote，方便代码更新)

Git->repository->remotes

添加upstream地址(公司仓库中对应的项目地址）

默认只有origin地址，就是自己仓库中的项目，添加了upstream地址，方便同步公司仓库中的对应项目

第四步，切换分支

因为工作都是在dev开发分支上做的，所以需要更换到dev分支

 

IDEA右下角会显示现在处于那个分支中。

第五步.获取公司仓库中的更新

fork到自己仓库中的项目是无法自动与公司仓库中对应项目保持一致更新，所以需要每天手动获取公司仓库中的最新代码

保持代码一致，可以减少后续marge出现的代码冲突。

选择需要更新的分支，pull即可将分支更新到本地

 第六步.Commit代码(git commit主要是将暂存区的改动提交到本地的版本库)

 当一个独立功能、交复杂业务或其他节点开发完成后，尽量将该阶段的代码进行一次【commit】，这样即使下一个节点代码开发有误或其他原因造成代码出现问题，我们可以回退到上次【commit】的节点。

 注（此图引用，如有侵权，联系删除）

第七步.更新自己的仓库

一个任务完成后，将当天开发的代码【push】到自己的 GitLab 仓库中

Git->repository->push,出现以下界面后，即可操作

协同合作常用流程：先更新(Update) 再提交(Commit) 再推送(Push)

第八步.提交merge request(合并请求)

push代码成功后，自己的远程仓库就更新了代码，根据工作的要求，提交merge request,，将自己的代码更新合并到公司的仓库中

对GitLab中的个人仓库项目修改设置，否则合并成功后，自己仓库中的分支会被删除，对需要合并的项目设置如下：

 

 

 第九步.可能存在合并冲突

在提交完成合并请求后，管理员对其进行审核，若在合并中有冲突，需要对有冲突的项目进行以上5、6、7步操作。

【注】在合并请求审核通过之前，我们往自己远程仓库 push（在合并请求之后的 push），管理员都可以看到我们最新的 push，无需关闭合并请求再次提交。