Khi bạn làm việc trong dự án, bất kể dù là dự án to, nhỏ, có một mình bạn hay cùng các đồng nghiệp khác thì việc thống nhất với nhau trong công việc là một điều cần thiết.

Việc này không những giúp quản lý của bạn, đồng nghiệp của bạn mà nó còn giúp đỡ bạn rất nhiều kể cả khi bạn làm dự án đó một mình.

Các nhánh chính

Một dự án Product hoặc một dự án lớn liên tục cập nhật, thay đổi tính năng thì thường luôn chứa các branch sau tương ứng với các môi trường để phát triển và triển khai:

Development (develop)

  • Tất cả các tính năng mới và bản sửa lỗi sẽ được đưa đến Development. Việc giải quyết xung đột mã dành cho nhà phát triển nên được thực hiện sớm nhất tại đây.

QA/Test (test)

  • Chứa tất cả các mã đã sẵn sàng để QA test.

Staging (staging)

  • Nó chứa các tính năng đã được thử nghiệm mà các bên liên quan muốn có sẵn cho bản demo hoặc đề xuất trước khi đưa vào Production. Các quyết định được đưa ra ở đây nếu một tính năng cuối cùng sẽ được đưa vào Production.

Production (master)

  • Nơi code được triển khai cho người dùng sử dụng

Ngoại trừ các hotfix, các branch thường theo duy nhất một chiều bắt đầu từ development > test > staging > production.

Các nhánh tạm thời

Như tên của nó, đây là những nhánh dùng một lần có thể được tạo và xóa theo nhu cầu của developer hoặc deployer.

Bạn nên sử dụng tất cả các chữ cái viết hoa thường và dấu gạch ngang (-) để phân tách các từ trừ khi đó là tên hoặc ID mục cụ thể. Dấu gạch dưới (_) có thể được sử dụng để phân tách ID và mô tả.

Feature

  • Bất kỳ thay đổi nào cho một mô-đun hoặc trường hợp sử dụng mới phải được thực hiện trên một nhánh tính năng. Nhánh này được tạo dựa trên nhánh phát triển hiện tại. Khi tất cả các thay đổi đã hoàn tất, một Pull Request/Merge Request là cần thiết để đưa tất cả những thay đổi này vào development.

Ví dụ:

  • feature/order_api-create-order
  • feature/JIRA-999
  • feature/JIRA-999_order_api-create-order

Bug Fix

  • Nếu các thay đổi được thực hiện từ Feature bị từ chối, sai sau khi Test, Staging mọi bản sửa lỗi cần thiết sau đó sẽ được thực hiện trên nhánh Bug Fix.

Ví dụ:

  • bugfix/order_api-create-order_set-price-decimal
  • bugfix/JIRA-1000
  • bugfix/JIRA-1000_set-price-decimal

Hot Fix

  • Nếu có nhu cầu thực hiện một bản vá tạm thời, áp dụng một khuôn khổ quan trọng hoặc thay đổi cấu hình cần được xử lý ngay lập tức trên Production nó sẽ được tạo dưới dạng Hot Fix. Nó không tuân theo sự tích hợp theo trình tự và có thể được hợp nhất trực tiếp vào Production, sau đó mới vào Development và trình tự sau.

Ví dụ:

  • hotfix/order_api-create-order_hidden-token
  • hotfix/hidden-token

Refactor

  • Bất kỳ tính năng hoặc ý tưởng mới, nâng cấp thuật toán, tái cấu trúc ... không phải lỗi phát sinh trong quá trình Test , Staging và không thay đổi input/ouput.
  • Nó là một bản nâng cấp của đoạn code của bạn khiến nó tốt hơn.

Ví dụ:

  • refactor/order_api-create-order_one-product-loop
  • refactor/order_api-create-order_shorten-insert-command

Merging

  • Một nhánh tạm thời để giải quyết conflict, thường là giữa phát triển mới nhất và một tính năng hoặc nhánh Hot Fix. Điều này cũng có thể được sử dụng nếu hai nhánh của một tính năng đang được nhiều nhà phát triển làm việc cần được hợp nhất, xác minh và hoàn thiện.

Ví dụ:

  • merge/develop-order_api-create-order

Thường thì quy tắc đặt tên branch của tôi sẽ là:

<Nhánh tạm thời>/<Cụm tính năng cha>_<Tính năng con(Tên task JIRA hoặc nội dung chính của task đó>_<Tên lỗi(Bug Fix, Hot Fix)/Nội dung cần cải thiện(Refactor)>

Ví dụ:

Tôi cần phát triển tính năng như sau:

Vì đây là một story nên, tôi sẽ chia nhỏ thành từng task và sub task bên trong, đại khái là sẽ bao gồm các task

  • Nhận biết thói quen của khách hàng
  • Gợi ý mua hàng theo thói quen của khách hàng

Task: "Nhận biết thói quen của khách hàng"

Từ task đó, tôi sẽ tiếp tục chia nhỏ ra thành các sub task, trong đống sub task đó sẽ có sub task là mua hàng

Vậy tôi sẽ đặt tên đại khái là:

feature/promotion_buying-habbit_api-create-purchase

Tổng kết

Bất kỳ tổ chức nào cũng có thể đưa ra quy ước của riêng. Điều này áp dụng cho nhu cầu của dự án của tôi cũng như team và có thể có một cách tiếp cận tốt hơn có thể cải thiện những điều này.

Tham khảo:

https://dev.to/couchcamote/git-branching-name-convention-cch