Git基本信息配置
在我们使用Git分布式版本仓库前，要现在本地下载安装好Git，然后配置自己的基本信息，命令如下:
--配置用户信息
git config--global user.name "Your Name"
git config--global user.email "Your Email"
--查看用户配置
git config--global --list;
在本地初始化一个项目仓库，命令如下:
--执行之后可以看到，仅仅在项目目录中多出了一个.git目录
--关于版本等的信息都在这个目录里面
git init
--或者直接从远程仓库克隆一个到目的文件夹:
git clone "https://github.com/xx/xxx"
Git分支命名规范
在协同开发中，合理的分支命名有助于提高代码管理的效率和可读性。以下是一些常见的分支命名规范:
主分支
main或master:主分支，存放稳定的生产代码。-
develop:开发分支，存放最新的开发代码。
功能分支
功能分支用于开发新功能，通常从develop 或main 分支创建，完成后合并回原分支。
命名格式:feature/描述
示例:
feature/user-authentication-
feature/payment-integration
修复分支
修复分支用于修复代码中的 bug，通常从 develop 或 main 分支创建，完成后合并回原分支
命名格式: bugfix/描述
示例:
bugfix/fix-login-error-
bugfix/correct-typo
发布分支
发布分支用于准备发布版本，通常从 develop 或 main 分支创建，完成后合并回原分支
命名格式:release/版本号
示例:
release/1.0.0-
release/2.1.0
热修复分支
热修复分支用于紧急修复生产环境中的问题，通常从 develop 或 main 分支创建，完成后合并回原分支。
命名格式:hotfix/描述
示例:
hotfix/critical-bug
Git 提交信息标记指南
在使用 Git 进行版本控制时，规范的提交信息有助于团队成员快速了解每次提交的主要内容。以下是一些常用的提交信息标记及其含义:
常用标记
- feat: 新功能或特性
- 示例:
feat:添加用户登录功能
- 示例:
- fix:修复一个 bug
- 示例:
fix:修复登录页面的崩溃问题
- 示例:
- docs:仅仅修改了文档，比如 README、注释等
- 示例:
docs:更新README 文件
- 示例:
- style: 代码格式的修改，不影响代码逻辑(例如空格、格式化、缺少分号等)
- 示例:
style:统一代码格式
- 示例:
- refactor: 代码重构，既不是新增功能也不是修复 bug
- 示例:
refactor:重构用户认证模块
- 示例:
- perf: 提升性能的代码更改
- 示例:
perf:优化数据库查询性能
- 示例:
- test:添加或修改测试代码
- 示例:
test:添加用户登录功能的单元测试
- 示例:
- chore: 其他不修改 src 或测试文件的杂务(例如构建过程或辅助工具的变动)
- 示例:
chore:更新构建工具版本
- 示例:
- build: 影响构建系统或外部依赖的更改(例如 gulp、npm、webpack)
- 示例:
build:更新 webpack 配置
- 示例:
- ci:持续集成相关的更改(例如 Travis、Circle、Jenkins 配置文件)
- 示例:
ci:配置 TravisCI
- 示例:
- revert:回滚某次提交
- 示例:
revert:回滚上一次提交
- 示例: