Git Flow Thực Chiến: Cách Quản Lý Nhánh Để Team Không “Húc Đầu” Vào Nhau

Git tutorial - IT technology blog
Git tutorial - IT technology blog

Làm việc nhóm mà không có quy trình thì chỉ có “toang”

Hồi mới đi làm, mình cứ ngỡ Git chỉ quanh quẩn add, commit, push. Mọi chuyện bắt đầu “vỡ trận” khi dự án phình to lên hơn 10 người, ai cũng hì hục sửa chung logic giỏ hàng rồi đẩy thẳng lên master. Kết quả là conflict dài như sớ. Code máy mình chạy ngon nhưng lên Production lại lăn đùng ra chết vì thiếu file. Git Flow ra đời để dẹp loạn cảnh này, tạo ra một ranh giới thép giữa code đang phát triển và code chuẩn bị đem đi kiếm tiền.

Quick Start: Triển khai Git Flow trong 5 phút

Đừng tốn thời gian đọc tài liệu dày cộp. Bạn hãy cài ngay công cụ git-flow. Đây thực chất là một bộ “phím tắt” (wrapper) giúp bạn thực hiện các quy trình phức tạp chỉ bằng vài từ khóa ngắn gọn, thay vì phải gõ 4-5 lệnh Git thuần.

1. Cài đặt nhanh

# macOS
brew install git-flow-avh

# Ubuntu/Debian
sudo apt-get install git-flow

# Windows
# Thường đã có sẵn trong Git Bash, nếu chưa hãy tải bản git-flow-avh.

2. Khởi tạo dự án

Mở terminal ngay tại thư mục gốc của dự án và gõ:

git flow init

Lúc này Git sẽ hỏi tên các nhánh (main, develop, feature…). Lời khuyên của mình: Cứ nhấn Enter chọn mặc định hết để anh em trong team và đối tác quốc tế dễ làm việc chung.

3. Bắt đầu làm tính năng mới

git flow feature start login-facebook

Lệnh này sẽ tự tách một nhánh mới từ develop và chuyển bạn sang đó luôn. Code xong xuôi, bạn chỉ cần gõ:

git flow feature finish login-facebook

Nó sẽ tự merge vào develop và dọn dẹp sạch nhánh vừa tạo. Cực kỳ rảnh tay!

Giải mã 5 loại nhánh “xương sống” trong Git Flow

Quy trình này chia repo thành 2 nhánh chính sống vĩnh viễn và 3 loại nhánh phụ sẽ bị xóa sau khi hoàn thành nhiệm vụ.

1. Nhánh chính (Main & Develop)

  • Main: Chứa code sạch nhất, đã qua kiểm thử gắt gao. Chỉ khi nào sẵn sàng release cho khách hàng mới đẩy code lên đây. Tuyệt đối không được gõ commit trực tiếp vào Main.
  • Develop: Đây là “phòng thí nghiệm”. Mọi tính năng mới đều đổ về đây để anh em test chéo trước khi đóng gói.

2. Nhánh phụ (Feature, Release, Hotfix)

  • Feature: Mỗi nhiệm vụ trên Jira nên là một nhánh riêng. Quy tắc bất biến: 1 task = 1 branch.
  • Release: Khi nhánh develop đã tích lũy đủ tính năng cho phiên bản 2.0, bạn tách nhánh này ra. Đây là giai đoạn chỉ dành cho việc fix bug UI nhỏ hoặc sửa lỗi chính tả, tuyệt đối không thêm tính năng mới vào đây.
  • Hotfix: Hãy tưởng tượng trang thanh toán bị lỗi 500 ngay đêm 30 Tết. Bạn sẽ tách nhánh Hotfix từ main, sửa xong rồi merge ngược lại cả maindevelop để dập lửa ngay lập tức.

Nâng cao: Phối hợp Git Flow với Pull Request (PR)

Trong thực tế tại các công ty lớn, chúng ta ít khi dùng lệnh finish ở máy cá nhân. Thay vào đó, mình thường kết hợp với quy trình Review Code trên GitHub/GitLab:

  1. Tạo nhánh bằng git flow feature start task-của-mình.
  2. Push nhánh lên server: git push origin feature/task-của-mình.
  3. Lên web mở Pull Request để đồng nghiệp vào “soi” code.
  4. Sau khi được duyệt (Approve), merge trực tiếp trên web rồi mới về máy cá nhân pull code mới về.

Mẹo sống còn: Tại sao phải dùng –no-ff?

Nếu bạn merge thủ công mà không có flag --no-ff (no fast-forward), Git sẽ gom các commit thành một đường thẳng tắp. Điều này khiến lịch sử repo trông cực kỳ rối mắt. Với --no-ff, Git tạo ra một nút thắt (merge commit) rõ ràng. Nhìn vào sơ đồ, bạn sẽ biết ngay tính năng đó bắt đầu từ đâu và kết thúc khi nào, cực kỳ dễ truy vết nếu sau này phát sinh lỗi.

Kinh nghiệm thực chiến cho Team Leader

Để Git Flow không trở thành gánh nặng, hãy áp dụng 3 quy tắc sau cho team của bạn:

1. Đặt tên nhánh theo ID ticket

Đừng đặt tên kiểu feature/fix-bug-gap. Hãy dùng format: loại-nhánh/mã-ticket-mô-tả. Ví dụ: feature/PROJ-123-api-login hoặc hotfix/PROJ-456-fix-crash-ios.

2. Tự động hóa Pipeline (CI/CD)

Hãy thiết lập để hễ có code push lên develop là hệ thống tự động deploy lên môi trường Staging cho Tester kiểm tra. Khi code merge vào main và được gắn Tag v1.1, hệ thống sẽ tự động đẩy lên Production. Việc này giúp giảm 90% lỗi ngớ ngẩn do thao tác tay.

3. Dọn rác định kỳ

Nhiều bạn có thói quen để hàng chục nhánh cũ bám rêu trên máy. Cứ cuối mỗi Sprint (thường là 2 tuần), hãy dành 5 phút để xóa những nhánh đã merge. Máy tính chạy nhanh hơn và bạn cũng đỡ hoa mắt khi tìm code.

Lời kết

Mình từng rơi vào cảnh sếp đòi fix gấp lỗi mất dữ liệu trên Production trong khi đang làm dở một tính năng khổng lồ chưa xong. Nhờ tuân thủ Git Flow, mình chỉ mất 2 phút để stash code đang làm, nhảy sang main tạo nhánh hotfix, sửa lỗi và deploy trong vòng đúng 15 phút. Mọi thứ diễn ra cực kỳ trơn tru.

Nếu bạn làm dự án một mình, Git Flow có vẻ hơi rườm rà. Nhưng chỉ cần team từ 2 người trở lên, việc áp dụng quy trình này ngay từ ngày đầu sẽ giúp bạn tiết kiệm hàng tá giờ đồng hồ ngồi gỡ conflict và cãi nhau xem ai đã ghi đè code của ai.

Đừng ngại thử. Hãy lập một repo nháp, tập gõ các lệnh init, start, finish vài lần cho quen tay trước khi áp dụng vào dự án thực tế của công ty nhé!

Share: