Git在工作中的基本应用
一 Git的起源
Git 的定义
有一句名言 "你要知道 从哪里来，才能知道未来可能通向何方" 。所以我们首先肯定聊的就是 Git的起源。
那么Git 的定义是什么 ？
Git 是一种分布式开源 版本管理工具(VCS)，你可以用它存储代码、跟踪修订历史记录、合并代码更改，并在需要时恢复为较早的代码版本。
版本控制系统发展的三个阶段
CVS 阶段 –> SVN 阶段 –> Git 阶段
- CVS阶段：（整个项目全部备份）项目搭建开发过程中，每次提交项目都会将整个项目提交到服务器进行保存，服务器存储着项目的 N 个备份，开发过程中的协作效率较低，同时也出现了各种传输的问题。同样是开源而且免费的SVN修正了CVS的一些稳定性问题，svs 逐渐被svn取代。
- svn阶段：（对修改进行备份）SVN 是集中式版本管理工具。 SVN 同样也需要搭建服务器，让项目组成员将数据存储在服务器上，但是每次改动并提交的时候，SVN 服务器并不重新保存整个项目的完整信息，而是和原来的项目进行对比，只保存改动的信息。这样就在很大的程度上对于项目版本服务器、项目协作效率有了显著的提升。所以至今为止，有很多公司依然选用 SVN 作为公司内部项目协作的版本控制软件。
- git阶段：分布式版本管理工具。是由 Linus Torvalds (林纳斯·托瓦兹) 创造， 在 git 诞生之前，Torvalds 选择使用 BitKeeper 进行 Linux 版本管理， BitKeeper 是一个闭源的商业软件。2005 年，一位 Linux 开发成员 Andrew（Samba 协议之父）写了一个可以连接 BitKeeper 仓库的外挂，因此 BitMover 公司（BitKeeper 持有者）认为他反编译了 BitKeeper。BitMover 决定中止 Linux 免费使用 BitKeeper 的授权。最终 Linux 团队与 BitMover 磋商无果，Torvalds 决定开发自己的版本管理系统。十天后，git 诞生了。
svn 和 git 有什么区别呢？
关于Linus Torvalds 的传奇人生
二 常见的一些命令
三 工作中一些常见的问题
- git reset 的 --mixed / --hard / --soft 的区别 ？
- git fetch 和 git pull 的区别 ？ (git pull = git fetch + git merge)
- git log 和 git reflog 的区别？
- git中https和SSH的clone方式区别 ？
- 刚提交合并请求的代码，合并申请被驳回了，有需要更改的地方，如何进行操作？
- 如何配置多用户？
- 如何安全的删除所有本地分支？
git branch | grep -v "main" | xargs git branch -D - git reset 和 git revert的区别 ？
git reset 为重置的意思，作用是将 HEAD 指向指定的版本上去
git revert是用来重做某一个 commit 提交的内容，在我们原始的提交之中，我们会发现分支上面有创建了一个新的 commit 提交，而此时我们对于想重做的某个 commit 提交的内容都不存在了。
git revert 一次只能 回退一个commit 提交，如果想要一次性回退多个提交，并且将多个revert回退合并成一个commit
commit 提交： A -> B -> C -> D ，想把 B,C,D 都revert 了
执行 git revert B-commitId^..D-commitId
形成：A-> B ->C -> D -> D'-> C' -> B'
如果想把多个revert 合并成一个提交
git revert -n BcommitId^..DcommitId
git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"
45 个 Git 经典操作场景，专治不会合代码
四 git 的一些配置
- 配置多账号
有时候我们自己有 github 的账号作为个人使用，公司团队使用 gitlab 另一账号，这时我们就需要对同一设备配置多账号 (配置多个git账号) - 配置别名
将一些比较长的命令配置成简单的别名，方便记忆和使用 oh-my-zsh
$ git config --global alias.st status
$ git config --global alias.co checkout
$ git config --global alias.cm "commit -m"
$ git config --global alias.br branch
$ git config --global alias.amend "commit --amend --no-edit"
$ git config --global alias.pick "cherry-pick"
$ git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset %b' --date=format:"%Y-%m-%d %H:%M:%S""
// 配置删除分支 （此配置存在问题）
// 暂时只支持 git branch | grep -v "master" | xargs git branch -D
$ git config --local alias.rmBrs "branch | grep -v "master" | xargs git branch -D"
五 规范化git commit信息
- Commit message 的作用
格式化的 Commit message，有几个好处。
（1）提供更多的历史信息，方便快速浏览。
比如，下面的命令显示上次发布后的变动，每个 commit 占据一行。你只看行首，就知道某次 commit 的目的。
git log --oneline
（2）可以过滤某些 Commit（比如文档改动），便于快速查找信息。
比如，下面的命令仅仅显示本次发布新增加的功能。
git log --grep feature
（3）可以直接从 Commit 生成 Change log
Change Log 是发布新版本时，用来说明与上一个版本差异的文档，详见后文 - Commit message 格式
每次提交，commit message 都包括三个部分：Header，Body 和 Footer。其中，Header 是必需的，Body 和 Footer 可以省略。
( ):
// 空一行
// type 提交的类别
// scope 用于说明提交影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同
// subject 提交目的的简短描述，不超过50个字符
- Header
Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。 - Body
Body 部分是对本次 Commit 的详细描述，可以分成多行。 - Footer
Footer 部分只用于两种情况。
- 不兼容变动
- 如果当前代码与上一个版本不兼容，则 Footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。
- 关闭 Issue，如果当前 Commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue 。Closes #234也可以一次关闭多个 issue 。Closes #123, #245, #992
- Change log
Change Log 是发布新版本时，用来说明与上一个版本差异的文档，一般包含 "Feature","Fix","Performance Improvement"与"Breaking Changes"。
如果你的所有 Commit 都符合 Angular 格式，那么发布新版本时，Change log 就可以用脚本自动生成，方法如下：
全局安装 conventional-changelog-cli
yarn add conventional-changelog conventional-changelog-cli --dev
在你的项目根目录中执行
这不会覆盖任何以前的变更日志。只会在 CHANGELOG.md 的头部加上自从上次发布以来的变动。
在package.json 的script 中配置。执行npm run changelog 即可生成changelog.md文件
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
}
这将覆盖任何以前的更改日志。
/*
- 配置项说明：
- -p angular 指定风格
- -i CHANGELOG.md 指定输出的文件名称
- -s 指定增量更新，不会覆盖以前的更新日志
- -r 0 从最新的版本生成多少个版本的日志，如果为0，则日志将重新生成。
*/
复制代码
生成日志如下图：
- 格式化规范工具 Commitizen
安装 commitizen 和 cz-customizable
npm install -g commitizen@4.2.4
npm install -D cz-customizable@6.3.0
在 package.json 中进行新增
"config": {"commitizen": {"path": "node_modules/cz-customizable"}}
在根目录下新建 .cz-config.js 文件并写入配置
module.exports = {
// 可选类型
types: [
{ value: 'feat', name: 'feat: 新功能' },
{ value: 'fix', name: 'fix: 修复' },
{ value: 'docs', name: 'docs: 文档变更' },
{ value: 'style', name: 'style: 代码格式(不影响代码运行的变动)' },
{ value: 'refactor', name: 'refactor: 重构' },
{ value: 'perf', name: 'perf: 性能优化' },
{ value: 'test', name: 'test: 增加测试' },
{ value: 'chore', name: 'chore: 构建过程或辅助工具的变动' },
{ value: 'revert', name: 'revert: 回退' },
{ value: 'build', name: 'build: 打包' },
{ value: 'ci', name: 'ci: 与持续集成服务有关的改动' },
],
// 消息步骤
messages: {
type: '请选择提交类型:',
customScope: '请输入修改范围(可选):',
subject: '请简要描述提交(必填):',
body: '请输入详细描述(可选):',
footer: '请输入要关闭的issue(可选):',
confirmCommit: '确认使用以上信息提交？(y/n/e/h)',
},
// 跳过问题
skipQuestions: ['footer'],
// subject文字长度默认是72
subjectLimit: 72,
}
复制代码
之后就可以用 git cz 来代替 git commit。
git cz
cz-cli@4.2.4, cz-customizable@6.3.0All lines except first will be wrapped after 100 characters.? 请选择提交类型: (Use arrow keys)> feat: 新功能fix: 修复docs: 文档变更style: 代码格式(不影响代码运行的变动)
refactor: 重构perf: 性能优化test: 增加测试? 请输入修改范围(可选):? 请简要描述提交(必填): 新功能xxx? 请输入详细描述(可选):
? 请输入要关闭的issue(可选):###--------------------------------------------------------###feat: 新功能xxx###--------------------------------------------------------###? 确认使用以上信息提交？(y/n/e/h)复制代码
- cz-customizable 是一款shell插件，无法在 git bash 中正常使用
六 用 Husky 向 Git 添加 Commit Hooks 以实现代码任务的自动化
什么是husky？
Husky是一个工具，它允许我们轻松地处理Git Hooks 并在提交代码时运行我们想要的脚本。
它的工作原理是在我们的 package.json 文件中加入一个对象，配置 Husky 来运行我们指定的脚本。之后，Husky会管理我们的脚本将在Git生命周期的哪个阶段运行。
husky 几乎支持Git定义的所有Git钩子，所以我们可以在Git事件流程中尽可能灵活地使用。
主要的钩子有- pre-commit ：在commit 提交之前
- pre-merge-commit ： 在merge 之前
- post-commit ： 在commit 提交以后
- pre-rebase
- post-rebase
- pre-push
- post-push
用法：
- 项目内安装
yarn add husky -D - 创建.husky/目录并指定该目录为git hooks所在的目录
在package.json中添加prepare脚本
{
"scripts": {
"prepare": "husky install"
}
} - 添加git hooks
创建一条 pre-commit hook
执行下面命令后，会看到.husky/目录下新增了一个名为pre-commit的shell脚本。
这样，在之后执行git commit命令时会先触发pre-commit这个脚本。
npx husky add .husky/pre-commit "npm run lint"
修改为
npx husky add .husky/pre-commit "npx lint-staged" - 安装 lint-stage (作用：对暂存区的代码执行lint 代码检查)
yarn add lint-stage -D
它将根据package.json依赖项中的代码质量工具来安装和配置husky和lint-staged，因此请确保在此之前安装（npm install prettier eslint -D）并配置所有代码质量工具，如Prettier和ESlint 等。
在package.json 中配置
"lint-staged": {
"src/**/.{tsx,ts,js}": [
"eslint"
],
".{scss,css}": [
"stylelint"
]
} - 规范commit message信息
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"' - commitlint 安装与配置
错误提示我们需要安装 commitlint。
yarn add @commitlint/cli @commitlint/config-conventional -D
配置 commitlint.config.js
module.exports = {
// 继承的规则
extends: ['@commitlint/config-conventional'],
// 定义规则类型
rules: {
// type 类型定义，表示 git 提交的 type 必须在以下类型范围内
'type-enum': [
2,
'always',
[
'feat', // 新功能 feature
'fix', // 修复 bug
'docs', // 文档注释
'style', // 代码格式(不影响代码运行的变动)
'refactor', // 重构(既不增加新功能，也不是修复bug)
'perf', // 性能优化
'test', // 增加测试
'chore', // 构建过程或辅助工具的变动
'revert', // 回退
'build', // 打包
],
],
// subject 大小写不做校验
'subject-case': [0],
},
};
七 思考：现阶段 cc项目 git流程上可以优化的点
- 不需要的远程分支及时清理，现在远程分支有点多。
- commit-msg 更加标准化，在 footer中标注 对应的redmin 问题号 和 是否为 私有部署的tag。有利于以后查看代码时候找到这段修改对应的需求是什么，也方便直接筛选需要私有 部署的需求。
- 分支的合并更加标准化，在每次合并前都先rebase 最新的远程（dev-2023-1），让主分支形成一条线。让分支信息简单明了。
- Husky pre-commit中配置 stylelint 检查 css 文件的格式化问题，现在是没有做这个检查的。
八 关于分享的一些规划
1.第一期：Git初级篇：git的起源以及常用的方法介绍
2.第二期：Git原理 - Git 的工作原理
- Git 中的diff算法
- 版本管理工具应该怎么去实现 （画板版本管理）
3.第三期：gitlab服务器介绍 - 如何搭建一台gitlab服务器
- gitlab服务器的一些配置 （连接我们redmin问题号，配置git rebase）
4.第四期：CI/CD流程介绍
九 思维扩展： 一条裙子带来的思考 - 蓝黑 or 白金
产生差异的原因： 人体感知颜色主要由眼睛视网膜中的视杆细胞和视锥细胞决定，视杆细胞负责昏暗光线下的视物，而视锥细胞则负责处理色彩和细节。每个人视杆细胞和视锥细胞 的多少，会对颜色最终在人大脑皮层中 成像产生 误差。 每个人都是一定程度的 “色盲”，每个物体的颜色 可能在每个人大脑皮层中成像是不同rgba 值；
同理为什么会有人不吃香菜 ？原理差不多，不是因为他们不喜欢香菜的味道，而是他们的味觉细胞最终传递给大脑皮层的味觉信号 和喜欢吃香菜人不一样，那就是一个难吃的信号。喜欢它的人说，它有一种清爽，柠檬或酸橙的味道；而那些不喜欢它的人对它的味道和气味有强烈的厌恶，称之为肥皂或腐烂味。 所以不是因为不喜欢，不是因为爱好问题，不是因为挑食。只是因为设备不同而已，产生的信号不同，最终产品不同。
俗话说：耳听为虚，眼见为实。但眼见也不一定为实。 在VR 虚拟现实逐渐壮大过程中，你还敢相信自己的感觉吗？
那我们还能相信什么，信“砖家”吗，NO！ 相信 道，相信人性，相信自然规律！
