Git & GitLab 使用及规范

Git & GitLab 使用及规范


Git安装配置及基本使用

  1. 官网下载安装包,手动完成安装。
  2. 打开Git Bash命令行工具,执行命令ssh-keygen -t rsa -C Email-Addresss生成一个密钥对。
  3. 登录到GitLab,点击右上角你的用户头像,点击Edit Profile settings,点击SSH Keys,点击Add SSH Key,填写Title栏,复制用户目录下.ssh/id_rsa.pub文件的内容到Key,点击Add Key
  4. 点击右上角的New project,填写完成后点击Create project新建一个仓库,点击Activity,点击SSH后复制SSH边上栏里的地址。
  5. 打开Git Bash命令行工具,切换到一个合适的目录,使用命令git clone 刚才复制的URL克隆创建的仓库。
  6. 进入目录cd 仓库名,执行命令git config --global user.email your-email

    git config --global user.name your-name,设置你的个人信息。

  7. 执行命令:

    echo "#Description" > README.md,添加一个文件

    git status,查看当前状态,发现有未跟踪文件

    git add .,当前目录所有文件添加到暂存区

    git diff,比较当前工作区和暂存区有何不同

    git status,查看当前状态,发现有文件未提交

    git commit -m "注释",把暂存区内容提交到本地仓库

    git push -u origin master,把本地仓库的提交推送到远程仓库

    git log,查看提交日志


Git本地分支管理

  1. 分支的创建、合并、删除

    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标签管理

  1. 标签的创建、删除

    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参数,以保留合并历史轨迹

分支模型

整体流程图:


主要分支(保护分支)

  • 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分支推送到远程仓库

分支关系类似下图:


发布分支

从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协同模型


SVN式集中协同模型

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


金字塔模型

适用于大型项目,参与人员较多,并且等级划分严明,代码需要逐级审核的项目

仅核心开发人员可以向仓库推送代码,开发人员只能从仓库拉取代码,开发人员的代码需先推送给核心开发人员审核通过后,合并之后才能推送,一般情况下是使用GitHubPull Request的方式

时间: 2024-11-05 15:58:14

Git & GitLab 使用及规范的相关文章

Jenkins+Git+Gitlab+Ansible实现持续集成自动化部署静态网站(一)--技术流ken

前言 在之前已经写了关于Git,Gitlab以及Ansible的两篇博客<Git+Gitlab+Ansible剧本实现一键部署Nginx--技术流ken>,<Git+Gitlab+Ansible剧本实现一键部署动态网站(二)--技术流ken>,以及关于jenkins的简单使用<Jenkins持续集成介绍及插件安装版本更新演示(一)--技术流ken>.相信大家也已经完全掌握了这三项工具的使用,也可以使用这几项工具可以部署静态以及动态网站了. 以前的博客可以实现一键部署网站

Jenkins+Git+Gitlab+Ansible实现持续集成自动化部署动态网站(二)--技术流ken

项目前言 在上一篇博客<Jenkins+Git+Gitlab+Ansible实现持续化集成一键部署静态网站(一)--技术流ken>中已经详细讲解了如何使用这四个工具来持续集成自动化部署一个静态的网站. 如果大家可以熟练掌握以上内容,势必会在工作中减轻不小的工作量. 本篇博客将再次使用这四个工具结合freestyle和pipeline来完成动态网站的部署. 为了拓宽知识点,本篇博客将使用jenkins的两种常用方法来进行部署,如果你对pipeline还不熟悉,请参考我之前的博客<Jenki

GIT库代码管理规范

GIT库代码管理规范 一. 规范要求 1. 每个项目建立单独的GIT库.每个GIT库包括两条线,命名规则如下: 开发线(测试):项目名称_DEV 生产线(正式):项目名称 2. 每条线只允许增量不允许回滚: 3. 每个开发人员拉各自的分支开发,合并前先获取DEV代码,再提交合并: 4. 提交分支时注明:动作类型(新增.修改.删除)+改动明细: 5. 从开发线合并到生产线,由测试工程师负责拉代码/标注更新内容: 6. 由发布工程师将代码部署到服务器: 7. 禁止开发人员访问生产线,生产线不对开发人

产品管理开发之Git工作流和分支规范推荐

前言 无论是开源项目还是内部项目,使用Git都是大势所趋,尤其是在产品管理这块,使用Git大大提高了开发效率和产品的交付频率.本篇,针对Git的工作流和分支使用,进行了一些推荐. 目录 1     产品管理开发之Git工作流和分支规范推荐 1.1      Git工作流模型推荐 1.2      Git产品开发分支规范要求 1.2.1      永久分支 1.2.1.1  master(稳定版) 1.2.1.2   开发版(develop) 1.2.2      临时性分支 1.2.2.1  

Git &amp; Gitlab 开发规范流程

第一步:clone开发分支到本地 源仓库建立以后,开发者需要自己去复制一份到本地 #获取源仓库项目 #旧版本为例 $ git clone [email protected]:hello/ta.git 第二步:新建分支 首先,每次开发新功能,都应该新建一个单独的分支 #新建一个开发分支 $ git checkout –b xxxxx #获取分支最新代码 $ git pull origin dev 第三步:提交commit 分支修改后,就可以提交commit了 $ git add . / git a

快速上手git gitlab协同合作

简单记录,整理. 摘要 为方便大家快速上手Git,并使用Gitlab协同合作,特编写此手册,手册内容不会太丰富与深入.主要包含如下内容: Git 使用教程1.1 安装1.2 常用命令1.3 版本控制1.4 分支与tag Gitlab 使用教程2.1 界面简介2.2 常用功能介绍2.3 注意事项 多人协作流程与规范3.1 永久与临时分支3.2 工作流图3.3 规范 Code Review4.1 为什么要有Code Review4.2 如何进行? 参考资料 后续会加入CI,自动部署等. 1. git

Git Manual / Git使用手册 / Git, GitLab, Git Bash, TortoiseGit

Git使用手册 目录 1     引言 2     Git.GitLab简介 2.1      Git 2.2      GitLab 2.3      Git基本概念 3     运行环境 4     基本操作 4.1      安装Git 4.2      使用GitLab服务器上的帐号 4.2.1      常见页面 4.2.2      设置头像 4.2.3      设置SSH Keys 4.2.4      新建项目 4.2.5      合并请求 4.3      使用Git Ba

Git &amp; Gitlab 使用指南

2016-02-23   |   9,129字   |   分类于 工具  |   3条评论 去年小组在从 SVN 和 TFS 迁移到 Git 的过程中整理了这份文档,面向的用户是对 Git 和 SVN 可能都不是很了解的人.看到自己写了这么多,于是就拿出来分享下,有些东西可能写得比较浅,有错误还请指正. 1. 关于 Git 你应该知道的东西 Git 是一个分布式版本控制系统.分布式的意思是,每个人电脑上都是一份完整的代码库,包含了所有的代码提交历史.由于 Git 分布式的特点,在没有网络的情况

Idea + Git + GitLab 使用

首先去下载Git,https://git-scm.com/ 安装好之后,打开Idea--->Settings,,,设置Git路径,然后点击Test按钮 然后是GitLab,一般企业内部开发都会有个私服服务器.服务器地址找你们组的相关人员要.一般为http://gitlab.XXXXXXX.com/这种格式,先去注册 注册完之后,让你们公司相关人员开放权限.给你开放权限之后你才能看到你需要负责的项目.利用邮箱,密码登录.登录进来之后大概是这样子: 有一个与你相关的项目列表.选择其中一个,点击后 复