git工作原理及提交规范【干货】

 阅读约 12 分钟

前言

官方解释:Git(读音为/gɪt/。)是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKe

Git 保存的不是文件的变化或者差异,而是一系列不同时刻的文件快照。在进行提交操作时,Git 会保存一个提交对象(commit object)。该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样,该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。

git安装

Linux上安装

sudo yum install git

MAC上安装

如果你正在使用Mac做开发,有两种安装Git的方法。

一是安装homebrew,然后通过homebrew安装Git,具体方法请参考homebrew的文档:http://brew.sh/

第二种方法更简单,也是推荐的方法,就是直接从AppStore安装Xcode,Xcode集成了Git,不过默认没有安装,你需要运行Xcode,选择菜单“Xcode”->“Preferences”,在弹出窗口中找到“Downloads”,选择“Command Line Tools”,点“Install”就可以完成安装了。

image-20191203154844055

window上安装

在Windows上使用Git,可以从Git官网直接下载安装程序,(网速慢的同学请移步国内镜像),然后按默认选项安装即可。

安装完成后,在开始菜单里找到“Git”->“Git Bash”,蹦出一个类似命令行窗口的东西,就说明Git安装成功!

git设置

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

因为Git是分布式版本控制系统,所以,每个机器都必须自报家门:你的名字和Email地址。你也许会担心,如果有人故意冒充别人怎么办?这个不必担心,首先我们相信大家都是善良无知的群众,其次,真的有冒充的也是有办法可查的。

注意git config命令的--global参数,用了这个参数,表示你这台机器上所有的Git仓库都会使用这个配置,当然也可以对某个仓库指定不同的用户名和Email地址。

git存储

git分区

git存储分成四个部分

image-20191203160845685

  1. workspace:工作空间(我们的开发代码目录)
  2. index: 暂存区,.git目录下的index文件
  3. Repository:本地仓库,通过git clone将远程的代码下载到本地;代码库的元数据信息在根目录下的.git目录下
  4. Remote:远程仓库(比如GitHub就是一个远程仓库)

整个过程就是:

  1. 工作区--git add--暂存区--git commit--本地仓库-- git push--远程仓库
  2. 远程仓库区–-fetch–-使用refsremotes下对应分支文件记录远程分支末端commit_id 和 本地仓库区 --merge–-工作区
  3. 远程仓库区–-pull–-使用refsremotes下对应分支文件记录远程分支末端commit_id and 本地仓库区 and 工作区

git fetch和git pull的区别

git fetch:是将远程主机的最新内容拉到本地,用户在检查了以后决定是否合并到工作本机分支中。具体操作如下:

git  fetch origin master:temp 
//本地新建一个temp分支,并将远程origin仓库的master分支代码下载到本地temp分支
git diff temp
//比较远程代码与本地代码的区别
git merge temp
//将temp分支合并到本地master分支
git branch -d temp
//如果不想保留分支,可以将其删除

git pull:基于本地的FETCH_HEAD记录,比对本地的FETCH_HEAD与远程仓库的版本号,然后git fetch获得当前的远程分支的后续版本的数据,然后利用git merge将其与本地的分支合并,可以认为是git pullgit fetchgit merge两个步骤的合并。
实际的git pull过程可以理解为:

git fetch origin master  //将远端的master分支拉取最新内容
git merge FETCH_HEAD //将拉取的最新内容与当前分支合并

git pull用法:

git pull <远程主机名>  <远程分支名>:<本地分支名>
//将远程主机的某个分支,与本地的指定分支合并

git pull合并后可能会出现冲突,需要手动解决冲突。
出现的错误提示如下

error: Your local changes to the following files would be overwritten by merge:
Please commit your changes or stash them before you merge.
//更新的代码与本地的修改代码有冲突,先提交你的改变或者先将本地修改暂存起来

解决冲突的方式:先将本地的代码暂存

git stash //先将本地修改暂存起来
git stash list  //查看保存信息
git pull     //拉取内容
git stash pop   //还原暂存的内容

git status

image-20191203172915929

  1. Changes to be committed:代表被add的文件,被加载到了暂存区
  2. Changes not staged for commit:代表在当前分支中被修改的文件,还没有被add,存储在工作区

git内部存储

本地git项目里面的.git目录下的文件如下:

image-20191203170339993

  1. refs:存储git各种引用的目录,包含分支、远程分支和标签
  2. objects:是存储git各种对象及备用的对象库,包含正常的压缩和压缩后的
  3. info:存储git信息的目录,比如判处特定后缀的文件
  4. index:暂存区
  5. hooks:存储git钩子的目录,钩子只在特定事件发生时触的脚本,比如:提交之前,提交之后
  6. description:项目描述
  7. config:代码库几倍的配置文件
  8. ORIG_HEAD:针对某些 危险操作 ,Git通过记录HEAD指针的上次所在的位置ORIG_HEAD提供了回退的功能。当你发现某些操作失误了,比如错误的reset到了一个很早很早的版本,可以使用 git reset --hard ORIG_HEAD回退到上一次reset之前。
  9. HEAD:代码库当前分支的指向
  10. FETCH_HEAD: 是一个版本链接,记录在本地的一个文件中,指向着目前已经从远程仓库取下来的分支的末端版本。
  11. COMMIT_EDITMSG:commit编辑

git提交规则

对于一个英文水平有限的IT人员在项目中很多时候使用git commit, message往往会写的不尽如人意,或者当你使用git log时往往不知道之前提交的是什么东西,修改了什么,这样对以后的查看很不友好。git 提交有一个成熟的工具(Commitizen)

commit的作用

  1. 提供更多的历史信息,方便快速浏览。
  2. 可以过滤某些commit(比如文档改动),便于快速查找信息
  3. 可以直接从commit生成Change log。

commitizen安装使用

安装

npm install -g commitizen

package.json配置

{
    "name": "application-name",
    "version": "0.1.0",
    "scripts": {
      "commitmsg": "validate-commit-msg",
      "commit": "git-cz ",
      "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
    },
    "devDependencies": {
      "commitizen": "^2.3.0",
      "validate-commit-msg": "^2.11.1",
      "conventional-changelog-cli": "^1.2.0",
      "husky": "^0.13.1"
    }
}

新建.vcmrc文件,添加内容如下

{
  "helpMessage": "\nPlease fix your commit message (and consider using https://www.npmjs.com/package/commitizen)\n",
  "types": [
    "feat",
    "fix",
    "docs",
    "style",
    "refactor",
    "perf",
    "test",
    "chore",
    "revert"
  ],
  "warnOnFail": false,
  "autoFix": false
}

commit规范

每次提交,Commit message 都包括三个部分:header,body 和 footer。

<type>(<scope>): <subject> #header
// 空一行
<body>
// 空一行
<footer> 

commit type

  1. feat: 新增 feature
  2. fix: 修复 bug
  3. docs: 仅仅修改了文档,比如 README, CHANGELOG, CONTRIBUTE等等
  4. style: 仅仅修改了空格、格式缩进、逗号等等,不改变代码逻辑
  5. refactor: 代码重构,没有加新功能或者修复 bug
  6. perf: 优化相关,比如提升性能、体验
  7. test: 测试用例,包括单元测试、集成测试等
  8. chore: 改变构建流程、或者增加依赖库、工具等
  9. revert: 回滚到上一个版本

git分支与版本发布规范

  1. 基本原则:master为保护分支,不直接在master上进行代码修改和提交。
  2. 开发日常需求或者项目时,从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复,功能测试完毕并且项目发布上线后,将feature分支合并到主干master,并且打Tag发布,最后删除开发分支。分支命名规范:

    • 分支版本命名规则:分支类型 分支发布时间 分支功能。比如:feature_20170401_fairy_flower
    • 分支类型包括:feature、 bugfix、refactor三种类型,即新功能开发、bug修复和代码重构
    • 时间使用年月日进行命名,不足2位补0
    • 分支功能命名使用snake case命名法,即下划线命名。
  3. Tag包括3位版本,前缀使用v。比如v1.2.31。Tag命名规范:

    • 新功能开发使用第2位版本号,bug修复使用第3位版本号
    • 核心基础库或者Node中间价可以在大版本发布请使用灰度版本号,在版本后面加上后缀,用中划线分隔。alpha或者belta后面加上次数,即第几次alpha:

      • v2.0.0-alpha.1
      • v2.0.0-belta.1
  4. 版本正式发布前需要生成changelog文档,然后再发布上线。
阅读 2.1k更新于 12月4日
推荐阅读
移动端技术
用户专栏

移动端技术汇总

1463 人关注
52 篇文章
专栏主页
目录