💡
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
  • Branch type (Loại nhánh)
  • Formatting
  • Naming - Đặt tên nhánh
  • Default Branches
  • Working Branches
  • Releases Branches
  • References

Was this helpful?

  1. Home
  2. DEVELOPMENT POLICY
  3. Git Rule

Branch Management

PreviousGit RuleNextCommitting Code

Last updated 3 years ago

Was this helpful?

(branching model) được sử dụng tại gumi trong hơn 6 năm qua. Và hiện tại, đây là quy tắc chung bắt buộc phải sử dụng khi phát triển một dự án mới từ khi bắt đầu.

Branch type (Loại nhánh)

  • feature: Dùng để tạo các nhánh chức năng mới

  • bug: Dùng để tạo các nhánh liên quan đến bug (lỗi)

  • release: Dùng để tạo nhánh liên quan đến việc release phiên bản

  • hotfix: Dùng trong trường hơp tạo nhánh cho các lỗi xãy ra trên production

Formatting

  • Sử dụng lowercase và kebab-case cho việc đặt tên nhánh

# Bad
feature/user_login_page
Bug/userResetPassword

# Good
feature/user-login-page
bug/user-reset-password

  • Sử dụng slash / để chia branch type (Loại nhánh) và branch name (tên nhánh)

# Bad
feature-user-login-page
bug_user-reset-password

# Good
feature/user-login-page
bug/user-reset-password

Naming - Đặt tên nhánh

  • Prefix tên nhánh với Backlog Item ID 

# Bad
sdg-531/feature/list-job-positions

# Good
feature/sdg-531-list-job-positions

Default Branches

Có hai nhánh chính với thời gian tồn tại là vô hạn (infinite lifetime)

  • develop: cho team phát triển làm việc trên các features/bugs fix/making releases

  • master: dùng cho việc release trên môi trường production, chuyển giao sản phẩm cho khách hàng

Working Branches

Dựa trên git-flow cũng như việc phân loại các nhánh đã quy định ở trên

  • Feature / Bug branches: phải được tạo từ nhánh develop, sử dụng để làm việc với features, bug fixes

Releases Branches

  • Release branches: phải được tạo từ nhánh develop, sử dụng để testing và chuẩn bị cho việc release các nhóm chức năng đã hoàn thiện, hoặc bug fixes (nếu có) và tất cả phải được merged trở lại vào nhánh develop & master

  • Hotfix branches: được tạo ra từ nhánh master, cho việc sửa các lỗi nhỏ trên production, và tất cả phải được merged trở lại vào nhánh develop và master

# Bad
release/1.0
release/v1.0

# Good
release/1.0.0

References

  • Như đã đề cập từ đầu, cấu trúc chia nhánh được dựa trên git-flow của tác giả Vincent Driessen, License: Creative Commons BY-SA

Tên của nhánh release phải chứa các chữ số ngữ nghĩa theo

Original Post:

git-flow
Sematic Versioning
http://nvie.com/posts/a-succesful-git-branching-model