Git Flow: Giải Pháp Tối Ưu Cho Quản Lý Dự Án

Commit

Đặt tả Commit là một định dạng chuẩn hóa cho các thông báo commit, giúp tạo ra lịch sử commit rõ ràng, dễ hiểu và tự động hóa các quy trình phát hành.

<type>[optional scope]: <description>

[optional body]

[optional footer]

type là các loại tùy biến thay đổi trong thực tế như: feat, fix, docs, style, refactor, perf, test, chore

Trong đó:

Feat: tạo 1 nhánh feature mới hoàn toàn và code trong nhánh đó.
Fix: áp dụng khi bạn thay đổi code trên một đoạn code hay một file code đã tồn tại.
Docs: Thay đổi trong file liên quan đến đuôi .md.
Style: Thay đổi lại nhưng không ảnh hưởng đến code (vd : formatting ).
Refactor: Là những thay đổi cấu trúc lại code và không thay đổi gì trong code hay thêm feature mới.(VD: cấu trúc lại 1 đoạn code có sẳn)
Perf: (performance) Thay đổi mã giúp cải thiện hiệu suất. (VD: giảm thời gian query)
Test: Thêm các tính năng kiểm thử trong code. (VD: thêm các Testcase liên quan đến hàm)
Chore: Là những thay đổi không liên quan đến source code hay test

Ví dụ:

docs: change cmd run code

feat(lang): added vietnamese language

feat: allow provided config object to extend other configs

Lưu Ý

Commit bắt buộc được có tiền tố với một loại, bao gồm một danh từ như feat, fix, v.v., theo sau là dấu hai chấm và description.
feat được sử dụng khi một commit thêm một tính năng mới vào ứng dụng hoặc thư viện của bạn.
Loại fix được sử dụng khi một commit đại diện cho việc sửa lỗi trong ứng dụng của bạn.
Scope có thể tùy biến thêm vào sao type tùy theo trường hợp cụ thể. - example : feat(lang)
Mô tả bắt buộc phải nằm sau type. Mô tả là một mô tả ngắn gọn về các thay đổi trong mã, ví dụ: fix: array parsing issue when multiple spaces were contained in string.
Mục footer có thể được phân biệt sau 1 dấu cách. Example: Fixes #13.
Các thay đổi quan trong ảnh hưởng đến code một cách trực tiếp thì cần có BREAKING CHANGE trong phần body. Example :

feat: thêm tính năng đăng nhập bằng email
	BREAKING CHANGE: trường 'username' đã được thay thế bởi 'email' trong cấu trúc dữ liệu người dùng.

Bắt buộc phải có 1 mô tả ở đằng sau -m

REAKING CHANGE.

Các loại khác ngoài feat và fix CÓ THỂ được sử dụng trong tin nhắn commit của bạn.

Issue

Với Issue khi xảy ra 1 vẫn đề xuất hiện cần giải quyết khi đó leader có thể giao việc cho các thành viên trong nhóm thông qua mục issue trên GitHub
Khi leader tạo sẽ Assignees ai là người làm nhiệm vụ đó, có thể thêm Labels vào để có thể hiểu thêm về nhiệm vụ cần làm, có thì thêm Projects vào và một branch cụ thể. Nếu thêm branch vào thì Issue đó sẽ được gắn trực tiếp đế branch đó Đây là ví dụ cụ thể hơn

Note: bạn có thể thêm tên issue, thêm người làm vấn đề đó ở mục Assignees và thêm description để mô tả rõ hơn

Pull Request

Khi được giao Issue bạn có và đã hoàn thành vẫn đề được giao đó bạn có thể tiến hành add, commit, và push lên nhánh của bạn dưới local
khi push lên xong bạn sẽ thấy nó sẽ xuất hiện 1 nhánh mới trên remote. Lúc ấy bạn cần đến Pull Request để có thể đưa code từ nhánh của bạn vào nhánh dev
Tương tự như Commit bạn phải gắn thêm tag (#numberIssue) để bên mục Issue của Github sẽ tự động cập nhật mới nhất commit mới nhất bạn vừa push lên , khi yêu cầu pull request bạn có thể thêm người review code bạn

Note : Đảm bảo bạn pull request lên nhánh dev đừng nhầm thành nhánh main.

Khi pull bạn có thể thêm người review code của bạn. Thường là leader của bạn

Khi hoàn thành Pull Request vào nhánh dev bạn có thể xóa remote nhanh đó để tránh rối khi có quá nhiều nhánh trên remote

Branch

Về việc tạo nhánh và phân quyền để giải quyết một là một điều vô cùng quan trọng trong GitFlow nó sẽ ảnh hưởng đến tốc độ hoàn thành dự án vì được chia cụ thể tránh xảy ra xung đột với nhau.

Main Branches

main (hoặc master)
- Chứa mã nguồn đã phát hành.
- Luôn ở trạng thái ổn định.
develop
- Là nhánh phát triển chính.
- Chứa mã nguồn kết hợp tất cả các nhánh tính năng và sửa lỗi đã hoàn thiện.

Supporting Branches

Feature Branches
- Được tạo trực tiếp từ nhánh develop.
- Được sử dụng để phát triển tính năng mới.
- Tên nhánh theo định dạng: feature/<tên-tính-năng>.
- Khi hoàn thành sẽ được hợp nhất vào nhánhnhánhdevelop.
Release Branches
- Được tạo từ develop khi chuẩn bị phát hành một phiên bản mới.
- Được sử dụng để hoàn thiện và kiểm tra phiên bản trước khi phát hành.
- Tên nhánh theo định dạng: release/<số-phát-hành>.
- Khi hoàn thành, hợp nhất vào cả main và develop.
Hotfix Branches
- Được tạo từ main để sửa lỗi khẩn cấp trong phiên bản đã phát hành.
- Được sử dụng để giải quyết các vấn đề nghiêm trọng mà không cần chờ phát hành tiếp theo.
- Tên nhánh theo định dạng: hotfix/<số-sửa-lỗi>.
- Khi hoàn thành, hợp nhất vào cả main và develop.
Bugfix Branches
- Được tạo từ develop để sửa lỗi phát sinh trong quá trình phát triển.
- Được sử dụng để giải quyết các vấn đề trong mã nguồn đang phát triển.
- Tên nhánh theo định dạng: bugfix/<tên-sửa-lỗi>.
- Khi hoàn thành, hợp nhất vào develop.