Bắt đầu học

Feature Branch Workflow

Xem thử

Vấn đề cần giải quyết

Trong Centralized Workflow, một người commit dở dang lên main và cả đội kéo về một bản không chạy. Bạn muốn main luôn ổn định để có thể phát hành bất cứ lúc nào, trong khi nhiều người vẫn làm song song. Feature Branch Workflow giải quyết bằng một quy tắc đơn giản.

Sau bài này, bạn có thể

  • Phát biểu quy tắc cốt lõi: mọi tính năng làm trên nhánh riêng, không commit trực tiếp lên main.
  • Thực hiện vòng đời một tính năng từ main mới nhất tới khi dọn nhánh.
  • Giải thích vì sao workflow này phù hợp với CI/CD.

Tiên quyết: bài Pull Request và git merge.

Quy tắc cốt lõi

Mọi tính năng được phát triển trên một nhánh riêng, không bao giờ commit trực tiếp lên main. Nhờ đó main luôn ổn định và mọi thay đổi đi qua Pull Request để review.

Thử và quan sát

Hãy dự đoán: hai người làm hai tính năng cùng lúc. Sau khi tính năng thứ nhất được merge, tính năng thứ hai nên làm gì trước khi merge để main vẫn ổn định? Chạy mô phỏng, rồi thử biến thể commit thẳng lên main.

Đang tải Animation…

Bảng bước (bản đọc tĩnh của mô phỏng)

BướcLệnhĐiều xảy ra
1git switch -c feature/payment && git commit -m "Thêm thanh toán"An làm tính năng thanh toán trên nhánh riêng, không đụng main.
2git switch -c feature/search main && git commit -m "Thêm tìm kiếm"Bình làm tính năng tìm kiếm song song, cũng từ main. Hai nhánh độc lập nhau.
3(PR #1 được duyệt và merge)Pull Request của An qua review và CI xanh rồi mới merge. main nhận một commit hợp nhất M1.
4git merge mainBình cập nhật nhánh của mình với main mới nhất trước khi merge, để phát hiện xung đột ngay trên nhánh chứ không trên main.
5(PR #2 được duyệt và merge)Tính năng thứ hai vào main sau khi CI xanh. main chỉ nhận code đã qua review nên luôn ổn định.

Biến thể: Commit thẳng lên main

BướcLệnhĐiều xảy ra
1git commit -m "Thử nhanh"Một người commit thẳng lên main để cho nhanh, không qua review.
2(CI) buildCI báo lỗi, nhưng main đã chứa commit hỏng và đồng đội đã kéo nó về.
3git revert HEAD --no-editPhải dọn dẹp bằng một commit đảo ngược. Với Feature Branch, commit này đã bị chặn từ Pull Request.

Giải đáp. Cập nhật nhánh của mình với main mới nhất (git merge main hoặc git rebase main) và chạy lại kiểm thử, để xung đột nếu có được phát hiện trên nhánh thay vì trên main. Hình dạng lịch sử: main chỉ nhận các commit hợp nhất M1, M2 sau khi Pull Request được duyệt, không có commit làm dở nào nằm trên main. Ở biến thể, commit thẳng lên main bỏ qua review và CI nên lỗi lan tới cả đội.

Quy trình

bash
git switch main
git pull
git switch -c feature/thanh-toan
git add .
git commit -m "Thêm cổng thanh toán"
git push -u origin feature/thanh-toan

Lần lượt: bắt đầu từ main mới nhất, tạo nhánh tính năng, làm việc và commit nhỏ thường xuyên, rồi đẩy nhánh và mở Pull Request. Hãy nhìn vòng đời đầy đủ ở dạng một dòng chảy.

Đang tải sơ đồ…

Cách đọc hình. Mỗi tính năng đi trọn một vòng: cập nhật main, tạo nhánh, commit nhỏ, push và mở Pull Request. Điểm rẽ nhánh là review và CI: chưa đạt thì quay lại commit thêm; đạt thì merge, cập nhật main rồi xóa nhánh. Vòng sau luôn bắt đầu từ main mới nhất.

Sau khi Pull Request được duyệt

bash
git switch main
git pull
git branch -d feature/thanh-toan

Vì sao phổ biến

  • main không bao giờ chứa code hỏng, lý tưởng cho CI/CD.
  • Mỗi tính năng có không gian riêng để thảo luận qua Pull Request.
  • Nhiều người làm song song mà ít giẫm chân nhau.

Đây là workflow nền tảng cho phần lớn đội phần mềm hiện đại, và là bước đệm để tiến tới Gitflow hoặc Forking khi cần.

Hiểu lầm thường gặp

  • "Nhánh tính năng sống càng lâu càng tốt." Nhánh dài hạn lệch xa main và xung đột nhiều; nên ngắn hạn và merge sớm.
  • "Chỉ cần review, không cần CI." CI là cổng chất lượng tự động; review và CI bổ sung cho nhau.
  • "Merge xong nhánh tự biến mất." Bạn nên xóa nhánh đã xong để kho gọn.

Tự kiểm tra

  1. Quy tắc cốt lõi của Feature Branch Workflow là gì?
  2. Vì sao cập nhật nhánh với main trước khi merge?
  3. Vòng đời của một tính năng bắt đầu bằng bước nào?

Đáp án gợi ý. (1) Mọi tính năng trên nhánh riêng, không commit thẳng lên main. (2) Để phát hiện xung đột trên nhánh chứ không trên main. (3) Cập nhật main mới nhất (git switch main, git pull).

Điều cần nhớ

  • Nhánh riêng cho mỗi tính năng, qua Pull Request, main luôn ổn định.
  • Vòng đời: cập nhật main, tạo nhánh, commit nhỏ, PR, review và CI, merge, dọn nhánh.
  • Nhánh ngắn hạn, merge sớm.
  • Bài sau: Gitflow Workflow.

Nguồn tham khảo

Tài liệu Atlassian Git Tutorial, Feature Branch Workflow; Pro Git, chương 3.4 "Branching Workflows" (git-scm.com/book).

Nội dung bài học