规范提交

月晕52
167 阅读9分钟

规范提交

规范提交：一般是指使用git进行分布式版本控制系统管理

1.Git 规范必要性

有效高速的管理从小到大的项目版本管理

1.1 分支管理

  • 代码提交在对应的分支中

这里指的是不同的项目有不同的分支可以在自己的分支中提交代码，然后进行 code review 之后进行合并分支，删除单独分支

  • 随时切换到线上的稳定版本
  • 多个版本开发工作同时进行

1.2 提交记录的可读性

  • 进行准确的提交描述，具备可检索性

    比如 git commit 你现在完成了一个功能比如是完成了一个接口/Register git commit -m "完成了/register 接口的 xxx 功能"

  • 合理的提交范围，避免一个功能就一笔提交

  • 分支间的合并保有提交历史，且合并后结果清晰

1.3 团队协作

  • 明确每个分支的功用，做到对应的分支执行对应的操作
  • 合理的提交，每次提交有明确的改动范围和规范的提交信息
  • 使用 Git 管理版本迭代、紧急线上 bug fix、功能开发等任务

2.分支管理规范

2.1 分支说明和操作

  • master 分支

    • 主分支，永远处于稳定状态，对应当前线上版本
    • 以 tag 标记一个版本，因此在 master 分支上看到的每一个 tag 都应该对应一个线上版本
    • 不允许在该分支直接提交代码

  • develop 分支

    • 开发分支，包含了项目最新的功能和代码，所有开发都依赖 develop 分支进行

    • 小的改动可以直接在 develop 分支进行，改动较多时切出新的 feature 分支进行

    注： 更好的做法是 develop 分支作为开发的主分支，也不允许直接提交代码。小改动也应该以 feature 分支提 merge request 合并，目的是保证每个改动都经过了强制代码 review，降低代码风险。

  • feature 分支

    • 功能分支，开发新功能的分支
    • 开发新的功能或者改动较大的调整，从 develop 分支切换出 feature 分支，分支名称为 feature/xxx
    • 开发完成后合并回 develop 分支并且删除该 feature/xxx 分支

  • release 分支

    • 发布分支，新功能合并到 develop 分支，准备发布新版本时使用的分支
    • 当 develop 分支完成功能合并和部分 bug fix，准备发布新版本时，切出一个 release 分支，来做发布前的准备，分支名约定为release/xxx
    • 发布之前发现的 bug 就直接在这个分支上修复，确定准备发版本就合并到 master 分支，完成发布，同时合并到 develop 分支

  • hotfix 分支

    • 紧急修复线上 bug 分支
    • 当线上版本出现 bug 时，从 master 分支切出一个 hotfix/xxx 分支，完成 bug 修复，然后将 hotfix/xxx 合并到 master 和 develop 分支(如果此时存在 release 分支，则应该合并到 release 分支)，合并完成后删除该 hotfix/xxx 分支

details 总结

  • master 分支: 线上稳定版本分支
  • develop 分支: 开发分支，衍生出 feature 分支和 release 分支
  • release 分支: 发布分支，准备待发布版本的分支，存在多个，版本发布之后删除
  • feature 分支: 功能分支，完成特定功能开发的分支，存在多个，功能合并之后删除
  • hotfix 分支: 紧急热修复分支，存在多个，紧急版本发布之后删除

2.2 分支间操作注意事项

  • 同一分支git pull使用 rebase

    git pull 默认为 merge 行为，当更新代码时，如果本地存在未推送到远程的提交，则会产生这样的 merge 的提交记录因此在同一个分支上更新代码时推荐使用 git pull --rebase。

    默认的 git pull 行为是 merge，可以进行如下设置修改默认的 git pull 行为：

# 为某个分支单独设置，这里是设置 dev 分支
git config branch.dev.rebase true
# 全局设置，所有的分支 git pull 均使用 --rebase
git config --global pull.rebase true
git config --global branch.autoSetupRebase always

具体可以参考 ： 在开发过程中使用 git rebase 还是 git merge，优缺点分别是什么？

  • 分支合并使用 --no-ff

      # 例如当前在 develop 分支，需要合并 feature/xxx 分支
  git merge --no-ff feature/xxx

    首先理解 Git 中的fast-forward,比如在开发的过程中我们一直在推进develop分支上面的工作，此时有一个新功能需要开发，新建一个feature/a分支，并在其上进行一系列的提交开发，当完成开发的时候，此时需要 merge 到develop分支，此时就需要在develop 分支在创建feature/a分支后没有产生任何 commit，此时的合并就叫fast-forward fast-forward 合并的结果如下图所示，这种 merge 的结果就是一条直线了，无法明确看到切出一个新的 feature 分支，并完成了一个新的功能开发，因此此时比较推荐使用 git merge --no-ff ，得到的结果就很明确知道，新的一系列提交是完成了一个新的功能，如果需要对这个功能进行 code review，那么只需要检视叉的那条线上的提交即可。 git_merge_diff.svg

3.提交信息规范

git commit 格式 如下：

<type>(<scope>)：<subject>

部分说明:

  • type 类型，提交的类别

    • feat：新功能
    • fix：修复 bug
    • docs：文档变动
    • style：格式调整，对代码实际运行没有改动，例如添加空行、格式化等
    • refactor：bug 修复和添加新功能之外的代码改动
    • perf：提升性能的改动
    • test：添加或修正测试代码
    • chore：构建过程或辅助工具和库（如文档生成）的更改

  • scope修改范围 主要是这次修改涉及到的部分，简单概括，例如 login、train-order

  • subject 修改的描述 具体的修改描述信息

  • 实例

    feat(detail)：详情页修改样式
fix(login)：登录页面错误处理
test(list)：列表页添加测试代码
    1. type + scope 能够控制每笔提交改动的文件尽可能少且集中，避免一次很多文件改动或者多个改动合成一笔
    2. subject 对于大部分国内项目而已，如果团队整体英文不是较高水平，比较推荐使用中文，方便阅读和检索。
    3. 避免重复的提交信息，如果发现上一笔提交没改完整，可以使用 git commit --amend 指令追加改动，尽量避免重复的提交信息。 :::

4.具体的git 操作示例演示

4.1 PR：具体演示下在 github 中提 pr 的操作

  • Fork 仓库

PRFork.png

点击 fork 后

PRCreateFork.png

这样你的账号就有一个和原仓库一模一样的仓库了，可以进行修改了

  • Clone 仓库

PRClone.png

  • Git Commit

    在本地修改好的项目，可以按照正常流程直接推送到仓库

PRNEW.png

之后再点击 Create pull requests 创建拉取请求

PRCreate.png

最后输入标题和信息之后，即可点击 Create pull requests，便可以提交 PR 了

PRConfirm.png

  • 避免分支冲突

    在每次提交 PR 之前，需要保证你拉取的代码必须是最新的，可以在修改之前先拉取一次最新的代码

    拉取最新的代码可以在仓库的 Fetch upstream 选择中，点击 Fetch and merge 进行同步

4.2 Github中的Issues提问

::: tip 用途 对开源项目来说，问题追踪是很重要的。在整个GitHub，谁都可以提问issue，谁都可以对issue问题进行回答。但如果没有适当的处理，项目会变得很庞大，挤满重复的bug issue、模糊不明的feature request。项目维护者会被大量工作压得喘不过气来，新的贡献者也搞不清楚项目当前的工作重点是什么。 :::

  • Issue提问前提

    1. 提问使用的语言：一般是维护者的母语，当然使用英语是都可行的
    2. 有Issue模板，请参照模板写Issue

  • Bug report：描述在学习中遇到的问题

    1. 为了避免无效提问和冗余提问，提问前请确定
      • 确定Google不能解决你的问题
      • 确定已有的Issue不能解决你的问题
      • 确定issue的title按照格式如下：[tutorial-code]：description
    2. Describe the bug 描述你遇到的问题：简洁有效
    3. To Reproduce 如何重现问题
    4. Expected behavior 期待修复的效果
    5. Screenshots 如有必要，可以截图说明
    6. 环境版本说明
      • OS: [e.g. win] 说明操作系统
      • Python Version 说明语言及版本号
      • Package Version 相关库/包的版本
      • Browser [e.g. chrome, safari] 如果有必要，说明浏览器型号
    7. Additional context 其他说明 添加你认为有必要的内容，否则不写。

  • Feature request：帮助维护教程的有效性

    1. 描述对应的教程内容
    2. 说出你的解决建议
    3. 如果你有其他想法，可以在此补充
    4. 其他内容

  • 一个好问题的标准

    1. 避免使用术语或晦涩的文字
    2. 问题可以切分，也就是说可以逐步解决的问题
    3. 尽量跟其他问题没有瓜葛，依赖其它问题会降低处理的灵活性
    4. 可以协商，也就说我们有好几种办法达到目标
    5. 问题足够小，可以非常容易的评估出所需时间和资源
    6. 可衡量，我们可以对结果进行测试

  • Labels 标签

    高质量的issue是项目成功的关键。有些人把issue仅仅看作是一堆你不得不去处理的问题列表，但是如果这些问题单管理完善，进行了分类并打上标签，会令人意想不到的提升我们对代码和社区的了解程度，也让我们更清楚问题的关键点在哪里。

  • Make Issue Steps 提问步骤 初步了解issue后，下面介绍如何提issue。首先你要确认你的问题Google无法解答，因为Google还是作为首推的解答平台。

  • Answer Issue Steps 回答步骤 每个人不仅仅可以提问，还可以回答他人的问题。

avatar
文章
阅读
粉丝