Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

团队规范系列之 git 规范 #70

Open
bosens-China opened this issue Jun 7, 2021 · 0 comments
Open

团队规范系列之 git 规范 #70

bosens-China opened this issue Jun 7, 2021 · 0 comments
Labels
代码规范 团队规范、代码规范、技术选型等相关内容

Comments

@bosens-China
Copy link
Owner

bosens-China commented Jun 7, 2021 •
edited
Loading

最近一周的工作重心就是在梳理团队规范，在写的过程也查缺补漏了不少知识，剔除掉关于公司场景的部分就有了这一系列的文章，预计写四部分：

  1. git规范
  2. 工程规范
  3. 用户体验规范
  4. 命名规范

Git 规范

Git 作为现在最流行的分布式管理工具，基本上是每个团队的必备，下面就从分支和提交这两部分展开

什么是分支

分支就是把你的工作从开发主线上分离开来，以免影响开发主线，假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了 50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

1.png

分支如何命名

分支按照类型可以分为以下几种

分支名称 命名 说明
主分支 master 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布
开发主分支 develop 开发分支，永远是功能最新最全的分支
功能分支 feature-* 新功能分支，某个功能点正在开发阶段
发布版本 release-* 发布定期要上线的功能
修复发布版本分支 bugfix-release-* 修复测试 bug
紧急修复分支 bugfix-master-* 紧急修复线上代码的 bug

开发流程示例

下面就以一个产品从最初到发布上线为例子，讲解 git 流程

初始化

第一步，初始仓库的信息，同时创建develop分支

2.png

开发新功能

开发人员在develop分支开发新的功能，包括:新特性与 Bug 修复

3.png

如果并行开发多个需求，可以创建 feature 分支，命名规则为feature-分支创建日期-新特性关键字，例如:feature-20190919-i18n

4.png

开发完成之后将 feature 分支合并到 develop 分支，最后删除 feature 分支

什么时候使用 feature

  • 开发一个独立的新特性(完成时，需合并到 develop 分支)
  • 技术研究与尝试(若失败，可随时删除 feature 分支)
  • 提前实现下一个版本需要开发的特性(可不在本次迭代中发布)

准备发布版本

如果 develop 分支上的功开发完毕

  1. 建 release 分支(发布分支)命名规则:release-分支创建日期-待发布版本号，例如：release-20190919-v1.0.0
  2. 对 release 分支的版本号进行修改（之后提交一次）
  3. 通知测试人员测试

5.png

修复问题

开发人员在 release 修复问题，此时禁止开发新功能，只对 bug 进行修复

6.png

最终发布

经过测试没有发现问题，或者问题已经全部修复，这个时候

  1. 将 release 分支同时合并到 master 分支与 develop 分支

    • 通知测试，进行主分支测试
    • 如果没问题，进行下一步，如果有问题回到 release

  2. 删除 release 分支

  3. 构建应用到服务器

7.png

commit 规范

目前开源社区主要应用是规范是Angular Git Commit Guidelines

它由下面几部分组成:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type

本次 commit 的类型，诸如 bugfix、docs、style 等

完整的类型如下：

名称 描述
feat 添加新特性
fix 修复 bug
docs 仅仅修改了文档
style 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
refactor 代码重构，没有加新功能或者修复 bug
perf 增加代码进行性能测试
test 增加测试用例
chore 改变构建流程、或者增加依赖库、工具等

scope

本次 commit 波及的范围

subject

简明扼要的阐述下本次 commit 的主旨

有几点需要注意：

  1. 首字母不要大写
  2. 结尾无需添加标点

body

主体内容，我们需要把本次 commit 详细的描述一下，比如此次变更的动机等，不能超出 72 个字符

为什么需要

  • 它可能是用来修复一个 bug，增加一个 feature，提升性能、可靠性、稳定性等等
  • 它如何解决这个问题? 具体描述解决问题的步骤
  • 是否存在副作用、风险?

footer

描述下与之关联的 issue 或 break change，在公司项目中基本忽略即可

参考文章
@bosens-China bosens-China added the 其他 未找到分类，暂定的文章 label Jun 7, 2021
This was referenced Jun 8, 2021
Open
Open
Open
@bosens-China bosens-China added 代码规范 团队规范、代码规范、技术选型等相关内容 and removed 其他 未找到分类，暂定的文章 labels Dec 21, 2021
@bosens-China bosens-China changed the title 团队规范系列之git规范 团队规范系列之 git 规范 Dec 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
代码规范 团队规范、代码规范、技术选型等相关内容
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@bosens-China