概念

在使用Git前我们需要先安装 Git。Git 目前支持 Linux/Unix、Solaris、Mac和 Windows 平台上运行。

安装配置

1. 安装

Git 各平台安装包下载地址为：http://git-scm.com/downloads

2. 配置

// 配置个人的用户名称和电子邮件地址：
git config --global user.name "zhongtingneng"
git config --global user.email 2213502797@runoob.com

查看git配置信息

git config --list

注意

如果要对配置信息进行修改，重复上述命令即可
配置只需要执行一次

仓库说明文档
在仓库中添加：Readme.md

忽略清单
将不需要被 git 管理的文件名字添加到此文件中，在执行 git 命令的时候，git 就会忽略这些文件。
.gitignore
例子：
提交步骤
```git // 初始化仓库 git init

// 查看文件状态 // git 不会记录你的空文件夹 git status

// 添加文件到仓库 git add 文件列表

// 提交暂存区到本地仓库 git commit -m 提交信息

// 查看提交记录 git log

<a name="IDKFC"></a>
# 基本操作
<a name="C5E08"></a>
## 创建仓库命令
```git
// 初始化仓库
git init
// 拷贝一份远程仓库，也就是下载一个项目。
git clone '项目地址'

提交与修改

// 添加文件到暂存区
git add 文件名 文件名 ...
// 将工作目录中的文件全部添加到暂存区
git add .
// 提交暂存区到本地仓库(当前分支)
git commit -m    提交信息
git commit -am 提交信息 （add+commit）
// 查看仓库当前的状态，显示有变更的文件
git status
// 比较文件的不同，即暂存区和工作区的差异
git diff HEAD -- 文件名
// 删除工作区文件（从版本库中删除该文件，那就用命令 git rm 删掉，并且 git commit ）
git rm 文件名

提交日志

// 查看历史提交记录
git log
// 记录每一次命令
git reflog

Git 标签

git tag -a v1.0

撤销

// 用暂存区中的文件覆盖工作目录中的文件
git checkout 文件
// 丢弃工作区的修改(让这个文件回到最近一次git commit或git add时的状态)
git checkout -- 文件名
// 将 git 仓库中指定的更新记录恢复出来，并且覆盖暂存区和工作目录
// 回退版本（不推荐使用：会覆盖以前的提交记录）
git reset
// 直接回到上一个版本
// 有几个 ^ 就是回退几个版本（不会删掉修改代码）
git reset --hard HEAD^
// 回到指定的版本
git reset --hard commitID
// 撤销指定的提交(推荐使用：不会覆盖以前的提交记录)
git revert <commitID>

远程操作

// 查看远程库
git remote
// 更详细的信息（抓取和推送的origin的地址。没有推送权限，就看不到push的地址。）
git remote -v
// 从远程获取代码库
git fetch
// 下载远程代码并合并
git pull 远程仓库地址 分支名称
// 将远程主机 origin 的 dev 分支拉取过来，与本地的 dev 分支合并。
git pull origin dev:dev
// 上传远程代码并合并
git push 远程仓库地址 分支名称
git push 远程仓库地址别名 分支名称
/*
     强制覆盖（不推荐使用）
*/
git push --force origin master
// 如：git remote add origin起其它名字也可以 远程仓库的地址
git remote add 远程仓库地址别名 远程仓库地址
// 修改远程厂库地址
git remote set-url origin [url]
// 删除远程仓库
git remote rm [别名]

分支管理

使用分支，可以让我们从开发主线上分离出来，以免影响开发主线

分支细分

主分支（master）

第一次向 git 仓库中提交更新记录时自动产生的一个分支

开发分支（develop）

作为开发的分支，基于 master 分支创建。

功能分支（feature）

作为开发具体功能的分支，基于开发分支创建

分支命令

// 查看分支
git branch
// 创建并且切换到dev分支
git checkout -b dev
git switch -c dev（新版git可以使用）
// 创建分支
git branch 分支名称
// 切换分支
git checkout 分支名称
git checkout --file
git switch 分支名称（新版git可以使用）
// 最新版本的Git提供了新的方法
// 创建并且切换到dev分支
git switch -c dev
// 合并分支
git merge 来源分支
// 复制特定的提交到当前分支（提交的多个功能中，某些情况不需要全部合并，这个时候就
使用cherry-pick）
git cherry-pick 4c805e2
// 删除分支（分支被合并后才允许删除）-D 强制删除
git branch -d 分支名称
// 查看分支合并图
git log --graph

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
Git（分布式版本控制系统） - 图2

暂时保存更改

在 git 中，可以暂时提取分支上所有的改动并存储，让开发人员得到一个干净的工作副本，临时转向其他工作。
使用场景：分支临时切换 ```git // 存储临时改动 git stash

// 查看临时改动 git stash list

// 恢复 git stash apply

// 恢复的同时把stash内容删除 git stash pop

<a name="SLmB2"></a>
## 分支规范
| **分支类型** | **用途** | **数量** | **命名规范** |
| --- | --- | --- | --- |
| feature | 业务/技术 需求功能开发 | N | feature/{版本}_{需求}_{姓名} |
| release | 用于集成环境测试、ST环境测试、灰度发布。release分支只有一个，少数场景下需要并行的版本，可以单独再拉一条。 | 1 | release |
| master | 用于发布，打tag | 1 | master |
| hotfix | 用于解决线上问题，开发测试阶段的bugfix请在各自的feature分支上改代码 | N | hotfix/{描述}_{姓名} |
<a name="pBC9X"></a>
# GIT提交规范
<a name="bP900"></a>
## 背景
一方面是客户要求，另一方面通过规范的提交记录可以更方便查找问题，同时 `feat` 与 `fix` 类型的提交可以<br />自动生成 `change log`。
<a name="j9tFR"></a>
## git message 书写规则
在使用 `git commit -m` 时需要遵守以下格式：
```shell
# 格式一：git commit -m '$type: 提交信息'
# 例如：
git commit -m 'feat: 新增评论组件'
git commit -m 'fix: 评论接口未做错误处理'
git commit -m 'docs: git 提交说明文档'
git commit -m 'style: 某某配置 json 文件格式化'
git commit -m 'refactor: 某某文件 Promise 改写为 async await 形式'
git commit -m 'test: 增加 getQuery 函数的单元测试'
git commit -m 'chore: 持续集成流水线新增 lint 步骤'

git 提交类型

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

Git（分布式版本控制系统）

概念