GitLab配置库使用规范
本文介绍了将原有Clearcase配置库迁移到GitLab进行配置管理的目的和流程,定义了配置管理角色与职责,描述了GitLab环境和基础设施,包括服务器配置和客户端平台,以及GI 库规划中的Group和Project规划。规划原则包括按合同类项目或子系统建立Group,在业务线内按实际子系统划分Project,同时包含文档管理库和数据库脚本库。

GitLab配置库使用规范
1. 概述
1.1 目的
随技术发展将原有Clearcase配置库迁移到G进行配置管理。为开发人员、CML、CM系统管理员使用GIT配置管理工具提供有效指导。
GitLab是利用 Ruby on Rails 一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。
1.2 配置管理流程
配置管理流程描述了配置管理流程与角色规划,定义了开发人员、项目级配置管理员、组织级配置管理员、项目经理、测试人员、QA等角色,并制定了这些角色的配置管理流程及相关活动。
1.3 角色与职责
项目配置管理角色包括项目级配置管理员,项目经理,项目软件经理,开发人员,测试负责人,测试人员,实施人员,组织级项目配置管理员和质量保证人员。表1-1列出了配置管理的角色和职责。
表1-1 配置管理角色和职责
配置管理角色 | CM活动 |
---|---|
项目级配置管理员 | 设置和检查客户端CM环境 项目用户权限维护 标识配置项(规范,创建配置项) 编写配置管理计划 负责配置审计,报告配置状态 维护和发布项目配置库基线 向集成空间提交稳定版本 更新项目产品库 更新开发空间(master分支,Develop分支、release分支、hotfix分支) 培训项目组人员 |
项目经理PM | 指定项目级配置管理员 合作公司、外包配置管理策略(unieap、UI) 变更请求(包括计划任务)的审批 对项目执行情况负责 |
项目软件经理PSM | 指导和监督配置管理的实施 (例:确定打基线的时机;deliver & rebase的时机;配置环境的建立时机) 制定项目配置管理策略 包括:配置层次结构、访问权限、基准管理计划等 变更请求(包括计划任务)的分配 |
开发人员 | 创建开发空间(视图) 根据项目任务分配创建、修改开发内容 分析和更新变更请求(开发任务,缺陷) |
部门级配置管理员 | 设置、检查和维护服务端CM环境 协助项目配置管理员搭建项目配置管理环境 配置管理系统数据的备份检查及恢复测试 负责软件过程和系统改进(升级) 培训项目级配置管理员 |
测试人员&实施人员 | 提交变更请求(缺陷) 更新变更请求(缺陷) |
测试负责人 | 获取待测基线 基线提升 建立缺陷库初始环境 |
QA | 配置审计 |
1.4 环境和基础设施
1.4.1 配置管理工具
工具名称&版本: GitLab Community Edition 15.1.2
1.4.2 服务器
表1-2 服务器配置
主机名 | 操作系统版本 | CPU | 内存 | 硬盘 |
---|---|---|---|---|
GitLab | AlmaLinux 8.6 | 4 C | 4 G | 100 G |
依赖组件:
GitLab 15.1.2
GitLab Shell 14.7.4
GitLab Workhorse v15.1.2
GitLab API v4
Gitlab KAS 15.1.0
Ruby 2.7.5p203
Rails 6.1.4.7
PostgreSQL 13.6
Redis 6.2.7
1.4.3 客户端平台
GIT客户端和相关文档资料的下载,请找部门配置管理员索取。
2 GIT配置库管理
2.1 GIT库规划
以下子系统、子应用及文档标识规则命名可参考事业部OSSP中《标识规范》之约定。
2.1.1 Group规划
Group划分原则:一个合同类项目一般建立一个Group,如果项目存在多个业务线的子系统,一个子系统建立一个Group。一个合同类项目可以按照产品线不同建立一个或多个Group。不同group以Group name中子系统缩写及名称进行区分。
Group信息包括:
- 组名称,组名称可以为字母、数字、空格、下划线、中划线和英文点号组成, 且必须以字母或数字开头,不能使用中文
- 组详情
Group name: XXX_YYY
组名命名规则:项目缩写_子系统缩写
例:xxx_core——xxx核心
xxx_dbcenter——xxx数据中心
xxx_med ——xxx医保接口
xxx_ggfw ——xxx公共服务
Details:xxx_xxx公共服务信息系统_xxx省人力资源与社会保障厅
描述填写规则:项目名称_客户名称_项目缩写
其中:项目编号为事业部立项后产生,项目缩写为项目名称中英文缩写,各产品线英文缩写保持一致,原则上与Clearcase中project名称保持一致
研发类R&D项目以rd为前缀命名项目。
例:xxx_CORE_社保核心业务信息系统_省人力资源与社会保障厅
xxx_GGFW_公共服务信息系统_省人力资源与社会保障厅
Group avatar:图示,可由项目自行维护
2.1.2 Project规划
Project划分原则:Project的规划一般需要按照项目的功能模块或文件类型来进行,也可以按照自己项目的特点如按子系统规划Project。
以业务线内实际子系统划分,并同时包含文档管理库、数据库脚本库
Project信息包括:
项目名称,项目名称可以为字母、数字、空格、下划线、中划线和英文点号组成,且必须以字母或数字开头,不能使用中文
选择命名空间(组、用户)
项目描述
可见性(库类别)
私有库:只有被赋予权限的用户可见
内部库:登录用户可以下载
公开库:所有人可以下载
- 其它 可以自定义库
Project name: xxx-yyy-zzz
命名规则:子系统名称
例:doc 文档管理库
ora 数据库管理库
xxx-hospitals
xxx-resident
xxx-person
xxx-yyy-pension
Namespace :groupname xxx_GGFW
Description: xxx公共服务企业个人子系统
2.1.3 Branches规划
GIT常用的工作流程有三种,分别是Git flow、GitHub flow、Gitlab flow
1、Git flow
最早诞生、并得到广泛采用的一种工作流程,就是Git flow 。
整体流程如下:
项目存在两个长期分支:
主分支master:用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版
开发分支develop:用于日常开发,存放最新的开发版。
存在三种短期分支:
功能分支(feature branch)
补丁分支(hotfix branch)
预发分支(release branch)
一旦完成开发,它们就会被合并进develop或master,然后被删除。
Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。不适用于进行"持续发布"的项目,要长期维护两个分支。
2、GitHub Flow
Git flow的一个更简单的替换方案是GitHub Flow,它只有一个feature分支和一个master分支,简单而干净。但是这种工作流中仍然有很多问题没有解决,例如部署、环境、发布和issue的管理。
3、Gitlab flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。我们推荐Gitlab工作流作为最佳的实践方式。流程图如下:
gitlab flow中的生产分支
在实际项目管理过程中,合并后的代码不一定要马上发布,可能需要一定时间的进行生产环境部署审核。GitLab flow引入了production分支来放置发布的代码。可以通过合并master到production分支来发布一个新的版本。production分支上的版本包含了当前线上内容,只需要查看production分支即可。可以从merge信息或自动部署时创建的tag查询production分支发版时间。
gitlab flow的分支使用
当项目有需要进行测试等缓存环境时候GitLab flow可以升级master分支为preproduction环境和一个production环境。在这种情况下master被用来作为缓存区。当有人想部署到preproduction环境,他们会创建一个从master分支到preproduction分支的merge request。而且上线代码通过合并preproduction分支到production分支。这种下行(downstream)的工作流保证了所有代码都在环境中测试过。如果你需要cherry-pick一个hotfix,常见的是在feature分支中开发,然后以合并请求合并到master分支,先不要删除feature分支。如果master分支通过ci并且运行正常,就可以合并到其它分支。如果需要更多的手工测试,你可以发送合并请求从feature分支到downstream分支。
Gitlab flow的发布分支:
在很少的情况下需要使用release分支对外界发布软件。在这种情况下,每个分支都会包含一个版本号(2-3-stable, 2-4-stable, etc)。这种stable分支都会从master开始,并且要尽可能晚的创建。创建的越晚,你就会越可能的减少bug fix的合并。在release分支发布后,只有严重的bug修复才加到release分支中。如果可能的话,这种bug的修改首先应合并到master,然后cherry -pick到release分支。这样子,你就不会忘记把修复bug的代码cherry pick到master,从而防止其他分支也出这个bug。每次release分支修改bug之后,都要先设置tag,然后增加版本号。有些项目也有stable分支用来指向最近release版本的commit,这种情况下一般没有production分支
Branches name:
命名规则:
创建特性分支,名称要以f-开头,加上特性名
创建发布分支,名称要以r-开头,加上预发布版本号
创建Bug修复分支,名称要以b-开头,加上Bug号
创建开发者私有分支,命名规则为开发人员账户_所开发的功能。命名中不要使用特殊字符,不要使用点。
例如admin开发的分支,命名为admin_Feature医保接口开发
合并分支时必须使用--no-ff参数,以保留合并历史轨迹
2.1.4 Tag
创建标签,名称要以t_开头,加上发布版本号
Tag name :
命名规则:t _提交时间_用户名称修改问题(可为问题平台编号)
例:t 20160801_admin Z1ZB1412590A-4增加对统筹区权限的配置
Detail:修改问题内容描述
2.1.5 Commit
Commit为修改内容的简单描述
Commit name: 修改问题描述
例:增加对xxx的配置
Signed-off-by: zfqc zfqc@neusoft.com
2.2 GIT库权限控制及创建项目申请流程
2.2.1 User
GIT帐号与公司LDAP账号关联,开发人员在使用公司邮箱账号登录系统后修改本人描述信息即可。
权限划分 | 拥有权限 | 适用人员 |
---|---|---|
Owner(所有者) | 创建项目、写留言薄、拉项目、下载项目、创建代码片 段、创建合并请求、创建新分支、推送不受保护的分支、移除不受保护的分支 、创建标签、编写wiki、增加团队成员、推送受保护的分支、移除受保护的分支、编辑项目、添加部署密钥、配置项目钩子、开关公有模式、将项目转 移到另一个名称空间、删除项目 | 项目所有者 拥有所有的操作权限 |
Master(管理者) | 创建项目、写留言薄、拉项目、下载项目、创建代码片 段、创建合并请求、创建新分支、推送不受保护的分支、移除不受保护的分 支 、创建标签、编写wiki、增加团队成员、推送受保护的分支、移除受保护的分支、编辑项目、添加部署密钥、配置项目钩子 | 项目PM\PSM 具有添加组成员、创建组内项目、维护组内项目权限,除更改、删除项目元信息外其它操作均可 |
Developer(开发者) | 创建项目、写留言薄、拉项目、下载项目、创建代码片段、创建合并请求、创建新分支、推送不受保护的分支、移除不受保护的分支 、创建标签、编写wiki | 项目开发人员 项目开发提交权限,对受保护内容无权限 |
Reporter(报告人) | 创建项目、写留言薄、拉项目、下载项目、创建代码片段 | 学习人员 项目只读权限,可以创建代码片断 |
Guest(匿名用户) | 创建项目、写留言薄 | 测试人员 提交项目issue只能提交问题和评论内容 |
参与整个项目人员可授予group的权限,如果只参与项目中个别project,可授予project权限
人员申请项目权限需要发送邮件给项目负责人进行授权,如大区人员需要使用GIT由项目负责人发送邮件给所在开发部长、项目总监、抄送部门CML,审批通过后方可授权,发送邮件要求如下:
申请账户的格式为
姓名:某某
所在部门:xx大区
职务:开发人员、实施人员、测试人员
项目组:xxx公共服务项目xxx_ggfw
子系统名:xxx-hospitals
项目负责人:某某某
人员退出项目应由项目负责人将人员去除Group 或Project member
人员离职应由配置管理人员将人员权限去除并锁定账户状态Blocked。
*为保证信息安全项目负责人、部门配置管理员应定期审计权限列表以便去除非项目内人员。
2.2.2 Group\Project
新项目、新团队创建有配置库管理员进行初始化,项目初始化后项目负责人可以由项目实际情况增加Project member
1、由PM向所在部门的开发部长申请创建配置库,并抄送负责创建该项目的部门级CML、组织级CML及组织级QA。邮件内容格式如下:
申请项目的格式为
项目编号:xxxyyyzzz
项目代码:xxx_nkjh
项目名称:xx省稽核系统
客户名称:xx省人力资源与劳动保障厅
基 准: xx干净版
project: ora
doc
java
flex
项目PM,PSM:李某某lixx@neusoft.com
人员信息:
张某某<zhangyy@neusoft.com>
赵某某<zhaozz@neusoft.com>
项目由配置管理人员创建成功后,会进行邮件通知,反馈邮件里包括完成情况、仓库名等。
2、经部长审批同意后,由部门级CML负责创建配置库。
3、CML创建完毕,将创建配置库的相关信息反馈给PM,同事抄送部长、组织级CML及QA。
4、PM收到建库完毕通知后及时安排人员验证新建配置库是否可用,如有问题与CML及时沟通。
部门CML创建项目应使用事业部统一分配的账号进行创建,事业部统一分配账号添加新项目、删除已经不使用的配置库。
3 GIT安装配置及基本使用
3.1 创建Git项目
3.1.1 创建组
部门配置管理员使用提权的个人账号登录http://zfgit.neusoft.com/users/sign_in
在左上角菜单栏Menu点击Groups,进入group管理区,然后创建group
按照Group规划及命名规则定义Group,填写描述,上传Group图标,选择Group类型为私有(Private);如果该组内的项目为事业部级分享的项目,Group类型选择Internal。
3.1.2 创建项目
在左上角菜单栏Menu点击Projects,进入project管理区,然后创建项目
New Projects: 选择项目所在Group、导入、选择创建项目类型。
Project的GIT地址
http://zfgit.neusoft.com/GG00/PP00.git
项目链接配置
项目创建完毕后回复项目经理创建GIT申请邮件,将如下链接内容同步发送一遍开发人员使用,
注意: 如果项目组已经存在一个Git配置库源码,则创建项目的时候不选择“Initialize repository with a README”,也就是默认不创建README文件,避免上传的时候还需要与README文件进行合并操作,比如源码迁移的时候,就不需要创建初始化的README文件。
Git global setup
git config --global user.name "Administrator"
git config --global user.email "admin@example.com"
Create a new repository
git clone http://zfgit.neusoft.com/GG00/PP00.git
cd PP00
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master
Existing folder
cd existing_folder
git init
git remote add origin http://zfgit.neusoft.com/GG00/PP00.git
git add .
git commit
git push -u origin master
Existing Git repository
cd existing_repo
git remote add origin http://zfgit.neusoft.com/GG00/PP00.git
git push -u origin --all
git push -u origin --tags
3.1.3 项目初始化
项目经理在收到GIT project创建完毕通知后,连接GIT库上传项目基准源码。
链接GIT
git config --global user.name "GIT用户名"
git config --global user.email “GIT用户名@neusoft.com”
将基准内容提交GIT库
git clone http://zfgit.neusoft.com/GG00/PP00.git
cd captcha
git add .
git commit -m 'first commit'
git remote add origin http:// zfgit.neusoft.com /GG00/PP00.git
git push -u origin master
注意:GIT不允许将空文件夹提交GIT库受控,但在实际项目中往往存在上传某空文件夹的需求,可以在该空文件夹中存放.gitkeep文件以便上传。
3.1.4 创建分支
Master为项目初始化时默认生成分支,新建分支GUI方法下:
登录GIT地址——project——Repository——Branches——New branch
填写分支名称创建完
分支授权:
在Project—Settiings—Repository--Protected Branches,设置各分支保护的内容。
3.1.5 人员授权
组成员授权
访问Group地址http://zfgit.neusoft.com/GG00
选择Members进行设置
Group Members可以对当前组下所有项目进行操作,如果某人只参加单独项目可以对人员在Project中进行单独授权。
增加组成员:
项目成员授权:
访问Project地址http://zfgit.neusoft.com/GG00/PP00
在项目Settings中选择Members,选择人员进行授权
3.2 项目负责人使用指南
3.2.1 项目申请
1、由PM向所在部门的开发部长申请创建配置库,并抄送负责创建该项目的部门级CML、组织级CML及组织级QA。邮件内容格式如下:
申请项目的格式为
项目编号:xxxyyyzzz
项目代码:xxx_nkjh
项目名称:xx省稽核系统
客户名称:xx省人力资源与劳动保障厅
基 准:xx干净版
project: ora
doc
java
flex
项目PM,PSM:张某某zhangxx@neusoft.com
人员信息:
张某某<zhangxx@neusoft.com>
李某某<lixx@neusoft.com>
郭某某<guoxx@neusoft.com>
项目由配置管理人员创建成功后,会进行邮件通知,反馈邮件里包括完成情况、仓库名等。
2、经部长审批同意后,由部门级CML负责创建配置库。
3、CML创建完毕,将创建配置库的相关信息反馈给PM,同事抄送部长、组织级CML及QA。
4、PM收到建库完毕通知后及时安排人员验证新建配置库是否可用,如有问题与CML及时沟通。
3.2.2 项目人员授权
部门配置管理员拥有将人员添加到Group和Project的权限。添加到Group member对当前Group中所有Project拥有相应的权限,添加到Project只对当前Project拥有相应权限。项目负责人不可以进行人员的任何授权!
1、添加到Group
登录Group地址:http://zfgit.neusoft.com/Group名,在下图界面中选择Member。在“Add new member to GG00”中选择添加的用户、权限、期限,添加到项目。
2、添加到Project
登录Project地址:http://zfgit.neusoft.com/GG00/PP00,点击Settings,然后选择Members.
在“Add a new member to PP00”中选择添加的用户、权限、期限,添加到项目。
3.3 开发人员使用指南(Git在团队当中的使用流程)
3.3.1 GIT简介
Git是一个分布式版本管理系统,是为了更好地管理Linux内核开发而创立的。Git可以在任何时间点,把文档的状态作为更新记录保存起来。因此可以把编辑过的文档复原到以前的状态,也可以显示编辑前后的内容差异。而且,编辑旧文件后,试图覆盖较新的文件的时候(即上传文件到服务器时),系统会发出警告,因此可以避免在无意中覆盖了他人的编辑内容。
使用版本管理的共享文件操作实例
Git的数据库分为远程数据库和本地数据库的两种。
· 远程数据库: 配有专用的服务器,为了多人共享而建立的数据库。
· 本地数据库: 为了方便用户个人使用,在自己的机器上配置的数据库。
数据库分为远程和本地两种。平时用手头上的机器在本地数据库上操作就可以了。如果想要公开在本地数据库中修改的内容,把内容上传到远程数据库就可以了。另外,通过远程数据库还可以取得其他人修改的内容。
3.3.2 用户申请
1、GIT用户使用公司邮箱账户密码登录,GIT帐号需要手工进行激活,首次使用请用户登录:http://zfgit.neusoft.com 登录后即可激活本人GIT用户
2、项目人员申请Git配置库权限,由项目负责人统一发给部门配置管理员进行授权,如大区人员需要使用GIT由项目负责人发送邮件给所在开发部长、贺晓明老师抄送部门CML,审批通过后方可授权,发送邮件要求如下:
申请账户的格式为
姓名:某某
所在部门:华北大区
职务:开发人员、实施人员、测试人员
项目组:xx公共服务项目xx_ggfw
子系统名:xx-hospitals
项目负责人:某某某
账户授权完毕后,会进行邮件通知,反馈邮件里包括完成情况、仓库名等。
3、人员退出项目应由项目负责人将人员信息发送给配置管理员进行去除Group 或Project member权限。
4、人员离职应由配置管理人员将人员权限去除并锁定账户状态Blocked。
5、为保证信息安全项目负责人、部门配置管理员应定期审计权限列表以便去除非项目内人员。
3.3.3 从客户端访问
从客户端访问:http://zfgit.neusoft.com/users/sign_in
3.3.4 修改用户信息
登录后点击图标——点击 Settings
可维护本人基本信息
3.3.5 显示项目
登录后将可以查看到用户拥有权限的项目和Public项目(通过Browse project查看)
3.3.6 显示项目动态
3.3.7 项目Commit明细
3.3.8 GIT命令操作流程
3.3.9 GIT工作流程
我们推荐项目使用GitLab Flow开发流程,在这种开发流程中开发人员将本地开发完毕的内容提交到默认分支master上,进行持续集成。
3.3.10 安装 GIT 客户端
GIT客户端软件和相关文档找部门配置管理员咨询。
3.4 GIT 常用命令行
3.4.1 git init
新建代码库,在当前目录新建一个Git代码库
git init
新建一个目录,将其初始化为Git代码库
git init [project-name]
下载一个项目和它的整个代码历史
git clone [url]
初始化 GIT,只有初始化了以后才可以使用 GIT 相关命令。在初始化之前,可以先创建一个文件夹。如下示例
$ mkdir lmlphp
$ cd lmlphp
$ git init
3.4.2 git branch
列出所有本地分支
git branch
列出所有远程分支
git branch -r
列出所有本地分支和远程分支
git branch -a
新建一个分支,但依然停留在当前分支
git branch [branch-name]
新建一个分支,并切换到该分支
git checkout -b [branch]
新建一个分支,指向指定commit
git branch [branch] [commit]
新建一个分支,与指定的远程分支建立追踪关系
git branch --track [branch] [remote-branch]
切换到指定分支,并更新工作区
git checkout [branch-name]
切换到上一个分支
git checkout -
建立追踪关系,在现有分支与指定的远程分支之间
git branch --set-upstream [branch] [remote-branch]
合并指定分支到当前分支
git merge [branch]
选择一个commit,合并进当前分支
git cherry-pick [commit]
删除分支
git branch -d [branch-name]
删除远程分支
git push origin --delete [branch-name]
git branch -dr [remote/branch]
C:\Users\May\Documents\GitHub\test> cd .\LMLPHP
C:\Users\May\Documents\GitHub\test\LMLPHP [master]> git branch -av
* master 405960a session_write_close() when fatal error occured
remotes/origin/HEAD -> origin/master
remotes/origin/develop 405960a session_write_close() when fatal error occured
remotes/origin/master 405960a session_write_close() when fatal error occured
C:\Users\May\Documents\GitHub\test\LMLPHP [master]> git branch develop
C:\Users\May\Documents\GitHub\test\LMLPHP [master]> git branch -av
develop 405960a session_write_close() when fatal error occured
* master 405960a session_write_close() when fatal error occured
remotes/origin/HEAD -> origin/master
remotes/origin/develop 405960a session_write_close() when fatal error occured
remotes/origin/master 405960a session_write_close() when fatal error occured
C:\Users\May\Documents\GitHub\test\LMLPHP [master]>
3.4.3 git clone
获取远程项目,并下载到本地。远程库的地址在 GITLAB项目中会有提供。下面是我测试时显示的内容,若执行成功,则将显示同下面类似的内容。
C:\Users\dingn>cd d:\git
C:\Users\dingn>d:
d:\git> git clone http://zfgit.neusoft.com/GG00/PP00.git
Cloning into 'PP00'...
remote: Counting objects: 18, done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 18 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (18/18), done.
Checking connectivity... done.
d:\git>
3.4.4 git add
添加指定文件到暂存区
git add [file1] [file2] ...
添加指定目录到暂存区,包括子目录
git add [dir]
添加当前目录的所有文件到暂存区
git add .
添加每个变化前,都会要求确认
对于同一个文件的多处变化,可以实现分次提交
git add –p
git add
命令用来增加更新的内容,后面的参数为目录名或者文件名,一般在 git commit 命令之前使用。通过 git diff 可以查看有哪些不同之处,只有被增加的更新才会被提交到版本库。
git add
后可以接要跟踪的文件或目录的路径。如果是目录的话,就说明要递归跟踪所有该目录下的文件。
git add
命令(这是个多功能命令,根据目标文件的状态不同,此命令的效果也不同:可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等)。
F:\test\xxx_clone\ding>git add README
F:\test\xxx_clone\ding>git status README
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README
再次修改内容后
F:\test\xxx_clone\ding>git status README
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: README
3.4.5 git checkout
git checkout 命令用于创建分支和切换分支。*号代表当前分支,下面通过 checkout 命令切换到 develop 分支。"checkout"在英文中的意思是检出,但是也不难理解,GIT 中分支其实就是一个指向,速度很快;现在我的本地有两个分支,但是只有一份代码,当使用 checkout 命令切换分支并且两个分支的内容不同时,你会发现磁盘上的文件内容即刻发生了变化。checkout 命令还可以用来创建分支并切换到这个分支,使用 checkout -b 参数即可,下面的例子使用此命令创建了 newFeature 分支并切换到了这个分支。
C:\Users\May\Documents\GitHub\test\LMLPHP [master]> git checkout develop
Switched to branch 'develop'
C:\Users\May\Documents\GitHub\test\LMLPHP [develop]> git branch -av
* develop 405960a session_write_close() when fatal error occured
master 405960a session_write_close() when fatal error occured
remotes/origin/HEAD -> origin/master
remotes/origin/develop 405960a session_write_close() when fatal error occured
remotes/origin/master 405960a session_write_close() when fatal error occured
C:\Users\May\Documents\GitHub\test\LMLPHP [develop]> git checkout -b newFeature
Switched to a new branch 'newFeature'
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]> git branch -av
develop 405960a session_write_close() when fatal error occured
master 405960a session_write_close() when fatal error occured
* newFeature 405960a session_write_close() when fatal error occured
remotes/origin/HEAD -> origin/master
remotes/origin/develop 405960a session_write_close() when fatal error occured
remotes/origin/master 405960a session_write_close() when fatal error occured
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]>
3.4.6 git status
显示有变更的文件
git status
git status 命令用来查看当前分支状态。如下示例:
f:\test\xxx_clone>git status
fatal: Not a git repository (or any of the parent directories): .git
非受控文件
f:\test\xxx_clone>cd F:\test\xxx_clone\xxx
F:\test\xxx_clone\xxx>git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
未有任何更改
F:\test\xxx_clone\xxx>git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: README
no changes added to commit (use "git add" and/or "git commit -a")
已经修改未提交
3.4.7 git diff
显示暂存区和工作区的差异
git diff
显示暂存区和上一个commit的差异
git diff --cached [file]
显示工作区与当前分支最新commit之间的差异
git diff HEAD
显示两次提交之间的差异
git diff [first-branch]...[second-branch]
显示今天你写了多少行代码
git diff --shortstat "@{0 day ago}"
git diff比较已经上传和本地暂存版本
F:\test\xxx_clone\xxx>git diff README
diff --git a/README b/README
index 1a017ad..cad650a 100644
--- a/README
+++ b/README
@@ -1,2 +1,3 @@
readme
-readme2
\ No newline at end of file
+readme2
+readme3
\ No newline at end of file
git diff --cached 比较已经暂存和上次提交时内容
F:\test\xxx_clone\xxx>git diff --cached README
diff --git a/README b/README
index e69de29..1a017ad 100644
--- a/README
+++ b/README
@@ -0,0 +1,2 @@
+readme
+readme2
\ No newline at end of file
3.4.8 git pull
取回远程仓库的变化,并与本地分支合并
git pull [remote] [branch]
git pull 命令用来更新代码,该命令相当于 git fetch 和 git merge 的组合。需要注意的是,如果来源是远程分支 develop,则必须这样写“origin develop”,origin 后面有个空格。如果远程分支存在有和当前分支一样的名字,则可以不指定分支。如下示例:
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]> git pull
Warning: Permanently added 'github.com,192.30.252.130' (RSA) to the list of know
n hosts.
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/ newFeature
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]> git pull origin develop
Warning: Permanently added 'github.com,192.30.252.130' (RSA) to the list of know
n hosts.
From github.com:leiminglin/LMLPHP
* branch develop -> FETCH_HEAD
Already up-to-date.
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]>
3.4.9 git push
上传本地指定分支到远程仓库
git push [remote] [branch]
强行推送当前分支到远程仓库,即使有冲突
git push [remote] --force
推送所有分支到远程仓库
git push [remote] --all
git push 命令用来推送更新到远程库,此命令一般在 commit 命令之后使用。如果远程没有对应的分支名,则需要通过设置参数“--set-upstream”指定提交到哪个分支。如下示例:
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]> git push
fatal: The current branch newFeature has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin newFeature
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]> git push --set-upstream
origin develop
Warning: Permanently added 'github.com,192.30.252.130' (RSA) to the list of know
n hosts.
Branch develop set up to track remote branch develop from origin.
Everything up-to-date
3.4.10 git commit
代码提交
提交暂存区到仓库区
git commit -m [message]
提交暂存区的指定文件到仓库区
git commit [file1] [file2] ... -m [message]
提交工作区自上次commit之后的变化,直接到仓库区
git commit -a
提交时显示所有diff信息
git commit -v
使用一次新的commit,替代上一次提交
如果代码没有任何新变化,则用来改写上一次commit的提交信息
git commit --amend -m [message]
重做上一次commit,并包括指定文件的新变化
git commit --amend [file1] [file2] ...
如下示例:
C:\Users\May\Documents\GitHub\test\LMLPHP [newFeature]> git commit -m "test"
On branch newFeature
nothing to commit, working directory clean
3.4.11 git rm
删除工作区文件,并且将这次删除放入暂存区
git rm [file1] [file2] ...
停止追踪指定文件,但该文件会保留在工作区
git rm --cached [file]
3.4.12 git mv
改名文件,并且将这个改名放入暂存区
git mv [file-original] [file-renamed]
3.4.13 git tag
列出所有tag
git tag
新建一个tag在当前commit
git tag [tag]
新建一个tag在指定commit
git tag [tag] [commit]
删除本地tag
git tag -d [tag]
删除远程tag
git push origin :refs/tags/[tagName]
查看tag信息
git show [tag]
提交指定tag
git push [remote] [tag]
提交所有tag
git push [remote] --tags
新建一个分支,指向某个tag
git checkout -b [branch] [tag]
3.4.14 .gitignore
.gitignore 的格式规范如下:
• 所有空行或者以注释符号 # 开头的行都会被 Git 忽略。
• 可以使用标准的 glob 模式匹配。
• 匹配模式最后跟反斜杠(/)说明要忽略的是目录。
• 要忽略指定模式以外的文件或目录,可以在模式前加上惊叹号(!)取反。
所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。星号(*)匹配零个或多个任意字符;[abc] 匹配
任何一个列在方括号中的字符(这个例子要么匹配一个 a,要么匹配一个 b,要么匹配一个 c);问号(?)
只匹配一个任意字符;如果在方括号中使用短划线分隔两个字符,表示所有在这两个字符范围内的都可以匹配
(比如 [0-9] 表示匹配所有 0 到 9 的数字)。
*.[oa] 忽略所有以 .o 或 .a 结尾的文件。
*~ 忽略所有以波浪符(~)结尾的文件
我们再看一个 .gitignore 文件的例子:
此为注释 – 将被 Git 忽略
*.a # 忽略所有 .a 结尾的文件
!lib.a # 但 lib.a 除外
/TODO # 仅仅忽略项目根目录下的 TODO 文件,不包括 subdir/TODO
build/ # 忽略 build/ 目录下的所有文件
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
3.4.15 .gitconfig
配置
Git的设置文件为.gitconfig,它可以在用户主目录下(全局配置),也可以在项目目录下(项目配置)。
显示当前的Git配置
git config --list
编辑Git配置文件
git config -e [--global]
设置提交代码时的用户信息
git config [--global] user.name "[name]"
git config [--global] user.email "[email address]"
3.4.16 git log
显示当前分支的版本历史
git log
显示commit历史,以及每次commit发生变更的文件
git log --stat
搜索提交历史,根据关键词
git log -S [keyword]
显示某个commit之后的所有变动,每个commit占据一行
git log [tag] HEAD --pretty=format:%s
显示某个commit之后的所有变动,其"提交说明"必须符合搜索条件
git log [tag] HEAD --grep feature
显示某个文件的版本历史,包括文件改名
git log --follow [file]
git whatchanged [file]
显示指定文件相关的每一次diff
git log -p [file]
显示过去5次提交
git log -5 --pretty --oneline
显示所有提交过的用户,按提交次数排序
git shortlog -sn
3.4.17 git blame
显示指定文件是什么人在什么时间修改过
git blame [file]
3.4.18 git show
显示某次提交的元数据和内容变化
git show [commit]
显示某次提交发生变化的文件
git show --name-only [commit]
显示某次提交时,某个文件的内容
git show [commit]:[filename]
3.4.19 git reflog
显示当前分支的最近几次提交
git reflog
3.4.20 git fetch
远程同步
下载远程仓库的所有变动
git fetch [remote]
3.4.21 git remote
显示所有远程仓库
git remote -v
显示某个远程仓库的信息
git remote show [remote]
增加一个新的远程仓库,并命名
git remote add [shortname] [url]
3.4.22 git reset
恢复暂存区的指定文件到工作区
git checkout [file]
恢复某个commit的指定文件到暂存区和工作区
git checkout [commit] [file]
恢复暂存区的所有文件到工作区
git checkout .
重置暂存区的指定文件,与上一次commit保持一致,但工作区不变
git reset [file]
重置暂存区与工作区,与上一次commit保持一致
git reset --hard
重置当前分支的指针为指定commit,同时重置暂存区,但工作区不变
git reset [commit]
重置当前分支的HEAD为指定commit,同时重置暂存区和工作区,与指定commit一致
git reset --hard [commit]
重置当前HEAD为指定commit,但保持暂存区和工作区不变
git reset --keep [commit]
新建一个commit,用来撤销指定commit
后者的所有变化都将被前者抵消,并且应用到当前分支
git revert [commit]
暂时将未提交的变化移除,稍后再移入
git stash
git stash pop
3.4.23 git archive
生成一个可供发布的压缩包
git archive
3.4.24 总结
GIT BASH 的功能非常强大,使用也非常方便,特别适合大型项目多人同时开发。图形界面工具虽然方便简单,但是效率远远不能跟命令行相比。本文简单的介绍了 GIT BASH 的使用,更多的功能请使用 --help 命令查看,系统会使用浏览器打开 HTML 版本文档,描述的非常详细。
3.5 Git GUI使用方法
3.5.1 概述
GIT操作流程:
3.5.2 初始化(Git init)
顾名思义,就是新建一个项目。在你新建好的文件夹中右键创建即可,若点击Git bash则以此目录作为当前目录进入命令行状态。
3.5.3 添加(Git add)
添加并不是提交代码到远程Git库,Git也并不会你修改了代码它自动帮你保存你修改的每一个过程。你修改了很多文件,但未必所有的修改,最终打算提交上去,那么哪些是你打算提交的,你可以添加进来待会提交,叫做缓存改动。很简单,比如本地电脑上我有整个项目完整的东东,甚至包含了账号密码的一些文件,但是我只是ADD除账号密码之外的文件,并不缓存账号密码文件的改动。不被ADD它就不会参与后续的操作。通常我都会直接全部缓存,它会自动寻找所有有改动的文件,而不需要提交的文件放在忽略的文件夹中。
3.5.4 忽略(.gitignore)
但实际上大部分我们的文件都是一起提交的,并不会逐一去甄选,又或者类似PSD这样的大源文件以及并不作为产品最终展示的过渡文件,我们可以统一放在临时文件夹中,并忽略此文件夹。
3.5.5 提交(Git commit)
提交则代表此前被添加ADD的文件已确认被提交到Git库了。需要注意的是,如果你改变代码的缩进(尽管没有修改内容),默认状态下会被识别为整个代码全部变更。提交的时候是要求必须要写备注的。
3.5.6 上传(Git push)
顾名思义,上传则是上传至远端服务器了,使其他开发人员可以看到上传的代码。
3.5.7 获取远程代码(Git remote/fetch pull - fetch)
先来设置与远程地址的关联,Git remote:
填写SSH地址与项目名。下面有3个选项:
第一个:立刻获取最新改动(所以如果是本地克隆远程一个项目,也可以这样操作)。
第二个:本地新建的项目,初始化远程仓库并发布过去。
第三个:什么也不做。
在项目的进行过程中,获取仓库的最新改动Git fetch
选择从远程仓库哪个分支中获取更新,如果没有则只有主支。
提示成功则改动的已经被存放到临时区了,你一会还需要进行合并操作,如果没有任何改动,则列表中是空的,比如:
3.5.8 合并(Git merge pull - merge)
注意:不管本地有没有代码,fetch之后呢,是都要merge的,也就是说,fetch下来后,大大的代码还在一个小黑屋里,我们需要把它装到自己兜里。
选择合并 - 本地合并,然后选择本地的分支(如果你没有创建分支,则只有1个主支master)
3.5.9 冲突处理(Conflict)
合并的过程中可能会出现一些红色的文件与一堆叹号,这时候慌慌张张的点啥它都不管用,不用担心,不是程序坏了,只是有冲突的文件,例如A人员写了width:1180px,B人员写了width:auto。那到底用你们谁的呢。
在GUI界面正文区,正文区右键可以选择,Use local version(使用本地版本)或Use remote version(使用远程版本),到底用你的还是其他开发人员的?或者你也可以自己再整合。
其他还有分支和一些高级功能,如果需要了解可以自己再摸索摸索,以上的操作已经可以满足简单的开发需求了。
3.5.10 查看历史(History)
右键点击鼠标选择“Git History”:
4 附:参考文献及扩展阅读
参考文献及扩展阅读:
Git Book: https://git-scm.com/book/zh/v2
常用git命令清单:http://blog.csdn.net/irean_lau/article/details/51643791
猴子都能懂的GIT入门:http://backlogtool.com/git-guide/cn/
廖雪峰的git教程:
http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000