git使用规范

转自：

https://www.cnblogs.com/gzpblog/p/5463031.html

Git安装配置及基本使用

从官网下载安装包，手动完成安装。
打开Git Bash命令行工具，执行命令ssh-****** -t rsa -C Email-Addresss生成一个**对。
登录到GitLab，点击右上角你的用户头像，点击Edit Profile settings，点击SSH Keys，点击Add SSH Key，填写Title栏，复制用户目录下.ssh/id_rsa.pub文件的内容到Key，点击Add Key。
点击右上角的New project，填写完成后点击Create project新建一个仓库，点击Activity，点击SSH后复制SSH边上栏里的地址。
打开Git Bash命令行工具，切换到一个合适的目录，使用命令git clone 刚才复制的URL克隆创建的仓库。
进入目录cd 仓库名，执行命令git config --global user.email your-email，
git config --global user.name your-name，设置你的个人信息。
执行命令：
echo "#Description" > README.md，添加一个文件
git status，查看当前状态，发现有未跟踪文件
git add .，当前目录所有文件添加到暂存区
git diff，比较当前工作区和暂存区有何不同
git status，查看当前状态，发现有文件未提交
git commit -m "注释"，把暂存区内容提交到本地仓库
git push -u origin master，把本地仓库的提交推送到远程仓库
git log，查看提交日志

Git本地分支管理

分支的创建、合并、删除
git branch，显示所有分支
git branch b1，从当前分支创建一个叫b1的分支
git checkout b1，切换到b1分支
git checkout -b b1，相当于以上两条命令的组合
git checkout master，切换到master主分支
git merge b1，把b1分支的代码合并到master上
git branch -d b1，删除b1分支，不能在被删除分支上执行

Git Tag标签管理

标签的创建、删除
git tag t1，从当前分支创建一个名为t1的标签
git tag -d t1，删除名为t1的标签

GitLib权限管理

GitLib有五种身份权限，分别是：

Owner 项目所有者，拥有所有的操作权限

Master 项目的管理者，除更改、删除项目元信息外其它操作均可

Developer 项目的开发人员，做一些开发工作，对受保护内容无权限

Reporter 项目的报告者，只有项目的读权限，可以创建代码片断

Guest 项目的游客，只能提交问题和评论内容

具体参见GitLab权限，为项目添加成员时可指定成员的身份权限。

命名规则

每次提交必须写明注释，如果是修复Bug，请加上Bug号

创建特性分支，名称要以f-开头，加上特性名

创建发布分支，名称要以r-开头，加上预发布版本号

创建Bug修复分支，名称要以b-开头，加上Bug号

创建标签，名称要以t-开头，加上发布版本号

合并分支时必须使用--no-ff参数，以保留合并历史轨迹

分支模型

整体流程图:
git使用规范

主要分支（保护分支）

master 主分支，稳定代码，为生产环境做准备的
develop 开发分支，为开发服务
分支关系类似下图：

辅助分支

特性分支

从develop分支创建，用于特性开发，完成后要合并回develop分支。
操作过程：
git checkout -b newfeature develop，从develop分支创建newfeature特性分支
git checkout develop，开发完成后，需要合并回develop分支，先切换到develop分支
git merge --no-ff newfeature，合并回develop分支，必须加--no-ff参数
git branch -d newfeature，删除特性分支
git push origin develop，把合并后的develop分支推送到远程仓库
分支关系类似下图:
git使用规范

发布分支

从develop分支创建，用于预发布版本，允许小bug修复，完成后要合并回develop和master。
操作过程：
git checkou -b release-1.2 develop，创建一个发布分支
git checkout master，切换到master分支，准备合并
git merge --no-ff release-1.2，把release-1.2分支合并到master分支
git tag 1.2，从master分支打一个标签
git checkou develop，切换到develop分支，准备合并
git merge --no-ff release-1.2，把release-1.2分支合并到develop分支
git branch -d release-1.2，删除这个发布分支

修复分支

从master分支创建，用于生产环境上的Bug修复，完成后要合并回develop和master。
操作过程：
git checkout -b hotfix-1.2.1 master，从master分支创建一个Bug修复分支
git checkout master，切换到master分支，准备合并
git merge --no-ff hotfix-1.2.1，合并到master分支
git tag 1.2.1，为master分支创建一个标签
git checkout develop，切换到develop分支，准备合并
git merge --no-ff hotfix-1.2.1，合并到develop分支
git branch -d hotfix-1.2.1，删除hotfix-1.2.1分支
分支关系类似下图:
git使用规范

Git协同模型

SVN式集中协同模型

适用于小型项目，参与人员较少的项目，每个开发者均可向仓库推送代码
git使用规范

规范二：

一、Git分支简介

新功能特性开发：创建 feature 分支，多人并行开发
版本迭代开发：develop唯一分支，多人并行开发
测试发布：将 master分支与待测分支汇总到release 分支
Master分支BUG：在feature分支上debug
Tag版本BUG：在hotfix分支上debug
版本上线：release分支合并到master,发布上线
里程碑打版：大版本迭代上线后，创建Tag版，作为里程碑

git使用规范

二、Git分支规则

master分支

产品的某一版本功能测试通过后，最终在master分支对外发布，master分支必须保证随时可发布。禁止将未经过测试的代码合并到master分支

develop 分支

基于master分支克隆，feature分支功能开发完成并经过内部或自行测试后合并到dev分支。dev分支有且仅有一个，在多个功能同时开发、修改且在不同时间点上线的使用release开发方式

命名规范: xxxxxx-yyyymmdd-dev

release 分支

创建release 分支（发布分支），将所有要发布的分支逐个合并到release分支

命名规范: xxxxxx-yyyymmdd-release

hotfix 分支

Bug修复分支，基于tag创建，主要用于修复对外发布的分支，收到客户的Bug反馈后，在此分支进行修复，修复完毕后分别合并到dev分支，测试通过够再将此分支合并到master分支。本分支属于临时分支，目的实现后可删除分支，分支命名规范bugfix-xxx或bufix-issueNN，xxx推荐与tag名称相同, NN代表bug编号（bug编号可见禅道）