Workflow in Git

Introduction

Workflow in Git, same as development model, are used in developing works based on Git among multi developers or big organizations.

Two Development Model in Git

As mentioned in , there are two main development models with which the developers can use PR.

Fork and Pull Model

In the fork and pull model, anyone can fork an existing repository and push changes to their personal fork without needing access to the source repository. The changes can be pulled into the source repository by the project maintainer. When you open a pull request proposing changes from your fork's branch to a branch in the source (upstream) repository, you can allow anyone with push access to the upstream repository to make changes to your pull request. This model is popular with open source projects as it reduces the amount of friction for new contributors and allows people to work independently without upfront coordination.

--- Quoting from About collaborative development models

Shared Repository Model

In the shared repository model, collaborators are granted push access to a single shared repository and topic branches are created when changes need to be made. Pull requests are useful in this model as they initiate code review and general discussion about a set of changes before the changes are merged into the main development branch. This model is more prevalent with small teams and organizations collaborating on private projects.

--- Quoting from About collaborative development models

Experiences in Real Work

Pull Request 的说明 -- Quoting from 我们是怎么做Code Review的

  1. 任务完成才能提交PR.
  2. PR应该在一个工作日内被合并或者被拒绝。
  3. PR在有严重问题(包括但不限于架构问题, 安全问题, 设计问题), 太多问题, 或者任务无效的情况下会被拒绝.
  4. 严禁一个PR里面有多个任务, 除非它们是紧密关联的.
  5. PR提交之后只允许针对Review发现问题再次提交代码, 除非有充足的理由, 严禁在同一个PR中再次提交其它任务的代码.
  6. 提交PR时候有一个描述框,内容会自动根据Commit的message合并而成。切记,如果一次提交的内容包含很多Commit,请不要使用自动生成的描述。请用简短但是足够说明问题的语言(理想是控制在3句话之内)来描述:
    a) 该Commit改动了什么
    b) 该Commit解决了什么问题
    c) 该Commit中有哪些需要代码审查的人留意的影响比较大的改动.

    特别需要留意, 如果对基础, 公共的组件进行了改动, 一定要另起一行特别说明.

  7. 审核人员邀请原则
    a) 在创建PR时, Reviewers(审核人)一栏里主要填写"必需审核人". 只有这些人审核都通过, 才允许合并.
    b) 除了"必需审核人"外, 还有一些其它审核人, 我们可以在Description里做为"邀请审核嘉宾"@进来(Git的@mention机制).
    c) 主干分支间的合并, 如Develop->Master, 或Master->Develop等, 则需要把整个团队(DEV+QA)都列为"必需审核人".

    "必需审核人"的列表由团队决定, 可能包括以下人选:
    团队Leader
    前端架构师(如果有前端代码改动) (可以授权)
    后端架构师(如果有后端代码改动) (可以授权)
    产品架构师
    对此PR解决的问题比较熟悉的(之前一直负责这部分业务的同事)
    此PR解决的问题对他影响比较大(比如认领的任务依赖此PR的同事)
    其它审核人,包括但不限于
    a) 需要知悉此处代码改动的人但又不必非要其审核通过的同事
    b) 可以从这个PR中学习的同事

    可以授权指的是,根据约定,Bug修复之类的改动,或者影响较小的改动,前端架构师和后端架构师可以授权团队内的某个资深开发人员,由这个资深开发人员代表他们进行审核。

  8. 主干分支之间的合并,大型Feature的合并,前端架构师和后端架构师需要参与。
    上述审核人关注的视角不太一样:
    团队Leader关注你是否完成了任务
    前后端架构师关注是否符合公司统一的架构、风格、质量
    产品架构师从整个产品层面来关注这个PR。
    熟悉此问题的同事可以更好的保证问题被解决,确保没有引入新问题。
    被影响的同事可以及时了解他受到的影响.

  9. 团队Leader或者产品架构师如果觉得PR邀请的审核者不足或者过多,必须调整为合适的人员,其它同事可以在评论中建议。

References

What is the Fork & Pull Model in GitHub? - StackOverFlow
About collaborative development models
我们是怎么做Code Review的
GitHub Guides

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据