首页 计算机科学 工具安装与使用

# git 安装与使用

# 简介

Git 是一个免费、开源的分布式版本控制系统，主要用于管理软件代码的变化，记录每一次修改，并允许开发者回滚到之前的版本或进行分支开发，方便团队协作开发。

# 安装

  1. 进入官方网站下载系统对应的版本下载地址

  2. 下载完成后直接无脑下一步即可

  3. 校验是否安装成功，在文件夹下鼠标右键出现下列 git 的选项，如图

# 使用

# 基础使用

  1. 原理说明

    git 底层是类似于 hashmap 的结构 key-value 的形式存储数据（直接把文件的内容拿出来存储到数据库中）key 是唯一的 value 就是文件的类容

  2. 常用命令

#可以查看这个文件的 key 值（8fe5f63999dd11e8ed17f7ba4d4a68b6b2fafbfc）
git hash-object -w README.MF 
#根据 key 值查询对应数据
git cat-file -p 8fe5f63999dd11e8ed17f7ba4d4a68b6b2fafbfc
#查看状态
git status 
#添加文件到本地缓存区
git add filename
#添加所有文件
git add -A 
#从本地缓存区删除文件（并不会删除实际的文件）
git rm --cached filename 
#提交文件到本地仓库
git commit filename -m '备注' 
#本地添加远程仓库地址
git remote add 分支名 https://gitee.com/xxx/xxx.git
  1. 操作流程图
​	提交远程仓库流程：本地开发 - 添加到本地缓存 - 提交到本地仓库 - 推送到远程仓库
​	拉去远程仓库流程：克隆远程仓库
  1. 多个远程仓库
    git 可以搭建多个远程仓库
    多个远程仓库的好处： 可以将一份代码一次上传到多个仓库中（某些场景用到）图片说明
    具体配置方法：
    #本地仓库与远程仓库地址管理命令
    #执行多次就添加多个
    git remote add
    #列如 这里同时添加了名为 origin 的 gitee 仓库和名为 origin 的 github 仓库
    git remote add origin git@github.com:myusername/myrepository.git
    git remote add origin git@gitee.com:myusername/myrepository.git
    #查看关联的远程仓库
    git remote -v
    #删除名为 origin 的远程仓库
    git remote rm origin
    #向指定远程仓库推送到指定分支
    #这个命令将在本地仓库中查找 master 分支，并将其推送到名为 origin 的远程仓库中
    git push origin master
    #向指定远程仓库拉取指定分支的内容
    #这个命令将从名为 origin 的远程仓库中下载最新的代码，并将其合并到本地的 master 分支中
    git pull origin master
# 分支管理
在 git 中分支是用来将特性开发工作从主仓库分离开的，分支可以基于以下几点创建
  • 基于当前分支创建分支
  • 基于远程分支创建分支
  • 基于一个提交创建分支
  • 基于 tag 创建分支
常用管理分支操作
#根据现有分支创建分支（继承分支内容）
git branch <branch_name> [依据的分支]
#无任何内容
git branch <branch_name>
#切换分支
git checkout <branch_name>
#创建并切换到新分支
git checkout -b <branch_name>
#查看所有分支
git branch 
#所有分支
git branch -a 
#可以查看本地和远程分支的关联信息
git branch -avv 
#合并分支
#如果已经在主分支上，想要将功能分支合并进来
git merge <feature_branch>
#删除分支
git branch -d <branch_name>
#强制删除一个未合并的分支
git branch -D <branch_name>
#查看分支图
git log --graph --all --oneline
#重命名分支
#首先切换到要重命名的分支
git checkout <old_branch>
#然后使用以下命令重命名分支
git branch -m <new_branch>
#推送分支到远程仓库 这里会推送到 origin 远程仓库
git push origin <branch_name>
#拉取远程分支到本地
git checkout -b <branch_name> origin/<branch_name>
#删除远程分支
git push origin --delete <branch_name>
#拉取远程分支列表
git fetch
#拉取所有远程分支到本地
git fetch --all
​
# 远程管理
1
# 搭建私有仓库
# 为什么搭建私有仓库
首先需要知道既然是远程那么就需要有通讯协议，而 git 支持的通信协议有：
  1. local
    ✔️优点 搭建简单，管理轻松
    💔danger 只能在局域网中使用
    例子 git init --bare 主服务（文件共享）
    注意点：如果拉取项目用全路径会全部打包
    如果用 “file:///" 方式会先 执行 gc 命令 在打包
  2. ssh
    ✔️优点 搭设简单 访问安全 高效 传输数据会尽量压缩
    💔danger 权限不好控制 必须提供系统账号密码
  3. http
    首先搭建 nginx 如果映射到 git 项目 需要开启 git 提交的钩子
    本地克隆远程服务：
    git clone http://xxx.xxx.xxx/test.git
# 方案
  1. gogs
  2. gitlab
  3. gitblit
# 扩展 1：gitflow
# 什么是 GitFlow
GitFlow 是一种 Git 工作流，这个工作流程围绕着 project 的发布 (release) 定义了一个严格的如何建立分支的模型。它是团队成员遵守的一种代码管理方案 。
Git 建分支是非常 cheap 的，我们可以任意建立分支，对任意分支再分支，分支开发完后再合并。
比较推荐、多见的做法是特性驱动 (Feature Driven) 的建立分支法 (Feature Branch Workflow)。
简而言之，就是每一个特性 (feature) 的开发并不直接在主干上开发，而是在分支上开发，分支开发完毕后再合并到主干上。
这样做的好处是：
  1. 还处于半成品状态的 feature 不会影响到主干
  2. 各个开发人员之间做自己的分支，互不干扰
  3. 主干永远处于可编译、可运行的状态
GitFlow 则在这个基础上更进一步，规定了如何建立、合并分支，如何发布，如何维护历史版本等工作流程。
在工作场合实施 Git 的时候，有很多种工作流程可供选择，此时反而会让你手足无措。企业团队最常用的一些 Git 工作流程，包括 Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。
在你开始阅读之前，请记住：这些 Git 工作流程应被视作为指导方针，而非 “铁律”。我们只是想告诉你可能的做法。因此，如果有必要的话，你可以组合使用不同的流程。
# GitFlow 常用分支说明
分支名称分支说明
Master生产分支，只能从其他分支合并，不能直接修改
Release发布分支，基于 Develop 分支创建，待发布完成后合并到 Develop 和 Master 分支去
Develop主开发分支，包含所有要发布到下一个 Release 的代码，该分支主要合并其他分支内容
Feature新功能分支，基于 Develop 分支创建，开发新功能，待开发完毕合并至 Develop 分支
Hotfix修复分支，基于 Master 分支创建，待修复完成后合并到 Develop 和 Master 分支去，同时在 Master 上打一个 tag
# Git flow 中的分支介绍
Git Flow 的核心就是分支 (Branch），通过在项目的不同阶段对分支的不同操作（包括但不限于创建、合并、变基等）来实现一个完整的高效率的工作流程。Git Flow 模型中定义了主分支和辅助分支两类分支。其中主分支包含主要分支和开发分支，用于组织与软件开发、部署相关的活动；辅助分支包含功能分支、预发分支、热修复分支以及其他自定义分支，是为了解决特定的问题而进行的各种开发活动。 与主分支不同，这些分支总是有有限的生命时间，因为它们最终将被移除。
主分支：master 分支、develop 分支；辅助分支：feature 分支、release 分支、hotfix 分支
# 主要分支 **（Master）**
主要分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，主要分支上的代码要被更新。同时，每一次更新，都需要在主要分支上打上对应的版本号。
任何人不允许在主要分支上进行代码的直接提交，只接受其他分支的合入。原则上主要分支上的代码必须是合并自经过多轮测试及已经发布一段时间且线上稳定的预发分支。
master 分支只存放历史发布 (release) 版本的源代码。即用于存放对外发布的版本，任何时候在这个分支获取到的都是稳定的已发布的版本。各个版本通过 tag 来标记。上图里的 v0.0.1 和 v0.0.2 就是 tag。
# 开发分支（Develop）
开发分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当开发分支到达一个稳定的点并准备好发布时，应该从该点拉取一个预发分支并附上发布版本号。也有人称开发分支为集成分支，因为会基于该分支和持续集成工具做自动化的构建。
开发分支接受其他辅助分支的合入，最常见的就是功能分支，开发一个新功能时拉取新的功能分支，开发完成后再并入开发分支。需要注意的是，合入开发的分支必须保证功能完整，不影响开发分支的正常运行。
develop 分支则用来整合各个 feature 分支。开发中的版本的源代码存放在这里。即用于日常开发，存放最新的开发版。
# 功能分支（Feature）
功能分支一般命名为 Feature / 添加用户登陆功能，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。也就是功能分支要求足够细粒度以避免成为长期存在的功能分支，应当小步合并而不是一次合并大量代码。
功能分支只能拉取自开发分支（develop)，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃。
每一个特性 (feature) 都必须在自己的分支里开发，feature 分支派生自 develop 分支。
feature 分支只存在于开发者本地，不能被提交到远程库。当 feature 开发完毕后，要合并回 develop 分支。feature 分支永远不会和 master 分支打交道。
# 预发分支（Release）
预发分支一般命名为 Release/1.1.2（后面是版本号），该分支专为测试 — 发布新的版本而开辟，允许做小量级的 Bug 修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。
预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复 Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署。
预发分支只能拉取自开发分支，合并回开发分支和主要分支。
release 分支不是一个放正式发布产品的分支，你可以将它理解为 “待发布” 分支。
我们用这个分支干所有和发布有关的事情，比如：
  1. 把这个分支打包给测试人员测试
  2. 在这个分支里修复 bug
  3. 编写发布文档
所以，在这个分支里面绝对不会添加新的特性。
当和发布相关的工作都完成后，release 分支合并回 develop 和 master 分支。
单独搞一个 release 分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。
# 热修复分支（Hotfix）
热修复分支一般命名为 Hotfix/1.2.1（后面是版本号），当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的 tag 版本（比如 1.1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如 1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责代码修复的人并行、独立的开展工作。
热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。
一个项目发布后或多或少肯定会有一些 bug 存在，而 bug 的修复工作并不适合在 develop 上做，这是因为
  1. develop 分支上包含还未验证过的 feature
  2. 用户未必需要 develop 上的 feature
  3. develop 还不能马上发布，而客户急需这个 bug 的修复。
这时就需要新建 hotfix 分支，hotfix 分支派生自 master 分支，仅仅用于修复 bug，当 bug 修复完毕后，马上回归到 master 分支，然后发布一个新版本，比如，v0.1.1。
同时 hotfix 也要合并回 develop 分支，这样 develop 分支就能享受到 bug 修复的好处了。
# GitFlow 实践
# 创建 develop 分支
# 创建 develop 分支 
git checkout -b develop
# 将 develop 分支推送到远端仓库
git push -u origin develop
# 开始新的 Feature
# 通过 develop 新建 feaeure 分支
git checkout -b feature/feature-name develop
# 可选，将分支推送到远端仓库
git push -u origin feature/feature-name
# 编辑 Feature 分支
# 查看状态
git status
# 添加提交内容
git add XXXfile
# 提交    
git commit
# 完成 Feature 分支
# 拉取远端仓库 develop 分支合并到本地 develop 分支
git pull origin develop
# 切换到 develop 分支     
git checkout develop
# 将 Feature 分支合并到 develop 分支    
# --no-ff：不使用 fast-forward 方式合并，保留分支的 commit 历史
# --squash：使用 squash 方式合并，把多次分支 commit 历史压缩为一次    
git merge --no-ff feature/feature-name
# 将分支推送远端仓库 
git push origin develop
# 删除 Feature 分支
git branch -d feature/feature-name
# 开始 Relase
# 创建 Relase 分支并切换到 Relase 分支上
git checkout -b release/x.y.z
#推送
git push -u origin release/x.y.z
# 完成 Release
# 切换到 master 分支上
git checkout master
# 合并 release/x.y.z 分支    
git merge --no-ff release/x.y.z
# 创建一个新标签（tag），标记当前 master 分支的最新提交。-a 表示创建一个有注释的标签，x.y.z 是标签名，通常是版本号的形式，-m 后面跟着的是对这个标签的描述信息
git tag -a x.y.z -m "Description of the release"
#当前的 master 分支以及所有本地标签推送到远程仓库（如 GitHub、GitLab 等）。--tags 选项告诉 Git 同时推送所有已经创建的标签。
git push origin master --tags
#切换工作目录到 develop 分支，准备将发布分支的更改合并到 develop 分支。
git checkout develop
#将 release/x.y.z 分支的更改合并到当前的 develop 分支。--no-ff 选项表示不允许快进式合并（即使两个分支的线性历史没有分叉，也要创建一个新的合并提交），这样做可以保留更多的历史信息。
git merge --no-ff release/x.y.z
#将合并后的 develop 分支推送到远程仓库，确保远程仓库的 develop 分支是最新的。
git push origin develop
#删除本地的 release/x.y.z 分支，因为这个分支的目的已经达到，发布完成后不再需要。-d 选项表示删除分支，如果该分支上有未合并的更改，Git 会阻止删除以防止数据丢失。
git branch -d release/x.y.z
# 开始 Hotfix
# 创建 hotfix 分支并切换到 hotfix 分支上
git checkout -b hotfix-0.1.1 master
# 完成 Hotfix
# 切换到 master 分支
git checkout master
# 合并 hotfix-0.1.1 分支
git merge --no-ff hotfix-0.1.1
# 推送到远端仓库
git push
# 切换到 develop 分支
git checkout develop
# 合并 hotfix-0.1.1 分支
git merge --no-ff hotfix-0.1.1
# 推送到远端仓库
git push
# 删除 release-0.1.0 分支    
git branch -d hotfix-0.1.1
# 为主分支打上版本标签
git tag -a v0.1.1 master
# 将标签推送到远端仓库  
git push --tags
# GitFlow 工具推荐，配套工具
# Git Flow SourceTree (图形化)
SourceTree 下载官方：Sourcetree | Free Git GUI for Mac and Windows
# Gitflow 结合 SourceTree 实践
添加功能， 可以看到我这里添加了可动态监控线程池的功能。
注意：此处最好在最新的 develop 分支上，进行创建 feature，这样确保更少的冲突。
# Git Flow 模型总结
Git Flow 模型通过不同的分支从源代码管理的角度对软件开发活动进行了约束，为我们的软件开发提供了一个可供参考的管理模型。Git Flow 模型让代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。但同时，不同的开发团队存在不同的文化，在不同的项目背景情况下都可能根据该模型进行适当的精简或扩充。防控中心通过合理使用 Git Flow，更好地管理代码仓库，提高工作的效率。
# 扩展 2：git common
# 简介
Git commit message 是你在执行 git commit 命令时，对代码更改进行描述的一段文本。它是一个重要的组成部分，因为它为代码库的历史记录提供了上下文和解释，使得其他开发者（或未来的你）能够理解为什么进行了这些更改。
一个良好的 Git commit message 通常包括以下几个部分：
  1. Header（头部）：
    • type：类型，如 feat （新功能）、 fix （修复）、 refactor （重构）、 perf （性能优化）、 test （测试）、 docs （文档）、 chore （维护）等。
    • scope（可选）：影响的范围，如模块名、文件名、功能区域等。
    • subject：简短的变更描述，通常是一句话，不超过 50 个字符，以动词开头，使用现在时态。
  2. Body（正文）：
    • 更详细的变更描述，解释为什么要进行这次提交（目的），以及它是如何工作的（方法）。
    • 每行不超过 72 个字符，通常使用 | 符号或 > 符号进行折行。
  3. Footer（脚注）：
    • 可以包含关闭的 issue 跟踪编号，例如 Closes #123 、 Fixes #456 。
    • 可以标记 BREAKING CHANGE，如果这次提交包含重大更改，这些更改可能破坏向后兼容性。
  4. Breaking Changes（破坏性变更）：
    • 如果变更包含破坏性更改，应在 Footer 中明确指出，并解释为什么这是必要的。
  5. References（引用）：
    • 如果提交与特定的 issue 或 pull request 相关，应该在 Footer 中引用它们。
  6. 编码风格：
    • 保持编码风格一致，例如使用 tabs 还是 spaces，以及缩进的大小。
  7. 提交信息的清晰性：
    • 确保提交信息清晰、具体，避免模糊不清的描述，如 “一些更改” 或 “小修复”。
  8. 关联测试：
    • 如果提交包括新功能或修复，应确保有相应的测试覆盖。
  9. 避免提交不必要的文件：
    • 在提交之前，使用 .gitignore 忽略无关文件，并检查是否有未跟踪的文件被错误地包含在提交中。
  10. Revert Commits：
    • 如果需要撤销之前的提交，使用 revert 类型，并在正文中说明为什么要撤销。
以下是一些常见的 commit message 类型：
  • feat ：新功能（feature）
  • fix ：修复 bug
  • docs ：文档更新
  • style ：代码格式（不影响功能，例如空格、分号等）
  • refactor ：代码重构（不包括新功能和修复 bug）
  • perf ：性能优化
  • test ：添加或修改测试代码
  • build ：构建流程或脚本的更改
  • ci ：持续集成配置的更改
  • chore ：不属于以上类型的其他更改，比如更新依赖等
例子：
feat(login): 添加用户登录功能

通过实现新的认证逻辑，用户现在可以安全地登录到系统。这个功能包括用户名和密码的验证。

BREAKING CHANGE: 由于安全原因，旧的认证API已被删除。

Closes #123

git 首次初始化提交的 commit message 可以按照以下格式写，我的提交是：
feat: 初始化项目

初始化项目，包括创建基本目录结构和配置文件。

这样的格式清晰地表明了提交的类型和内容，符合规范，也便于其他开发人员阅读和理解。
遵循这些规范也可以帮助团队成员更好地理解每次提交的内容，同时也使得使用工具如自动生成的 CHANGELOG、版本控制和代码审查更加容易。
当提交 commit message 时，通常遵循以下规范：
  1. 第一行为标题，使用简短的语句描述提交的更改内容。
  2. 第二行为空行。
  3. 从第三行开始为详细描述，可以包括更改的原因、解决的问题、影响的范围等。
举个完整的例子：
feat: Add user authentication feature

Add user authentication feature to allow users to sign up, log in, and manage their accounts.

- Implemented user sign-up and login functionality
- Added user profile management
- Integrated with JWT for token-based authentication

Resolves: #123

在这个例子中，commit message 遵循了规范，包括了类型（feat）、简短的标题（Add user authentication feature）、详细描述和解决的问题。同时，还使用了关键字 Resolves 关联了一个 issue（#123），以便跟踪和关闭相关的问题。这样的规范 commit message 可以帮助团队更好地理解提交的内容，并且更容易进行代码审阅和版本控制管理。
以下是提交的例子：
  1. feat: Add new user authentication feature
    • Description: Implemented a new feature to allow users to authenticate using email and password.
  2. fix: Fix issue with login button not working
    • Description: Resolved a bug where the login button was not functioning properly on certain browsers.
  3. docs: Update installation guide with new dependencies
    • Description: Updated the installation guide to include information about new dependencies required for the application.
  4. style: Format code according to coding standards
    • Description: Applied consistent code formatting across the entire codebase to adhere to coding standards.
  5. refactor: Simplify user profile update logic
    • Description: Refactored the user profile update functionality to make the code more readable and maintainable.
  6. test: Add unit tests for user authentication
    • Description: Added new unit tests to ensure the reliability of the user authentication feature.
  7. chore: Update build process to use Webpack
    • Description: Updated the build process to utilize Webpack for better module bundling and asset management.
注意点
  1. 如果是改进功能也是用（feat）类型
  2. 修复功能的 bug 用（fix）类型
  3. 如果是重大 bug，影响线上项目使用则需要单独建立一个 hotfix 分支，修复完需要合并到 master 分支发布
# Git 分支管理
# Git 常用分支
包括：master，hotfix，bugfix，release，develop，feature。
  • master：项目主分支，有且仅有一个，除项目负责人外其他开发人员不得向 master 分支合并内容。
  • hotfix：紧急线上 bug 修复分支，紧急即需要立刻尽快去处理发布上线（自 master 拉取）, 直接进行测试及上线。
  • bugfix：非紧急上线的 bug 修复分支，如非当天上线即使用 bugfix 进行命名（自 master 拉取） , 直接进行测试及上线。
  • release：作为提测及上线分支，release 是发布正式版本之前（即合并到 master 分支之前），需要有一个预发布的版本进行测试。
  • develop：主开发分支，存有确定性的所有功能（上线和未上线）, 作为开发环境共有的部署分支。
  • feature：功能开发分支，feature 是为了开发后续版本的功能，从 develop 分支拉取出来的。开发完成稳定后，要再并入 develop 分支。
# 分支命名
  • hotfix：hotfix/{功能}，如 hotfix/providerLose。
  • bugfix：bugfix/{功能} 年月日，如 bugfix/pubMsg_20210701。
  • _release：release/{功能}_年月日，如 release/pubMsg_20210701。
  • feature：feature/{功能}_年月日，如 feature/pubMsg_20210701。
# 分支管理
上线完成之后，提交申请进行 master 的合并处理，打 Tag 维护（审核人员 / Leader）相关分支创建人，删除对应上线功能 feature /release/bugfix 分支
# Git 代码提交规约（推荐）
设置用户名为本人姓名，邮箱为公司邮箱或本人邮箱。
代码提交规则：
提交的说明包含两部分：动作类型：简要说明，以英文的 “:” 作为区分。
动作类型使用英文大写。
理论上一次提交仅包含一个功能修改，如功能过大，需要注明功能的完成进度。若一次提交有多个功能修改，则每个功能提交描述作为单独的一行，每行以英文标识符 “,” 作为行尾结束符。
列如：
# 新增功能
新增功能是软件开发中的一个常见活动，通常意味着为现有系统或软件添加新的功能或特性。
  1. 类型 (Type)：
    • 使用 feat 表示这是一个新增功能。
  2. 范围 (Scope)（可选）：
    • 如果新功能属于特定的模块或组件，可以添加范围。
  3. 主题 (Subject)：
    • 主题应简洁明了，描述新功能的核心内容，使用现在时态的动词，例如 “添加”、“实现” 等。
  4. 正文 (Body)（如果需要）：
    • 正文可以提供新功能的详细描述，包括功能的工作原理、用户将如何使用它以及任何重要的细节。
  5. 脚注 (Footer)：
    • 如果新功能与特定的 issue 或 pull request 相关，应在脚注中引用它们。
  6. 示例提交信息：
假设您为项目新增了一个用户注册功能，提交信息可能如下：
feat(registration): 添加用户注册功能

实现了一个完整的用户注册流程，允许新用户创建账户。新功能包括：
- 表单验证。
- 密码加密存储。
- 注册成功后的确认邮件。

Closes #feature-request-1

在这个示例中：
  • feat 是提交的类型，表示这是一个新增功能。
  • registration 是范围，表示这次新增功能属于用户注册模块。
  • 主题描述了新功能的核心内容。
  • 正文提供了新功能的详细信息，包括实现的功能点。
  • 脚注引用了与这个新功能相关的 issue 或功能请求。
# 修改功能
功能上的修改通常意味着你为软件添加了新的功能或改进了现有功能。在提交这类更改时，应该遵循以下步骤来撰写你的 Git 提交信息：
  1. 确定类型 (Type)：
    • 对于功能上的修改，通常使用 feat 作为提交的类型。
  2. 指定范围 (Scope)（可选）：
    • 如果功能修改是针对特定模块或组件的，可以在类型之后添加范围以明确指出。
  3. 撰写主题 (Subject)：
    • 主题应该简短明了，描述功能的核心变更，通常不超过 50 个字符，以动词开头，使用现在时态。
  4. 编写正文 (Body)（如果需要）：
    • 如果功能变更较为复杂，需要在正文中提供更多的细节，包括为什么进行这次变更，以及它是如何工作的。
    • 正文应该清晰地解释变更的动机和实现方式，每行不超过 72 个字符。
  5. 添加脚注 (Footer)（如果需要）：
    • 如果这次提交解决了特定的 issue 或与某些 issue 相关，应该在脚注中引用它们。
    • 如果这次提交包含了破坏性变更，应该在脚注中明确指出，并简要说明原因。
  6. 检查代码：
    • 在提交之前，确保代码符合项目的编码规范，并且已经通过了所有测试。
  7. 提交代码：
    • 使用 git add 将更改添加到暂存区，然后使用 git commit 命令提交更改。
一个功能修改的提交信息示例：

feat(dashboard): 增加新的仪表板可视化功能

引入了一个全新的仪表板，它允许用户通过图表和表格查看关键性能指标。这个功能包括自定义数据过滤和视图保存。

BREAKING CHANGE: 由于新的数据模型，旧的仪表板API已被删除。

Closes #issue123

在这个示例中， feat 是类型， dashboard 是范围， 增加新的仪表板可视化功能 是主题。正文部分提供了更多关于功能的细节，脚注部分标记了关闭的 issue 和破坏性变更。
# 删除功能
删除功能是一个结构性的变化，通常意味着你从代码库中移除了一些代码或特性。在这种情况下，你应该使用 feat 类型来表示这是一个新特性的添加，因为从版本控制的角度来看，删除一个功能可以被视为添加了一个没有该功能的新状态。然而，如果你遵循的是 Conventional Commits 规范，对于移除功能，推荐使用 refactor 类型，因为删除功能通常伴随着代码结构的重构。
  1. 类型 (Type)：
    • 使用 feat 表示添加了一个没有被删除功能的新状态。
    • 或者使用 refactor 表示进行了重构，这在删除功能时更常见。
  2. 范围 (Scope)（可选）：
    • 如果删除的功能属于特定的模块或组件，可以添加范围。
  3. 主题 (Subject)：
    • 主题应简洁明了，描述删除的功能，使用现在时态的动词，例如 “移除”、“删除” 等。
  4. 正文 (Body)（如果需要）：
    • 正文可以提供删除功能的原因、影响以及任何相关的迁移指南或注意事项。
  5. 脚注 (Footer)：
    • 如果删除的功能影响了特定的 issue 或 pull request，应在脚注中引用它们。
    • 如果这次提交包含了破坏性变更，应在脚注中明确指出，并简要解释原因。
  6. 示例提交信息：
假设你删除了一个不再使用的搜索功能，提交信息可能如下：

refactor(search): 移除旧的搜索功能

由于该搜索功能已不再符合项目需求，并且没有被任何活跃的用户使用，我们决定将其完全移除。这个改动简化了代码库并减少了维护负担。

BREAKING CHANGE: 移除了search模块的所有API。

Closes #issue789

在这个示例中：
  • refactor 是提交的类型，表示进行了代码重构。
  • search 是范围，表示这次重构影响的是搜索模块。
  • 主题描述了删除的功能。
  • 正文提供了删除功能的原因和影响。
  • 脚注中标记了破坏性变更并引用了相关的 issue。
# 修复问题
修复功能问题时编写提交信息是记录和沟通修复内容的重要方式。
  1. 类型 (Type)：
    • 使用 fix 表示这是一个修复问题或 bug 的提交。
  2. 范围 (Scope)（可选）：
    • 如果修复的问题属于特定的模块或组件，可以添加范围。
  3. 主题 (Subject)：
    • 主题应简洁明了，描述修复的问题和所采取的行动，使用现在时态的动词，例如 “修复”、“解决” 等。
  4. 正文 (Body)（如果需要）：
    • 正文可以提供问题的详细描述，包括问题的症状、原因以及修复措施。
  5. 脚注 (Footer)：
    • 如果修复的问题与特定的 issue 或 pull request 相关，应在脚注中引用它们。
    • 如果修复是一个紧急的 hotfix，可以在脚注中注明。
  6. 示例提交信息：
假设您修复了一个导致数据丢失的问题，提交信息可能如下：
fix(data): 修复数据丢失问题

解决了在特定条件下用户数据未能正确保存的问题。原因是保存操作未能正确触发，通过优化事件监听逻辑，确保所有数据更改都能被捕捉并保存。

Closes #issue789

在这个示例中：
  • fix 是提交的类型，表示这是一个问题修复。
  • data 是范围，表示这次修复影响的是数据处理模块。
  • 主题描述了修复的问题和采取的行动。
  • 正文提供了问题和修复措施的详细信息。
  • 脚注引用了与这个修复相关的 issue。
# 优化功能或系统
当你对功能或系统进行优化时，你希望提升性能、改善用户体验或代码可维护性，而不改变功能的行为。在这种情况下，你应该使用 perf 类型来表示这是一个性能优化的提交。以下是优化功能或系统时提交信息的一些建议：
  1. 类型 (Type)：
    • 使用 perf 表示这是一个性能优化的提交。
  2. 范围 (Scope)（可选）：
    • 如果优化影响特定的模块或组件，可以添加范围。
  3. 主题 (Subject)：
    • 主题应简洁明了，描述所做的优化，使用现在时态的动词，例如 “优化”、“改进” 等。
  4. 正文 (Body)（如果需要）：
    • 正文可以提供优化的详细描述，包括优化的方面、使用的技术和预期的效果。
  5. 脚注 (Footer)：
    • 如果优化与特定的 issue 或 pull request 相关，应在脚注中引用它们。
  6. 示例提交信息：
假设你优化了一个搜索功能的性能，提交信息可能如下：

perf(search): 优化搜索功能的性能

通过引入更高效的算法和缓存机制，搜索功能的响应时间减少了30%。此外，还重构了查询构建逻辑，以减少数据库的负载。

Closes #issue123

在这个示例中：
  • perf 是提交的类型，表示这是一个性能优化。
  • search 是范围，表示这次优化影响的是搜索模块。
  • 主题描述了进行的优化。
  • 正文提供了优化的详细信息，包括使用的技术和预期的效果。
  • 脚注引用了与这个优化相关的 issue。
# 修改代码格式
修改代码格式通常指的是对代码进行重构以改进其可读性、一致性或结构，而不改变其功能行为。这类更改通常使用 refactor 作为提交类型。
  1. 类型 (Type)：
    • 使用 refactor 表示这是一个代码重构的提交。
  2. 范围 (Scope)（可选）：
    • 如果重构影响特定的模块、组件或文件，可以添加范围。
  3. 主题 (Subject)：
    • 主题应简洁明了，描述所做的重构，例如 “改进代码格式”、“统一命名约定” 等。
  4. 正文 (Body)（如果需要）：
    • 正文可以提供重构的详细描述，包括为什么进行重构、重构了哪些方面、使用了什么方法等。
  5. 脚注 (Footer)：
    • 如果重构与特定的 issue 或 pull request 相关，应在脚注中引用它们。
  6. 示例提交信息：
假设你进行了代码格式化，以提高代码的一致性和可读性，提交信息可能如下：

refactor: 改进项目代码格式和命名约定

统一了项目中的命名约定和代码结构，以提高代码的一致性和可读性。包括：
- 应用了一致的命名规则。
- 重构了模块化的代码结构。
- 移除了多余的空格和未使用的导入。

Closes #issue123

在这个示例中：
  • refactor 是提交的类型，表示这是一个代码重构。
  • 主题描述了进行的重构。
  • 正文提供了重构的详细信息，包括重构的方面和方法。
  • 脚注引用了与这个重构相关的 issue。
# 重构功能
重构功能是一个常见的软件开发活动，旨在改进现有代码的结构、设计或架构，而不改变其外部行为。
  1. 类型 (Type)：
    • 使用 refactor 表示这是一个重构的提交。
  2. 范围 (Scope)（可选）：
    • 如果重构影响特定的模块、组件或功能，可以添加范围。
  3. 主题 (Subject)：
    • 主题应简洁明了，描述重构的内容和目的，使用现在时态的动词，例如 “重构”、“改进” 等。
  4. 正文 (Body)（如果需要）：
    • 正文可以提供重构的详细描述，包括重构的原因、重构的具体内容、采用的技术或方法，以及任何相关的动机。
  5. 脚注 (Footer)：
    • 如果重构与特定的 issue 或 pull request 相关，应在脚注中引用它们。
    • 如果重构包含了破坏性变更（尽管不常见，因为重构应保持功能行为不变），应在脚注中明确指出。
  6. 示例提交信息：
假设你重构了一个搜索功能的内部实现，以提高其可维护性和性能，提交信息可能如下：

refactor(search): 重构搜索功能以提高可维护性

对搜索功能的内部实现进行了重构，以简化代码结构并提高性能。改动包括：
- 将搜索逻辑分解为更小的、可复用的函数。
- 引入了新的数据结构来优化查询处理。
- 更新了单元测试以覆盖新的代码结构。

Closes #issue123

在这个示例中：
  • refactor 是提交的类型，表示这是一个重构。
  • search 是范围，表示这次重构影响的是搜索模块。
  • 主题描述了重构的目的和范围。
  • 正文提供了重构的详细信息，包括改动的方面和方法。
  • 脚注引用了与这个重构相关的 issue。
# 文档变更
当您需要对文档进行变更时，这通常意味着您在更新项目文档、注释或其他非代码文本内容。
  1. 类型 (Type)：
    • 使用 docs 表示这是一个文档相关的提交。
  2. 范围 (Scope)（可选）：
    • 如果文档变更影响特定的模块、组件或文档部分，可以添加范围。
  3. 主题 (Subject)：
    • 主题应简洁明了，描述文档变更的内容和目的，例如 “更新”、“添加”、“修正” 等。
  4. 正文 (Body)（如果需要）：
    • 正文可以提供文档变更的详细描述，包括变更的原因、变更的内容以及任何重要的细节。
  5. 脚注 (Footer)：
    • 如果文档变更与特定的 issue 或 pull request 相关，应在脚注中引用它们。
  6. 示例提交信息：
假设您添加了一个新的使用说明到项目的 README 文件，提交信息可能如下：
docs(README): 添加新的使用说明

在README文件中增加了详细的使用说明，以便新用户更快地了解如何安装和运行项目。

Closes #issue123

在这个示例中：
  • docs 是提交的类型，表示这是一个文档变更。
  • README 是范围，表示这次变更影响的是项目的 README 文件。
  • 主题描述了文档变更的内容。
  • 正文提供了变更的详细信息。
  • 脚注引用了与这个变更相关的 issue。
代码修改完成后，需先进行编码规范检查，注释检查，单元测试等操作。
测试通过后提交到本地，检查提交文件是否正确，有无遗漏文件，添加相关说明。
拉取服务器的代码，检查代码合并结果，若有冲突则找相关人员解决冲突。解决冲突后，重新编译测试代码，测试成功后提交本地代码。
推送代码到服务器。