Git分支建立及提交规范

git
版本控制工具
发布日期:   2021-08-20
更新日期:   2024-06-12
文章字数:   1.6k
阅读时长:   5 分
阅读次数:  

分支建立规范

Git主要分支说明：

  • Master
    • 主分支，维护发布产品的代码，存储了正式发布的历史版本
  • Develop
    • 开发分支，作为功能的集成分支，维护开发中的代码，代码最终要合入Master分支
  • Feature
    • 开自Develop分支，主要用于开发新功能，开发者根据自己负责模块自行维护，模块开发完成并自测通过后，代码合入Develop分支，新功能提交应该从不直接与master分支交互
    • 命名规范为：feature/#…，每一个功能都应对应一个issue，…即为issue号
    • 开发中的合并代码采用rebase方法（可以使分支的提交历史看上去更简洁，详细可见rebase与merge的对比），具体方法如下：
      • 新建feature分支：git checkout develop， git branch feature/#…， git checkout feature/#…
      • feature分支开发一段功能后：git add.， git commit -m “…”， git checkout develop， git pull origin develop， git checkout feature/#…， git rebase develop（代码依次为提交本次代码，添加提交信息，切换到develop分支并拉取最新分支，切换回feature分支，rebase develop分支）
      • 在rebase develop分支时，可能会产生conflict，此时仍在rebase过程中，这时需要手动修改代码解决冲突，然后解决完该次冲突（rebase会对比每次未合入develop分支的提交，可能每次提交都会有冲突）后，再执行git add.，git rebase –continue命令，rebase完成后，即可push代码。
      • 多个分支同时开发时，应当频繁地将测试后可运行的feature分支更新到dev分支，每次更新dev分支时通知其他开发人员，拉取最新的dev分支，将自己正在开发的分支rebase dev分支。这样可以避免较长时间没有进行rebase而导致的冲突较多问题。
  • Bugfix
    • 开自Develop分支或者Release分支，主要用于修复当前开发中的功能的已知bug；每一个已发现的bug都应该在gitlab中记录issue，并定期更新当前解决进展，如有有价值的思考或独特的解决方法，可以在issue中评论并在wiki的技术知识库或个人空间博文中进行记录。
    • 命名规范为：bugfix/#…
  • Hotfix
    • 开自Master分支，主要用于修复当前已发布版本的已知bug；解决bug时注意事项参考Bugfix。这是唯一可以直接从master分支fork出来的分支。修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。你可以把它想成是一个直接在master分支上处理的临时发布。
    • 命名规范为：hotfix/#…
  • Release
    • 开自Develop分支，主要用于发布版本，一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上 —— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。一旦对外发布的工作都完成了，执行以下三个操作：
    • 合并Release分支到Master；
    • 给Master打上对应版本的标签tag；
    • Release回归，这些从新建发布分支以来的做的修改要合并回develop分支。
    • 命名规范为：release/…，…即为版本号

代码提交规范(常用)

  • 建议经常用命令git status查看当前所在分支并用git log查看当前分支记录，每次提交前与checkout分支时都先查看当前分支再进行下一步操作
  • 提交信息的说明，禁止无意义的日志语言，如modify，修改xxx文件等，任何修改都应该简要说明
  • Commit message格式 <type>: <subject> 注意冒号后面有空格
  • type 用于说明 commit 的类别，使用下列之一
    • feat：新功能（feature）
    • fix：修补bug
    • docs：文档（documentation）
    • style： 格式（不影响代码运行的变动）
    • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
    • test：增加测试
    • chore：构建过程或辅助工具的变动
  • subject
    • subject是 commit 目的的简短描述，不超过50个字符，且结尾不加句号（.）。
    • 提交分支合并请求之前的基础原则，如本地编译通过、手工或者自动化验收的测试通过

也可使用约定式提交规范(更详细提交记录)

  • 使用约定式提交规范（Conventional Commits），它受到了 Angular 提交准则的启发，并在很大程度上以其为依据。约定式提交规范是一种基于提交消息的轻量级约定。 它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与 SemVer 相吻合，在提交信息中描述新特性、bug 修复和破坏性变更。它的 message 格式如下: 
    <type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  • type
    • type 用于说明 commit 的类别，使用下列之一
      • feat：新功能（feature）
      • fix：修补 bug
      • docs：文档（documentation）
      • style： 格式（不影响代码运行的变动）
      • revert：回滚到上一个版本
      • refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）
      • test：增加测试
      • chore：构建过程或辅助工具的变动
      • perf：性能优化
      • ci：持续集成
  • scope
    • scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层、配置文件等等。如果 commit 影响的范围比较小，可以不写 scope。如果 commit 影响的范围比较大，可以写成*
  • subject
    • subject 是 commit 目的的简短描述，不超过 50 个字符，结尾不加句号
  • body
    • body 是对本次 commit 的详细描述，可以分成多行
  • footer
    • footer 用于不兼容变动或关闭 issue。不兼容变动是指在当前代码库中存在用户代码与之前版本不兼容时，footer 部分以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法
git
赏
  目录