简介

Git 是一个开源的分布版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

安装

单人流程

准备工作（只做一次）

1. 创建工作区
2. 在工作区中打开 git 终端
3. 通过git init指令，初始化版版本库
4. 通过git config --global user.name "姓名"和git config --global user.email "邮箱"设置用户名和邮箱
5. 通过 git config -l查看设置情况

开发阶段（反复执行）

1. 编写代码
2. 通过git add "文件名称"/git add .添加到版本库的暂缓区
3. 通过git commit -m"说明"将暂缓区的文件添加到 HEAD 指针指向的分支中（默认只有一个分支，master分支，也称之为主分支）

注意点：

• 不是写一句代码就 add commit 一次，应该是完成一个功能后再 add commit

• commit 时 -m 注释一定要认真编写，与当前提交的内容保持一致

多人流程

在远程服务器上创建一个共享版本库

1. 项目负责人打开远程的服务器，然后创建一个工作区
2. 在远程的服务器上打开工作区，在工作区中打开 git 终端工具
3. 在 git 终端工具中输入git init --bare
4. 经过以上几步, 就代表远程服务器上的共享版本库已经创建好了

开发人员下载远程版本库

1. 开发人员在自己电脑上打开 git 终端工具
2. 从远程的服务器上下载当前项目的共享版本库，git clone远程服务器共享版本库地址（和单人开发使用 git 区别：单人开发是自己创建版本库，而多人开发是从远程服务器下载版本库）

开发阶段

1. 设置用户名和邮箱
2. 编写代码
3. git add .添加到暂缓区
4. git commit -m"说明"添加到 HEAD 指针指向的分支
5. 将代码提交到远程的服务器 git push
6. 其它的开发人员只需要通过git pull就可以拿到更新的代码了

注意点：

• commit 是将编写好的代码提交到本地的版本库，所以其它的开发人员是拿不到我们提交的代码的

  如果想让其它开发人员也能拿到我们提交的代码, 还必须将编写好的代码提交到远程的服务器

• 如果服务器上有其它开发人员的更新内容，那么我们不能直接通过 push 将我们的代码提交到服务器

  如果服务器上有其它开发人员更新的内容，我们必须先将其它开发人员更新的内容更新到本地之后才能通过 push 提交我们的内容

• 如果我们更新的内容和其它同事更新的内容有冲突（修改了同一个文件的同一行代码），这个时候就需要我们手动修改冲突，修改完冲突之后才能将代码提交到远程服务器

分支使用

查看分支

1. 通过git branch指令就可以查看当前版本库中有多少个分支

注意点：

• 如果当前的版本库是空的，那么无法查看

• 如果通过git branch指令查看当前版本库中有多少个分支，输出的内容中哪一个分支前面有 * 号

  就代表当前的 HEAD 指针指向哪一个分支，我们提交的代码就会提交到指向的分支中

创建分支

1. 通过git branch "分支名称"来创建一个新的分支

注意点：

• 在哪个分支创建了新的分支，那么创建出来的新的分支就会继承当前分支的所有状态
• 一旦分支被创建出来之后，分支就是独立的，分支之间不会相互影响

切换分支

1. 通过git branch "分支名称"来修改 HEAD 指针的指向

注意点：

• 只要 HEAD 指针的指向发生了改变，那么 commit 的代码就会发生改变，HEAD 指针指向谁的 commit 提交的代码就提交到谁里面

将分支提交到远程服务器

1. 通过git branch -r来查看远程服务器上有多少个分支

2. 首先需要在本地分支切换到新建的分支中，然后通过git push指令提交新建的分支到远程的服务器

   git push —set-upstream origin Dev

合并分支

1. 可以通过git merge "分支名称"来合并分支

   例如：在 master 分支中执行git merge Dev就代表需要将Dev分支中的代码都合并到 master 分支中

   在 Dev 分支中执行 git merge master就代表需要将 master 分支中的代码合并到 Dev 分支中

删除分支

1. 可以通过git branch -d "分支名称"来删除本地分支
2. 可以通过git push orgitn --delete "分支名称"来删除远程服务器的分支

GitFlow工作流

准备阶段

1. 初始化远程工作区和共享版本库

   git init --bare

2. 项目经理初始化项目，并在 master 定制标记

   git add .

   git commit -m'说明'

   git push

   git tag v0.1

   git push origin v0.1

3. 项目经理基于 master 分支创建 develop 分支

   git switch master

   git branch Develop

   git switch Develop

   git push

4. 项目经理给开发人员分配工作任务

开发阶段

1. 开发人员基于 Develop 分支创建功能分支

   git branch feature/home

   git switch feature/home

2. 开发人员在自己的分支上 add commit push

3. 开发人员完成告诉项目经理，由项目经理审核代码并合并到 Develop

   git pull

   git switch feature/home（检查代码）

   git switch Develop

   git merge feature/home

   git switch feature/login（检查代码）

   git switch Develop

   git merge feature/login

准备上线阶段

1. 项目经理基于 Develop 分支创建 Release 分支

   git switch Develop

   git branch Release/v1.0

2. 测试人员获取 Release 分支代码进行测试

3. 发现 bug 由开发人员基于 Release 分支创建 bugfix 分支进行修复

   git pull

   git switch Release/v1.0

   git branch bugfix/issue32

   修复 bug / add / commit

4. 修复完成后重新合并到 Release 分支

   git switch Release/v1.0

   git merge bugfix/issue32

   git push

5. 将测试和修复完所有 bug 的最终代码合并到 master 分支和 Develop 分支

   git switch Develop

   git merge Release/v1.0

   git switch master

   git merge Release/v1.0

项目上线

1. 项目经理在 master 分支定制标记

   git switch master

   git tag -a v1.0 -m"项目第一次上线"

2. 项目经理将标记提交到远程服务器

   git push origin v1.0

上线之后

1. 项目上线后发现紧急 bug

2. 基于 master 分支创建 hotfix 分支，在该分支上修复 bug

   git switch master

   git branch hotfix/issue66

   修复 bug / add /commit

3. 修复完成后重新合并到 master 分支和 Develop 分支

   git switch Develop

   git merge hotfix/issue66

   git sitch master

   git merge hotfix/issue66

4. 项目经理重新在 master 分支定制标记

   git tag v1.1

   git push origin v1.1

补充

• master 主分支：

  负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。

• develop开发分支:

  该分支记录相对稳定的版本，所有的feature分支都从该分支创建。

• feature/* 特性（功能）分支:

  用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 develop 分支。

• release/*发布分支：

  用于代码上线准备，该分支从develop分支创建，创建之后由测试发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完后，在上线之前，需要合并该release分支到master分支和develop分支。

• bugfix/* bug修复分支:

  用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测没问题后合并到 develop 分支后，删除该分支。

• hotfix/*紧急bug修复分支：

  该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支。

提交规范

• 1. 什么是Conventional Commits？

  Conventional Commits 是一种对 Git 提交信息进行结构化的规范。它建议每条提交都遵循如下格式：

  <type>[optional scope]: <description>
   
  [optional body]
   
  [optional footer(s)]

  • type：本次提交的类型（如 feat、fix、docs 等）

  • scope（可选）：本次更改影响的范围或模块

  • description：简要描述更改内容

  • body（可选）：详细描述

  • footer（可选）：BREAKING CHANGE 或关联 issue

• 2. 常见type类型

  类型	含义
  feat	新功能
  fix	bug修复
  docs	文档变更
  style	代码格式（非逻辑变更）
  refactor	代码重构（非功能变更）
  perf	性能提升
  test	测试相关
  chore	杂项维护
  build	构建流程、依赖变更
  ci	持续集成相关

  示例：

  feat(login): add remember me option
   
  fix(api): correct user login error
   
  docs: update README with new usage instructions
   
  refactor: improve component structure for clarity
   
  chore: update dependencies