Git分支管理规范

git 评论

前言

Git分支模型

Git-Flow的经典流程图

分支管理规范

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 分支

以上就是在项目中应该出现的分支以及每个分支功能的说明。
其中稳定长期存在的分支只有 master 和 develop 分支，别的分支在完成对应的使命之后都会合并到这两个分支然后被删除。简单总结如下：

  • master 分支: 线上稳定版本分支, 该分支代码与线上代码是完全一致的。
  • develop 分支: 开发分支，衍生出 feature 分支和 release 分支
  • release 分支: 发布分支，准备待发布版本的分支，存在多个，版本发布之后删除。该分支从 develop 分支创建，创建之后由测试人员发布到测试环境进行测试。
  • feature 分支: 功能分支，完成特定功能开发的分支，存在多个，功能合并之后删除
  • hotfix 分支: 紧急热修复分支，存在多个，紧急版本发布之后删除

2. 项目分支操作流程示例

这部分内容结合日常项目的开发流程，涉及到开发新功能、分支合并、发布新版本以及发布紧急修复版本等操作，展示常用的命令和操作。

  1. 切到 develop 分支，更新 develop 最新代码

    1
    2
    git checkout develop
    git pull --rebase

  2. 新建 feature 分支，开发新功能

    1
    2
    3
    4
    5
    6
    7
    git checkout -b feature/xxx
    ...
    git add <files>
    git commit -m "feat(xxx): commit a"
    git commit -m "feat(xxx): commit b"
    # 其他提交
    ...

    如果此时 develop 分支有一笔提交，影响到你的 feature 开发，可以 rebase develop 分支，前提是 该 feature 分支只有你自己一个在开发，如果多人都在该分支，需要进行协调：

    1
    2
    3
    4
    5
    6
    7
    8
    # 切换到 develop 分支并更新 develop 分支代码
    git checkout develop
    git pull --rebase
    # 切回 feature 分支
    git checkout feature/xxx
    git rebase develop
    # 如果需要提交到远端，且之前已经提交到远端，此时需要强推(强推需慎重！)
    git push --force

    上述场景也可以通过 git cherry-pick 来实现，有兴趣的可以去了解一下这个指令。

  3. 完成 feature 分支，合并到 develop 分支

    1
    2
    3
    4
    5
    6
    7
    8
    9
    # 切到 develop 分支，更新下代码
    git check develop
    git pull --rebase
    # 合并 feature 分支
    git merge feature/xxx --no-ff
    # 删除 feature 分支
    git branch -d feature/xxx
    # 推到远端
    git push origin develop

  4. 当某个版本所有的 feature 分支均合并到 develop 分支，就可以切出 release 分支，准备发布新版本，提交测试并进行 bug fix

    1
    2
    3
    4
    5
    # 当前在 develop 分支
    git checkout -b release/xxx
    # 在 release/xxx 分支进行 bug fix
    git commit -m "fix(xxx): xxxxx"
    ...

  5. 所有 bug 修复完成，准备发布新版本

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    # master 分支合并 release 分支并添加 tag
    git checkout master
    git merge --no-ff release/xxx --no-ff
    # 添加版本标记，这里可以使用版本发布日期或者具体的版本号
    git tag 1.0.0
    # develop 分支合并 release 分支
    git checkout develop
    git merge --no-ff release/xxx
    # 删除 release 分支
    git branch -d release/xxx

    至此，一个新版本发布完成。

  6. 线上出现 bug，需要紧急发布修复版本

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    # 当前在 master 分支
    git checkout master
    # 切出 hotfix 分支
    git checkout -b hotfix/xxx
    ... 进行 bug fix 提交
    # master 分支合并 hotfix 分支并添加 tag(紧急版本)
    git checkout master
    git merge --no-ff hotfix/xxx --no-ff
    # 添加版本标记，这里可以使用版本发布日期或者具体的版本号
    git tag 1.0.1
    # develop 分支合并 hotfix 分支(如果此时存在 release 分支的话，应当合并到 release 分支)
    git checkout develop
    git merge --no-ff hotfix/xxx
    # 删除 hotfix 分支
    git branch -d hotfix/xxx

    至此，紧急版本发布完成。

3. 提交信息规范

提交信息规范部分参考 Angular.js commit messgae。

git commit 格式 如下：

1
2
3
4
5
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

各个部分的说明如下：

  • type 类型，提交的类别

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

  • scope 修改范围

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

  • subject 修改的描述

    具体的修改描述信息

  • 范例

    1
    2
    3
    feat(detail): 详情页修改样式
    fix(login): 登录页面错误处理
    test(list): 列表页添加测试代码

这里对提交规范加几点说明：

  1. type + scope 能够控制每笔提交改动的文件尽可能少且集中，避免一次很多文件改动或者多个改动合成一笔。
  2. subject 对于大部分国内项目而已，如果团队整体英文不是较高水平，比较推荐使用中文，方便阅读和检索。
  3. 避免重复的提交信息，如果发现上一笔提交没改完整，可以使用 git commit --amend 指令追加改动，尽量避免重复的提交信息。

最后

本文到此结束，感谢阅读。如果您觉得不错，请关注公众号【当我遇上你】，您的支持是我写作的最大动力。

参考

当我遇上你

勿在浮沙筑高楼