Git的使用和提交规范

Git的基础使用

1. git初始化

  • 下载git:地址是 git
  • 安装完成后,在github或者gitlab上复制http的clone链接,打开Git Bash\

git clone http://xxxx.git

  • 这样会在本地创建一个以项目名命名的文件夹,clone结束后就可以看到我们拉下来的项目了。

    • 做完 这些以后,还有很重要的一步,就是给你的git添加用户名和邮箱

git config --global user.name [username]
git config --global user.email [email]

  • 如果只是在我们公司自己的gitlab上使用git,这些已经够了,但是在github上使用git的时候,我们还需要获取我们的密钥,并且保存在github上就可以了

    $ ssh-keygen -t rsa -C "email"


将生成的ssh-key添加到你的github中吧。

2. git操作

  • 拉取操作

    git pull origin master 拉取主仓库的origin分支代码

  • 合并操作

    当你在dev分支想要合并master的代码,你可以git merge origin master
    如果有冲突的话,命令行会给出提示,按照提示操作,保留或者删除代码就可以了,之后重复提交操作。

  • 提交操作

    git add . / git add filename 添加你需要提交的文件, .表示所有更改的文件
    git commit -m 'any' 添加注释,跟代码的注释一样,很重要,具体的规范请看下一节
    git pull origin master在提交前,记得拉取更新,不然可能会报错,或者覆盖掉你的代码
    git push origin master` 最后一步,提交代码

  • 新建仓库和分支
    有时候,我们clone了项目后,已经有仓库地址,不需要新建了,但是有时候,我们还需要新建仓库,比如下面的操作。

    首先,你要清楚仓库的地址
    然后git remote add <name> <url> ,起一个自己喜欢的名字和仓库地址,这样一个本地仓库就创建成功了

    3. pull request

    pull request 是一种主要用于大型项目的提交方法, 在给开源框架贡献代码时,必须要用到这个,下面我们简称pr

    1. 首先我们要在源项目中,fork这个项目,生成一个属于你自己的代码仓库
    2. 在本地的文件中,pull项目地址,创建本地文件库。
    3. 此时你可以修改这个项目,并提交到你自己的仓库中,但是这个不是我们最终的需求,我们要提交到源框架中,这时,我们需要提交pr
    4. 在git上,创建一个合并请求,操作的话,都有步骤,我们这里不赘述。下面主要说一下如何去更新你本地的项目和源项目同步。因为源项目可能会有很多人员参与。
    5. 在本地git仓库中,添加一个新的地址,地址是源项目地址。
    6. 在每次提交pr之前,你需要先更新本地代码,合并源项目分支。
    7. git merge 仓库名 分支 这里的仓库和分支是你需要合并的源码仓库分支,新建仓库的方法在之前已经有介绍了

4. Git提交规范

4.1 Git commit日志基本规范
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
4.2 对格式的说明如下:
  • type代表某次提交的类型,比如是修复一个bug还是增加一个新的feature。所有的type类型如下:
  • feat: 新增feature
  • fix: 修复bug
  • docs: 仅仅修改了文档,比如README, CHANGELOG, CONTRIBUTE等等
  • style: 仅仅修改了空格、格式缩进、都好等等,不改变代码逻辑
  • refactor: 代码重构,没有加新功能或者修复bug
  • perf: 优化相关,比如提升性能、体验
  • test: 测试用例,包括单元测试、集成测试等
  • chore: 改变构建流程、或者增加依赖库、工具等
  • revert: 回滚到上一个版本
4.3 格式要求:
  • 标题行:50个字符以内,描述主要变更内容
  • 主体内容:更详细的说明文本,建议72个字符以内。 需要描述的信息包括:
  • 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
  • 他如何解决这个问题? 具体描述解决问题的步骤
  • 是否存在副作用、风险?
  • 尾部:如果需要的化可以添加一个链接到issue地址或者其它文档,或者关闭某个issue。
4.4 Git分支与版本发布规范
  • 基本原则:master为保护分支,不直接在master上进行代码修改和提交。

  • 开发日常需求或者项目时,从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复,功能测试完毕并且项目发布上线后,将feature分支合并到主干master,并且打Tag发布,最后删除开发分支。分支命名规范:

    • 分支版本命名规则:分支类型 分支发布时间 分支功能。比如:feature_20170401_fairy_flower
    • 分支类型包括:feature、 bugfix、refactor三种类型,即新功能开发、bug修复和代码重构
    • 时间使用年月日进行命名,不足2位补0
    • 分支功能命名使用snake case命名法,即下划线命名。
  • Tag包括3位版本,前缀使用v。比如v1.2.31。Tag命名规范:

    • 新功能开发使用第2位版本号,bug修复使用第3位版本号
    • 核心基础库或者Node中间价可以在大版本发布请使用灰度版本号,在版本后面加上后缀,用中划线分隔。alpha或者belta后面加上次数,即第几次alpha:
### 如何遵循 Git Commit Message 的规范提交 Bug Fix 在 Git 中,为了保持团队协作中的代码历史清晰易读,通常会采用一种标准化的 `Commit Message` 格式。对于修复 Bug 类型的提交信息,可以参考以下结构: #### 基本格式 ``` fix(<scope>): <short description> <body> <footer> ``` - **`fix`**: 表示该提交是一个 Bug 修复[^4]。 - **`<scope>`**: 描述更改影响的部分,例如模块名或文件名(可选)。如果范围广泛或者不确定,则可以省略。 - **`<short description>`**: 简短描述本次提交的核心改动,长度建议不超过 50 个字符[^1]。 --- #### 示例 假设我们修复了一个用户登录页面上的密码验证逻辑错误,以下是可能的提交消息: ```bash $ git commit -m "fix(user-authentication): repair password validation logic" ``` 如果有更详细的说明需求,可以在 `<body>` `<footer>` 部分补充更多信息。例如: ```text fix(user-authentication): repair password validation logic The previous implementation did not correctly handle special characters in passwords, resulting in incorrect error messages being displayed. Closes #123 ``` - **Body**: 提供关于此次修改的具体细节以及原因。 - **Footer**: 如果适用,可以在此处注明关联的 Issue 编号或其他元数据。 --- #### 工具支持 为了确保每次提交都符合约定俗成的标准,可以通过一些工具实现自动化检查提示: 1. 使用 `Husky` 结合 `validate-commit-msg` 来强制执行规则[^3]: ```json { "husky": { "hooks": { "commit-msg": "validate-commit-msg" } } } ``` 2. 安装并配置 `Commitizen` 或者类似的 CLI 工具帮助生成标准化的提交信息[^3]: ```bash npm install --save-dev @commitlint/cli @commitlint/config-conventional echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js ``` 通过这些方法能够有效减少人为失误带来的不一致性问题。 --- ### 总结 当涉及 Bug 修复时,请务必以 `fix` 开头撰写您的提交日志,并辅以简洁明了的主题句;必要情况下附加额外解释以便后续维护人员理解背景与目的所在。同时借助现代开发流程里的插件强化实践效果不失为明智之举!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值