git规范化开发

特性分支开发        

以前使用git基本都是随心所欲的用，commit的信息比较随便，所以有时git分支结构有时显得混乱，最近标准化开发的过程中接触了特性分支开发。

        何为特性分支，按我的理解，就是每一次代码的修改提交，都对应一种特性，这个特性可以是代码增加新功能,也可以是代码重构，代码修改比如修改bug，

常见的有以下特性

1. feat (Feature)

   • 用途: 用于新增功能或特性。
   • 示例: feat/user-authentication（用户认证功能）

2. fix (Bug Fix)

   • 用途: 用于修复程序中的错误或漏洞。
   • 示例: fix/login-bug（修复登录错误）

3. refactor

   • 用途: 用于代码重构，不涉及功能改变，目的是提高代码质量、可读性或性能。
   • 示例: refactor/user-service（重构用户服务模块） 

4. docs (Documentation)

   • 用途: 用于修改或添加文档内容。
   • 示例: docs/api-documentation（API文档更新）

 

因此我们写代码都是在特性分支写代码的，主分支被锁定，只有Pull Request才能合并

每次提交都会创建一个分支，这个分支称为特性分支，由负责人review后确认没问题然后合入主分支

 下面为一个示例的提交信息

然后git上会有很多分支，但是这些特性分支会在合并后被删除

gpg签名

总的来说就是一个鉴别身份的东西，每次提交都可以附上gpg签名，用来标识该代码是你提交的

然后可以通过git log --show-signature
命令查看自己提交的信息包含的gpg签名

git hook

git内置的一种脚本机制，可以在某些操作之前或之后触发，比如提交前触发代码检查等功能

在.git目录下找到hook可进行设置

fork与pr

我们经常能听到pr这个词，

fork就是将别人的公有仓库的代码复制到自己仓库，可以进行本地修改

pr：我的理解为请求合并代码的意思，当你发现fork的代码有bug时，在本地解决bug后可以进行pr，也就是pull request （看起来这个单词有些别扭），也就是将自己改的代码合并到原来的公共仓库，也就是你为这仓库做了贡献，当仓库同意了这个pr后，你修改的代码就到了这个仓库