Git 之 提交代码时的默认提交规则标签简单说明整理 feat/fix/doc/styles/revert/test/build等 Git 之 提交代码时的默认提交规则标签简单说明整理 feat/fix/doc/styles/revert/test/build等一、简单介绍Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。 [1] Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。本节介绍，Git 之 reset --hard 回退/回滚到之前的版本代码后，可能又由于冲动，可能需要恢复回退/回滚版本，这里简单整理回退的方法，如果有不足之处，欢迎指出，或者你有更好的方法，欢迎留言。二、常用的代码提交默认前缀标签规则1、feat: 新功能（feature）2、fix: 修补bug3、docs: 文档（documentation）4、style: 格式（不影响代码运行的变动）5、refactor: 重构（即不是新增功能，也不是修改bug的代码变动）6、chore: 构建过程或辅助工具的变动7、revert: 撤销，版本回退8、perf: 性能优化9、test：测试10、improvement: 改进11、build: 打包12、ci: 持续集成13、update:更新

Git分支命名规范 Git分支命名规范一、git分支命名规范git分支分为集成分支，功能分支、和修复分支。分别命名为develop，feature和hotfix，均为单数。不可使用features、future、hotfixes、hotfixs 等错误名称。分支名描述master / main主分支，永远是可用的稳定版本，不能直接在该分支上开发develop开发主分支，所有新功能以这个分支来创建自己的开发分支，该分支只做合并操作，不能直接在该分支上进行开发feature-xxx功能开发分支，在develop上创建分支，以自己开发功能模块命名，功能测试正常后合并到develop分支feature-xxx-fix功能bug修复分支，feature分支合并之后发现bug，在develop上创建分支进行修复，之后合并回develop分支hotfix-xxx紧急bug修改分支，在master分支上创建，修复完成后合并到masterbugfix短期从develop创建release短期从develop创建PS：1.feature分支在申请合并之后，未合并之前还是可以提交代码的，所以feature在合并之前还可以在原分支上继续修复bug2.一个分支尽量开发一个功能模块。不要多个功能模块在一个分支上开发3.feature分支在申请合并之前，最好是先pull一下主分支develop，看一下有没有冲突，如果有，先解决冲突后再申请合并二、Branch功能详解master 负责记录上线版本的迭代，该分支代码与线上代码是完全一致的主分支。develop负责记录相对稳定的版本，所有的feature分支和bugfix分支都从该分支创建开发分支feature用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成后并自测，自测通过之后，需要合并到develop分支，之后删除该分支。bugfix用于修复不紧急的bug，普通bug均需要创建bugfix分支开发，开发完成自测，pass之后合并到develop分支后删除该分支release用于代码上线准备，该分支从develop分支创建，创建之后由测试人员发布到测试环境进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，所有bug修复完成后，在上线之前，需要合并该release分支到master分支和develop分支。hotfix该分支只有在紧急情况下使用，从master分支创建，用于紧急修复线上bug，修复完成后，需要合并该分支到master分支以便上线，同时需要再合并到develop分支紧急bug修复分支。三、Branch命名规范分支名格式例子功能分支feature/功能名称feature/loginbug修复分支bugfix/bug名称bugfix/add-user紧急bug修复分支hotfix/bug名称hotfix/delete预发布分支release/预发布版本名称release/add-user四、分支用途详解我们刚刚熟悉了git中常用的分支，那么这些分支有什么意义呢？这么说吧，如果你是一个人开发，那么这确实没什么用，当你在一个团队时就发挥了很大的作用。一般作用下，master分支和线上版本是保持一致的，那么我们需要对它非常重视。一切开发任务都不能在这里进行。因为在开发过程中如果出现bug就会弄脏master分支。如果我们在develop分支上开发，不管出什么错误都不怕，因为master是干净的，实在不行可以从master重新拉取没有问题的项目。这个就是分支其中一个作用。现在是这样的情况：我们在develop分支上完成了项目，那么之后对各个分支是怎么处理呢？过程大概是这样的：将我们的develop分支合并到release分支，这个是一个预发布分支，这个预发布分支是交给测试的人员。测试人员在release分支上拉取完整项目进行测试，在测试过程中发现了一个bug。测试人员找到了开发人员，开发人员在release分支上修改好问题，所有问题都解决了，这时release分支合并到master分支和develop分支。这时开发人员的develop是最新的，master分支也是最新的。另外一种情况是这样的：线上产品使用过程中突然出现了一个bug，这时非常紧急的情况，这时需要处理的步骤大致如下：创建一个紧急bug分支名为hotfix，将master分支拉取到hotfix分支。紧急修改完bug之后将hotfix同步到master分支和develop分支，再删除hotfix分支。世界就恢复平静了。总之，分支会让你在更安全的环境下开发，git里面什么后悔药都有的。引用1.Git分支命名规范 : [https://blog.51cto.com/u_15057832/3527964](

Git代码Commit规范 <type>(<scope>): <subject>规范git commit到底有哪些好处呢？便于程序员对提交历史进行追溯，了解发生了什么情况。一旦约束了commit message，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰。格式化的commit message才可以用于自动化输出Change log。type(必须)用于说明git commit的类别，只允许使用下面的标识。typedescfeat新功能（feature）fix/to修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。fix：产生diff并自动修复此问题。适合于一次提交直接修复问题。to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fixdocs文档（documentation）style格式(不影响代码运行的变动)refactor重构（即不是新增功能，也不是修改bug的代码变动）。perf优化相关，比如提升性能、体验。test增加测试。chore构建过程或辅助工具的变动。revert回滚到上一个版本。merge代码合并。sync同步主线或分支的Bug。scope(可选)scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。例如在Angular，可以是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用*代替。subject(必须)subject是commit目的的简短描述，不超过50个字符。建议使用中文（感觉中国人用中文描述问题能更清楚一些）。结尾不加句号或其他标点符号。根据以上规范git commit message将是如下的格式：fix(DAO):用户查询缺少username属性 feat(Controller):用户查询接口开发