Git Flow——基于Git的⼯作流

1. 版本控制及代码管理

分⽀类型

  • 主⼲分⽀: master
    <mark>有且只有⼀个</mark>
    <mark>代码经过严格测试, 最稳定, 可以随时上线</mark>
  • 开发分⽀: develop
    <mark>有且只有⼀个</mark>
    <mark>合并了各个开发者最新完成的功能</mark>
    <mark>经过了初步测试, 没有明显 BUG</mark>
    <mark>⼀个周期的功能完成后需要合并到 master 分⽀</mark>
  • 功能分⽀: feature
    <mark>可以有个很多个</mark>
    <mark>每次开发⼀个新的功能时，都会创建⼀个feature分⽀</mark>
    <mark>是功能开发中的状态</mark>
    <mark>代码最不稳定</mark>
    <mark>开发完成后需要合并到 develop 分⽀</mark>

Pull Request: 拉取请求

  • 开发者⾃⼰提交 Pull Request 通知团队成员来合并⾃⼰提交的代码。
  • 通过此⽅式可以将合并过程暴露给团队成员, 让代码在合并之前可以被团队其他成员审核, 保证代码质量。

Code Review: 代码审核

  • 代码逻辑问题
  • 算法问题
  • 错误的使⽤⽅式
  • 代码⻛格及规范化问题
  • 学习其他⼈的优秀代码

2. 上线流程介绍

⼤型项⽬代码布局

1.概览


2.布局详解

  • 通⽤的算法、功能放到 common ⽬录
  • 底层的功能放到 lib ⽬录
  • 独⽴脚本的放到 scripts ⽬录
  • 配置⽂件放到项⽬⽬录 或 config ⽬录
  • views.py 及 view_func()
    <mark>1. MVC 模式的 V 只负责试图处理, 逻辑属于 Controller 层</mark>
    <mark>2. view_func 本身不适合写逻辑, view 是特殊函数, 只负责视图处理。</mark>
    <mark>3. 添加 helper.py ⽂件, ⽤来放置每个 app 的逻辑函数</mark>
    <mark>4. 函数构建应保持功能单⼀, ⼀个函数只做⼀件事情, 并把它做好, 避免构建复杂函数</mark>
    <mark>5. 复杂功能通过不同函数组合完成</mark>

项⽬阶段开发流程及要求

  1. 两⼈⼀组, 结组编程, 每组不要超过三⼈
  2. 每组选⼀⼈作为组⻓, 由组⻓在 Github 上创建⾃⼰的组和项⽬
  3. 组⻓分配任务, 各⾃开发⾃⼰的功能
  4. 开发过程中注意编码规范, ⼒求做到 “团队代码如同⼀⼈编写”
  5. 每个⼈为接到的功能创建⼀个独⽴的分⽀
  6. 开发、提交、审核、合并、上线