Git的使用和提交规范

最新推荐文章于 2025-06-09 10:52:08 发布
最新推荐文章于 2025-06-09 10:52:08 发布
阅读量722 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： git 文章标签： git pull request
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/wangdan_2013/article/details/81505068

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 提交规范
蜡笔小谢的博客
01-16 5710
在团队协作中，合理的提交规范能够帮助开发者提高代码质量、简化代码审查流程，并促进更高效的团队协作。本文介绍 Git commit 提交规范的重要性，并分享一些最佳实践，帮助开发者更好地管理和记录代码提交。
Git 完整的提交规范教程
余十步的博客
07-06 2222
本文中的关键词 “必须（MUST）”、“禁止（MUST NOT）”、“必要（REQUIRED）”、“应当（SHALL）”、“不应当（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“可以（MAY）” 和 “可选（OPTIONAL）”
git提交代码常用规范
12-30
git提交代码常用规范
Git的基础使用
weixin_33694172的博客
08-08 105
Git的基础使用 1. git初始化 下载git：地址是 git 安装完成后，在github或者gitlab上复制http的clone链接，打开Git Bash\ git clone http://xxxx.git 这样会在本地创建一个以项目名命名的文件夹，clone结束后就可以看到我们拉下来的项目了。 做完 这些以后，还有很重要的一步，就是给你的git添加用户名和邮箱 gi...
Git提交规范
最新发布
m0_54228768的博客
06-09 541
使用首字母小写的驼峰命名。除具体的模块、组件名之外，可以使用 base 表示基础结构、框架相关的改动，用 misc 表示杂项改动，用 all 表示大范围重构。例如在Angular，可以是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。其中，type、scope、subject是必需的，description 可以省略。scope用于说明 commit影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
Git 代码提交规范
猫老板的豆
10-24 614
用于提交仅格式化、标点符号、空白等不影响代码运行的变更。例如：ci: 修改GitHub Actions配置文件。例如：revert: 回滚feat: 增加用户注册功能。用于提交构建过程、辅助工具等相关的内容修改。例如：test: 增加用户模块的单元测试。例如：fix: 修复登录页面崩溃的问题。例如：feat: 增加用户注册功能。例如：style: 删除多余的空行。用于提交CI配置文件和脚本的修改。用于提交提升性能的代码修改。用于提交仅文档相关的修改。用于提交回滚之前的提交。
git代码提交规范
weixin_65950986的博客
11-15 540
提交规范有助于保持代码库的一致性，帮助审查和检查的时候提高效率，当然公司没有要求也不是必须要按照规范来。
git使用流程和规范1
08-04
本文主要探讨了在团队中如何有效地使用 Git，以实现高效的工作流程和规范，从而提高团队的长期工作效率，灵活应对产品需求变化，以及方便自动化测试和部署。 首先，我们来看一种常见的 Git 工作流模型——git-flow...
git使用规范（绝密）.pdf
06-29
在提交规范方面，规范中明确禁止了使用强制推送命令（如`git push -f`或`git push --force`）覆盖中央仓库的内容，除非开发人员确实知道自己在做什么。因为强制推送会覆盖远程分支上的提交，可能会导致其他人的提交...
git-commit-lint-vscode:vscode一款git 规范化提交插件
05-17
这个插件就是规范化git提交规范,让你的提交不仅"好看"还"实用" git 规范提交从何说起? git 规范提交从哪里开始的呢?起源在哪呢?emmmmmm,这就追溯到了Angular了! 让我们看下Angular社区的提交规范 这个提交记录是不是...
Git代码提交规范
可可的博客
12-06 1354
1.安装commitizen和cz-customizable 2.在package.json中进行新增 3.在根目录下新建.cz-config.js文件并写入配置 之后就可以用 git cz 来代替 git commit 1.使用husky进行强制git代码提交规范 多出一个文件 2.导入配置文件 3.在package.json中新增指令 4.并执行 5.新增husky配置文件 并往里面写入 写 效果 5.使用husky强制代码格式化 创建配置文件 6.往第六步生成的文件中写入 8.把package
Git代码提交规范指南
一个摩拉的博客
05-20 713
良好的提交信息规范能显著提升代码的可维护性和团队协作效率。
git 代码提交规范
m0_37641682的博客
05-27 224
commit message = subject + : + 空格 + message 主体​。refactor：代码重构（既不是新增功能也不是修复bug的代码更改）chore：杂项（构建过程或辅助工具的变动）style：代码风格变动（不影响代码逻辑）build：构建系统或外部依赖项变更。feat：新功能（feature）test：添加或修改测试。ci：持续集成配置的更改。记录一下，防止自己忘记。fix：修复 bug。
git提交代码规范
AKA石头
05-03 3200
Git提交代码规范 本规范大部分适用于规范研发体系所有软件工程师的Git提交 相关名字解释 [SC] 表示第三方的 source code，比如框架代码，开源代码 [NF] 表示新的 feature [IM] 表示功能改进等 [BF] 表示修复 bug [EN] 表示提交的加密代码 [Release] 发布版本 内容完整性要求 git 提交时必须说明本次操作的目的，尽量详细的说明修改内容，不允许使用 “fix、modify”等简单词汇进行备注，修复bug 时带上bug号如#2234 举个栗子 [
【软件开发规范篇】Git代码提交规范
分享是一种境界，勤于分享，乐于分享！
04-28 4414
本文介绍软件项目开发过程中，代码提交到git仓库，建议遵循的一些规范。每次提交代码到 Git 仓库时，都需要写 commit message。通常情况下，commit message 应该清晰明了，说明本次提交的目的和具体操作等。然而，在日常开发中，开发者们提交的 commit message 千差万别，中英文混用，导致后续代码维护成本很高，有时候甚至自己都不知道修复的是什么问题。因此，为了解决这些问题，建议大家在提交代码的时候，能遵循一些规范或约定，从而提高代码规范，提高开发效率。
git修改bug提交规范
04-25
### 如何遵循 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、付费专栏及课程。

余额充值