工作开发--必备git技能及流程

开源

个人开源的leno-admin后台管理项目，前端技术栈：reactHooks、ant-design；后端技术栈：koa、mysql、redis，整个项目包含web端、electron客户端、mob移动端、template基础模板，能够满足你快速开发一整套后台管理项目；如果你觉得不错，就为作者点个✨star✨吧，你的支持就是对我最大的鼓励；

演示地址

文档地址

源码github地址

一、git 基础语法

git init 初始化仓库（使用git对项目进行管理）
git status 查看文件状态
- 红色表示工作区内部的文件需要提交
- 绿色表示暂存区内部的文件需要提交
git add 提交语法（将文件由工作区添加到暂存区）
- git add index.html # 将index.html添加到暂存区
- git add css # 将css目录下所有文件添加到暂存区
- git add *.js # 将当前目录下所有的js文件添加到暂存区
- 添加当前目录下所有文件
  - git add .
  - git add -A
  - git add --all
git commit 将文件由暂存区添加到仓库区
- git commit -m "此次提交说明，必须加" 将文件由暂存区提交到仓库
- git commit --amend -m "此次提交说明，必须加" 修改最近一次提交说明，如果提交说明输错，可以使用这个命令
git log 查看自己的提交日志
git diff 查看每次提交的内容不同之处
- git diff 查看工作区与暂存区的不同
- git diff --cached 查看暂存区与仓库区的不同
- git diff HEAD 查看工作区与仓库区不同，HEAD表示最新的提交
- git diff c234323 da35344查看两个版本的不同
git reset 版本回退
- git reset --hard 版本号 将代码回退到指定的版本
- git reset --hard head~1 将版本回退到上一次提交
  - ~1：上一次提交
  - ~2：上上一次提交
  - ~0：当前提交
- 注意：使用了版本回退后，git log 只能看到当前版本之前的信息，这时需要使用 git reflog 则可以查看所有版本信息

git 忽视文件

如果仓库内由文件不想被git管理，则需要在仓库内部创建一个.gitignore 文件名不可以变动，为固定名字

// 代码案例  
 '#' 忽视idea.txt文件
  idea.txt

  '#' 忽视css下的index.js文件
  css/index.js

  '#' 忽视css下的所有的js文件
  css/*.js

  '#' 忽视css下的所有文件
  css/*.*
  
  '#' 忽视css文件夹
  css

二、git 分支操作

创建分支
- git branch 分支名称 注：分支中的代码与当前分支的内容完全相同
- 第一次创建，会默认有一个master的主分支
- 案例：git branch two 创建一个叫two的分支
查看分支
- git branch 查看所有分支
切换分支
- git checkout 分支名称
创建并切换分支
- git checkout -b 分支名称
- 创建一个分支，并且切换到创建的新分支上
删除分支
- git branch -d 分支名称
- 注意：不能删除当前的分支，需要切换其他分支再执行分支，master分支可以删除，但最好不要这么做

合并分支

git merge 分支名称 将其他分支内容合并到当前分支

// 代码案例

git merge two  // 将two分支中的代码合并到master

git 合并冲突
- git合并中如果出现冲突，只能手动修改，最好在合并前检查代码

三、git远程git仓库操作

git clone 克隆远程仓库代码到本地，会将git仓库一并clone，下载则不会
- git clone 仓库地址本地项目名
```
// 代码案例

git clone https://gitee.com/zhao-wenchao110/wangyi_music_vue2.0.git master
```
- git clone -b 仓库分支仓库地址 克隆指定分支

git push 将本地仓库代码提交到远程仓库

git push 仓库地址本地分支/远程分支

// 代码案例

`git push https://gitee.com/zhao-wenchao110/wangyi_music_vue2.0.git login/login`

git pull 将远程代码下载到本地

git pull 远程仓库远程分支名:本地分支名

// 代码案例

git pull https://gitee.com/zhao-wenchao110/wangyi_music_vue2.0.git login:login

git remote 为远程仓库地址设置别名
- git remote add 仓库别名仓库地址
```
// 代码案例

git remote add gitee https://gitee.com/zhao-wenchao110/wangyi_music_vue2.0.git
```
- git remote remove 仓库别名 删除仓库别名
- git remote -v 检查关联的仓库别名

四、规范自己的提交格式

代码提交规范：原文地址
这篇文章写的非常棒，我在这里只是精简的简述一下；

在代码的提交环节，团队的每一个人员的风格及描述信息的习惯，都会造成最终的每一条提交信息的紊乱，导致后期维护困难；

这里我推荐用社区内最流行，最受认可的Angular团队的提交我、规范，也是很多开源项目的提交规范，非常值得花费一些时间进行学习；

以下是Angular团队的提交记录：

提交语法：

由 Header Body Footer 三部分组成

其中Header还包含：type（必须）、scope（可选）、subject（必须）

type
type是cimmit 的提交类型

值	描述
feat	新增一个功能
fix	修复一个 Bug
docs	文档变更
style	代码格式（不影响功能，例如空格、分号等格式修正）
refactor	代码重构
perf	改善性能
test	测试
build	变更项目构建或外部依赖（例如 scopes: webpack、gulp、npm 等）
ci	更改持续集成软件的配置文件和 package 中的 scripts 命令，例如 scopes: Travis, Circle 等
chore	变更构建流程或辅助工具
revert	代码回退

安装 Commitizen 实现提交规范

npm install commitizen -D

初始化项目

npx commitizen init cz-conventional-changelog --save-dev --save-exact

这行命令会在 package.json 里面增加了以下的配置：

"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
}

使用 git cz 提交规范代码格式：

但是有一个大问题，都是英文的，对于我们英语不咋行的程序员来说，这就有点难搞了；这是我们可以自定义将英文显示为中文，这里使用的是cz-customizable 适配器。

配置 cz-customizable：

npx commitizen init cz-customizable --save-dev --save-exact --force

这行命令执行后会在文件中添加以下两段代码：

"devDependencies": {
  ...
  "cz-customizable": "^6.3.0",
  ...
},

"config": {
  "commitizen": {
    "path": "./node_modules/cz-customizable"
  }
}

配置中文：

在根目录下创建.cz-config.js 文件

将以下代码添加到.cz-config.js文件中

module.exports = {
  // type 类型（定义之后，可通过上下键选择）
  types: [
    { value: 'feat', name: 'feat:     新增功能' },
    { value: 'fix', name: 'fix:      修复 bug' },
    { value: 'docs', name: 'docs:     文档变更' },
    { value: 'style', name: 'style:    代码格式（不影响功能，例如空格、分号等格式修正）' },
    { value: 'refactor', name: 'refactor: 代码重构（不包括 bug 修复、功能新增）' },
    { value: 'perf', name: 'perf:     性能优化' },
    { value: 'test', name: 'test:     添加、修改测试用例' },
    { value: 'build', name: 'build:    构建流程、外部依赖变更（如升级 npm 包、修改 webpack 配置等）' },
    { value: 'ci', name: 'ci:       修改 CI 配置、脚本' },
    { value: 'chore', name: 'chore:    对构建过程或辅助工具和库的更改（不影响源文件、测试用例）' },
    { value: 'revert', name: 'revert:   回滚 commit' }
  ],

  // scope 类型（定义之后，可通过上下键选择）
  scopes: [
    ['components', '组件相关'],
    ['hooks', 'hook 相关'],
    ['utils', 'utils 相关'],
    ['element-ui', '对 element-ui 的调整'],
    ['styles', '样式相关'],
    ['deps', '项目依赖'],
    ['auth', '对 auth 修改'],
    ['other', '其他修改'],
    // 如果选择 custom，后面会让你再输入一个自定义的 scope。也可以不设置此项，把后面的 allowCustomScopes 设置为 true
    ['custom', '以上都不是？我要自定义']
  ].map(([value, description]) => {
    return {
      value,
      name: `${value.padEnd(30)} (${description})`
    }
  }),

  // 是否允许自定义填写 scope，在 scope 选择的时候，会有 empty 和 custom 可以选择。
  // allowCustomScopes: true,

  // allowTicketNumber: false,
  // isTicketNumberRequired: false,
  // ticketNumberPrefix: 'TICKET-',
  // ticketNumberRegExp: '\\d{1,5}',


  // 针对每一个 type 去定义对应的 scopes，例如 fix
  /*
  scopeOverrides: {
    fix: [
      { name: 'merge' },
      { name: 'style' },
      { name: 'e2eTest' },
      { name: 'unitTest' }
    ]
  },
  */

  // 交互提示信息
  messages: {
    type: '确保本次提交遵循 Angular 规范！\n选择你要提交的类型：',
    scope: '\n选择一个 scope（可选）：',
    // 选择 scope: custom 时会出下面的提示
    customScope: '请输入自定义的 scope：',
    subject: '填写简短精炼的变更描述：\n',
    body:
      '填写更加详细的变更描述（可选）。使用 "|" 换行：\n',
    breaking: '列举非兼容性重大的变更（可选）：\n',
    footer: '列举出所有变更的 ISSUES CLOSED（可选）。 例如: #31, #34：\n',
    confirmCommit: '确认提交？'
  },

  // 设置只有 type 选择了 feat 或 fix，才询问 breaking message
  allowBreakingChanges: ['feat', 'fix'],

  // 跳过要询问的步骤
  // skipQuestions: ['body', 'footer'],

  // subject 限制长度
  subjectLimit: 100
  breaklineChar: '|', // 支持 body 和 footer
  // footerPrefix : 'ISSUES CLOSED:'
  // askForBreakingChangeFirst : true,
}

提交结果：

五、git 多人开发提交流程：

假设一个小组当中，组长是小A，组员是小B：

小A创建项目并且将项目开发环境搭建完成，提交git push到远程git仓库当中
小B将远程仓库内项目的源码git clone 到本地中
小B修改了部分源码并且提交到git 仓库当中
小A获取到小B提交的源码，检查无误后合并到主干master上
小B接收到一个新的功能模块开发任务，在远程仓库创建一个分支，比如：login登录分支，并在分支上进行此功能模块的开发
小B将该功能开发完成后，将该项目源码提交到远程login分支上
小A收到代码，测试后，发现没有bug，便将login这个功能合并到master主干支上
后面就是类似的操作，多人分别在不同的分支写自己负责的板块，最终统一由项目组长和软测检查，最终无bug合并到master主干上

总结

本人将自己日常使用的git，进行一些简单的总结及阐述，希望能够帮到大家，如有错误，欢迎大家指出，谢谢~🥩