Git介绍
- Git是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。
- Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
1 基本配置
1.1 用户信息
开发人员的用户信息请使用中文拼音全拼写法,比如“Zhang San”、“Li Si”这样的,注意姓和名首字母大写,中间留一空格,电子邮件地址统一填写公司邮箱,比如“zhangsan@company.cn”。 命令行如下:
git config --global user.name "用户信息"
git config --global user.email "邮箱"
1.2 环境配置
Windows 由于权限系统和 macOS 有差异,换行也有所不同,所以对于 Windows 平台使用 Git 需要进行下列配置:
git config --global core.filemode false
git config --global core.autocrlf false
如果是 macOS 系统,则只需要执行:
git config --global core.autocrlf false
修改完成后可以通过 git config --global -l 查看是否改动成功,请注意一下。
在项目开发中,如果改变了文件或文件夹名称的大小写,默认情况下 git 是无法检测到的,请各位执行以下命令关闭大小写忽略。
git config --global core.ignorecae false
2 关于Git分支
分支功能是 git 最为强大的功能之一,它能够让你并发地在多个场景下进行开发。并且可以让你同时开发不同功能而不冲突,用于区分功能或版本
长期分支:
master:主分支 可发布的稳定版分支,存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的发布版本
develop:开发分支用于日常开发,存放最新的开发版
公共的开发主线分支,feature 功能分支的代码开发完成后,经过 code review 后会合并到此分支
临时分支:一旦完成开发,它们就会被合并进develop或master,然后被删除。
feature branch:功能分支 一般是从 develop 开发分支上检出(checkout)
hotfix branch:补丁分支 紧急修复,一般是用于修复上线后的生产环境的问题
release branch:预发分支 测试、发布主线,此分支是从 develop 分支上检出(checkout), 一般是提测阶段会使用该分支的代码
2.1 主分支和开发分支
主分支命名为master,有且只有一个分支,所有正式版本都必须从master分支发布,并且又相关发布的Tag,master分支只能从其它分支合并,不能在这个分支上修改,禁止直接向 master 分支 Push 代码;
日常开发分支命名为 develop,有且只有一个分支,原则上并行开发的时候,develop 分支承担改动最大的方向,比如进行大规模的代码重构、界面框架替换、大版本升级或者日常常规迭代升级等等。
2.2 临时分支之功能分支
对于较大的功能版本升级,划分不同的功能分支feature进行管理,一方面便于功能测试,另外一方面便于需求变更对应的代码变更调整。【当前仅使用在本地分支,不要上传到服务器,减少代码冲突带来的工作量】
命名为feature-*,后面的命名可以是小版本号,或者功能,或者较大任务的Jira ID号,feature-{KaTeX parse error: Expected 'EOF', got '}' at position 17: …uild_version_id}̲,或者是feature-{Ji…featureName}如:feature-logedit,从develop分支拉出来处理。
处理完成后,代码合并回develop分支一起提交服务器,合并后删除该临时分支。
2.3 临时分支之补丁分支
对于正在主线上处理,但是需要临时支援另外一个bug或者是另外事件触发,可以单独发布该分支。
命名为hotfix-*,命名可以是临时处理的事件标识或者JiraID,如:hotfix-{![JiraID}、hotfix-{$eventName},需要从master分支拉出一个补丁分支临时修改。
修改完后合并到release分支预发布以及master分支发布,合并完后删除该临时分支。
2.4 临时分支之预发布分支
对于发布的版本,需要发布到预发布环境进行验收,按版本号进行标识。
命名为release-*,命名需要根据版本,比如release-{KaTeX parse error: Expected 'EOF', got '}' at position 11: version_id}̲,或者是临时发布的版本rele…version_id}-{$jiraID/eventName},需要从其它分支(develop或hotfix)合并过来。
预发布后再进行master合并。
2.5 同一个代码仓库多个开发分支
对于多个服务共享一个代码仓库的情况,开发过程需要按服务分别拉分支开发,严禁都提交到Develop分支。
命名为“服务标识-dev”,当作Develop开发分支处理,最后发布页需要合并到master分支。
2.6 各分支示意图以及流程图:
3 代码提交
做完一件事情即可提交代码,提交的备注文字尽量准确、简洁,不要同时提交多件事情的代码。
提交commit的注释文字,需要简单扼要,且充分考虑影响范围,不要遗漏提交功能实现的描述。
Commit注释规范,不同情形下区别:
以下是简书上抄下来的,咱们重新规范下,按中文命名更容易记住:
- feat【新增】: Feature的缩写, 新的功能或特性
- fix【bug修复】: bug的修复
- docs【文档】: 文件修改, 比如修改应用了ngDoc的项目的ngDoc内容
- style【界面】: 格式修改. 比如改变缩进, 空格, 删除多余的空行, 补上漏掉的分号. 总之, 就是不影响代码含义和功能的修改
- refractor【重构】: 代码重构. 一些不算修复bug也没有加入新功能的代码修改
- perf【优化】: Performance的缩写, 提升代码性能
- test【测试】: 测试文件的修改
- chore【其它】: 其他的小改动. 一般为仅仅一两行的改动, 或者连续几次提交的小改动属于这种
如果有版本号,可增加版本号标识,整体更整洁 commit 模板 ps: 首字母小写,并且结尾不加句号, 使用半角(英文)符号
git commit -m '<type>(<scope>): <subject> [<issue_id>]'
git commit -m '新增(影响全局select组件UI样式): 更改了select组件动画效果 [issue-123]'
- type: 分支行为
- scope: 说明 commit 影响的范围,比如数据层,控制层,视图层等等,这个需要视具体场景与项目的不同而灵活变动
- subject: 对于该 commit 目的的简短描述
- issue_id: 如果你的改动是针对git中的issue进行,请将issue_id添加到commit 记录中
3.1 .gitignore文件
这个文件会配置忽略文件列表,请尽量放在工程的根目录下,除了无需提交的临时文件、编译输出等数据之外,本地用户相关的一些配置也可以加入忽略列表。
3.2 每日构建
每日构建服务器一般会基于 release 分支进行,如果确定版本可以发布后,代码会 merge 到 master 以及 develop 分支,然后通过 master 分支构建发布版本。
日常开发中也可以考虑开启 develop 分支的每日构建,但原则上同一时间段只允许开启一个分支的每日构建。
4 代码发布
4.1 申请master分支合并:
从gitlab中可直接申请master合并,并由仓库管理员负责合并;
4.2 申请版本发布:
在发布前的测试环境上,从对应的开发分支进行测试环境构建,至于测试环境规划,另外篇章说明。【开发联调与测试并行时候,需要考虑环境区分】
5 Git仓库命名规范
项目名称请用大写,空间是部门命名,默认是CPStudio。
分类:
默认系统入口代码,都以系统缩写命名,比如CPStudio/EKP
前后端分离的api,以系统加_api命名,比如CPStudio/EKP_API
后端定时任务系统,以系统缩写加_task,比如CPStudio/EKP_TASK
其它类别的子系统,以下划线加有子系统含义的缩写字母,比如CPStudio/EKP_RES,代表了EKP系统的模板库资源。
6 便于 code review 的合作流程
在编写代码的时候,为了代码的高质量与开发人员的知识共享,通常会加上代码审查也就是 code review 环节。这个环节是借助 merge request 或者 pull request 来做到的,所以我们提交的 commit 记录应该尽量保持为一个,这样的好处有很多:
方便代码审核者进行 code review,只需要看这一个 commit 记录的逻辑即可, 万一该 commit 的代码导致出现问题,我们可以只针对这个 commit 进行快速回退。 一个功能保持一个 commit 记录如果遇到需要对这个功能提前提交到某些环境比如生产环境上,我们可以快速用过 cherry-pick 命令,在对应的分支上"重现"该提交记录,达到提前提交的目的。
也许你会有疑问,单个功能保持一个 commit 记录与 commit 提交记录尽量保持较细的粒度这一原则是否相悖,笔者觉得并没有冲突,因为这两个 git 协作要求是基于不同的角度来看待问题的,对于自己开发的分支上,我们需要保持每个提交的粒度在一个 commit 做一个修改,这样有利于我们记录工作内容与方便自己在本分支上做回滚,但是对于一个软件开发的主分支来说,它上面的提交应该是以功能为单位的,而无需关心这个功能内开发人员开发这个功能做了多少次修改。
面对这种情况,我们会使用 rebase 命令,也就是衍合(变基)操作。所谓衍合就是将你此分支上的 commit 提交,按顺序重新在某个分支上的某个基础点重新"演绎"一次,而这个重新"演绎"重新提交的 commit 记录与原来的 commit 提交会有些许不同,不同点在于 commit 的 HashId 会不同,但是提交内容是一样的。
rebase 命令提供了交互式的界面,并且提供多种的命令让你能够将多个 commit 记录合并为一个,从而达到我们单一功能保持一个 commit 记录的目的,保持提交历史的清爽。
7 git命令
Git 常用的是以下 6 个命令:git clone、git push、git add 、git commit、git checkout、git pull,当然还有很多命令,可以去官网查
- git clone:拷贝一份远程仓库,也就是下载一个项目。
- git push origin master:将文件给推到服务器上
- git add .:添加当前目录的所有文件到暂存区
- git commit -m “提交文件信息”:提交暂存区到仓库区
- git checkout [branch name]:切换到指定分支,并更新工作区
- git pull:本地与服务器端同步
8 SSH与HTTPS的区别
最后咱们回归主题,对于 clone 项目,在管理Git项目上,很多时候都是直接使用https url克隆到本地,当然也有有些人使用SSH url克隆到本地。
这两种方式的主要区别在于:
- 使用https url克隆对初学者来说会比较方便,复制https url然后到git Bash里面直接用clone命令克隆到本地就好了,但是每次fetch和push代码都需要输入账号和密码,这也是https方式的麻烦之处。
- 而使用SSH url克隆却需要在克隆之前先配置和添加好SSH key,因此,如果你想要使用SSH url克隆的话,你必须是这个项目的拥有者。否则你是无法添加SSH key的,另外ssh默认是每次fetch和push代码都不需要输入账号和密码,如果你想要每次都输入账号密码才能进行fetch和push也可以另外进行设置。