💡
gumi Vietnam
  • Home
    • COMPANY POLICY
      • Company Internal Regulation
      • Overtime Register Flow
    • DEVELOPMENT POLICY
      • General
        • Digital Asset Management
        • Server Management
        • Backlog Flow
      • Git Rule
        • Branch Management
        • Committing Code
        • Release Management
          • Create Pull Request (PR)
          • Semantic Versioning
        • Git Security
        • Git Security Checklist
        • Git Flow
        • Rules of Git commit message
        • Information in commit messages
      • Coding Convention
        • HTML/CSS Basic Note
        • Google HTML/CSS Rule
        • Sass Guideline
        • JavaScript Rule
        • Vue.js Rule
          • Style Guide
          • TypeScript with Composition API
          • Nuxt and Typescript Coding Convention
            • Nuxt Coding Convention
            • Typescript Coding Convention
        • PHP Rule
          • Basic Coding Standard
          • Coding Style Guide
        • Mobile Team
          • Architecture
            • MVVM in iOS Swift
            • iOS Clean Architecture
          • Convention
            • Android
              • Kotlin Style Guide
              • Coding Convention
            • iOS
              • Swift Style Guide
    • PRIVACY POLICY AND CLIENT CONFIDENTIALITY
      • Confidentiality Policy
      • Access Production Policy
        • Rule
        • Flow
        • Problem Resolve and Penalty
Powered by GitBook
On this page
  • 1. Overview
  • 2. The main branches
  • 3. Supporting branches
  • 4. Reference documentation

Was this helpful?

  1. Home
  2. DEVELOPMENT POLICY
  3. Git Rule

Git Flow

PreviousGit Security ChecklistNextRules of Git commit message

Last updated 2 years ago

Was this helpful?

Created by Tung Nguyen (Frontend Specialist) from Technical Division at 2021 Feb

This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model) has become hugely popular in many software teams to the point where people have started treating it like a standard of sorts. (Vincent Driessen, author of Git-flow)

In gumi, we have been using this model for more than 6 years, and nowadays, it is a mandatory standard that project teams must follow when developing projects.

1. Overview

License: Creative Commons BY-SA

The overall flow of Git-flow:

  1. A develop branch is created from master

  2. A release branch is created from develop

  3. Feature branches are created from develop

  4. When a feature is complete it is merged into the develop branch

  5. When the release branch is done it is merged into develop and master

  6. If an issue in master is detected a hotfix branch is created from master

  7. Once the hotfix is complete it is merged to both develop and master

2. The main branches

There are two main branches with an infinite lifetime:

  • develop: for the development team to work on features/bugs fix/making releases

  • master: for production release, shipping product & deliver to the customer

3. Supporting branches

The different types of branches we may use are:

  • Feature branches: created only from develop branch, for the development team to work on features, bug fixes

  • Release branches: created only from develop branch, for testing and preparing to release group of finished features, bug fixes (if any) here should be merged back into develop & master branch

  • Hotfix branches: created only from the master branch, for fixing small bugs on production, bug fixes (if any) here should be merged back into develop branch

4. Reference documentation

Author: Vincent Driessen Original blog post:

Original documentation (Vincent Driessen):

http://nvie.com/posts/a-succesful-git-branching-model
http://nvie.com/posts/a-succesful-git-branching-model
[EN] Git for beginners (Mr. Dang Nguyen)