Feature Branch trong Git: nó là gì, cách tạo và làm việc với nhánh

Feature Branch trong Git là gì

Feature Branch (nhánh tính năng) là một nhánh tạm thời trong Git được tạo từ develop để phát triển một chức năng cụ thể. Không giống như các nhánh tồn tại lâu dài main và develop, nhánh feature tồn tại trong một thời gian giới hạn — từ vài giờ đến vài tuần.

Mục đích chính của feature branch là cách ly các thay đổi liên quan đến một tác vụ khỏi phần mã còn lại. Nhà phát triển có thể thử nghiệm, thực hiện nhiều commit và thậm chí phá mã trong nhánh riêng của mình mà không ảnh hưởng đến công việc của các thành viên khác trong nhóm.

Sau khi hoàn thành phát triển, nhánh feature được hợp nhất trở lại develop thông qua Pull Request với đánh giá mã bắt buộc. Sau khi hợp nhất, nhánh thường bị xóa để giữ kho chứa sạch sẽ.

Theo Vincent Driessen, 2010, mô hình Git Flow với các nhánh feature đã trở thành tiêu chuẩn ngành nhờ sự phân chia trách nhiệm rõ ràng giữa các loại nhánh khác nhau.

Quy trình làm việc với Feature Branch

Quy trình làm việc với feature branch bao gồm một chuỗi các bước mà nhà phát triển thực hiện cho mỗi tính năng mới. Quy trình này giảm thiểu xung đột hợp nhất và đảm bảo kiểm soát chất lượng mã.

1. Tạo nhánh từ commit mới nhất của develop. Nhà phát triển chuyển sang develop, cập nhật nó và tạo một nhánh feature mới.
2. Phát triển và commit trong nhánh feature. Nhà phát triển thực hiện thay đổi, commit với mô tả rõ ràng và định kỳ push nhánh lên kho chứa từ xa.
3. Đồng bộ hóa với develop — trong quá trình phát triển, nhánh chính có thể tiến lên phía trước. Nhà phát triển thực hiện rebase hoặc merge từ develop vào nhánh feature của mình.
4. Tạo Pull Request — khi tính năng đã sẵn sàng, nhà phát triển mở PR để đánh giá mã. Nhóm xem xét mã và để lại nhận xét.
5. Hợp nhất và xóa — sau khi PR được phê duyệt, nhánh được hợp nhất vào develop và xóa cả ở cục bộ lẫn từ xa.

Đồng bộ hóa định kỳ với develop là cực kỳ quan trọng. Nhánh feature tồn tại càng lâu mà không hợp nhất các thay đổi từ develop thì khả năng xảy ra xung đột khi hợp nhất cuối cùng càng cao.

Tần suất đồng bộ hóa nhánh feature

Quy tắc đặt tên nhánh feature

Đặt tên nhánh là một phần quan trọng của kỷ luật nhóm. Một tiêu chuẩn đặt tên thống nhất cho phép nhanh chóng xác định tác vụ nào đang được thực hiện và ai đang thực hiện nó.

• feature/tên — tiền tố feature/ được sử dụng trong Git Flow cổ điển. Ví dụ: feature/added-auth-module.
• feature/JIRA-123-mô tả — liên kết đến số tác vụ trong hệ thống theo dõi. Ví dụ: feature/PROJ-42-add-login.
• feature/loại/tên — định dạng mở rộng với chỉ dẫn loại tác vụ. Ví dụ: feature/feat/analytics-dashboard.

Sử dụng ID tác vụ từ JIRA, Trello hoặc hệ thống khác là một thực hành tốt nhất. Nó tự động liên kết mã với tác vụ và đơn giản hóa việc tìm kiếm nhánh qua git log.

Quy trình Pull Request

Pull Request (hoặc Merge Request trong GitLab) là một yêu cầu hợp nhất nhánh feature vào develop. PR không chỉ là một thao tác kỹ thuật, mà là một quy trình đánh giá mã nhóm giúp cải thiện chất lượng mã và lan truyền kiến thức trong nhóm.

Một PR tốt chứa tiêu đề với mô tả ngắn gọn về tác vụ, liên kết đến ticket và mô tả các thay đổi. Nhà phát triển nên chỉ ra những gì đã được thực hiện, những tệp nào đã được thay đổi và liệu có rủi ro tiềm ẩn cho các phần khác của dự án hay không.

Nhóm xem xét mã trong PR, để lại nhận xét, yêu cầu thay đổi (change requests) và phê duyệt hợp nhất (approve). Sau khi phê duyệt, merge hoặc squash merge được thực hiện.

Thời gian đánh giá PR trung bình trong phát triển di động là từ 4 đến 24 giờ. Thư viện Danger tự động hóa một phần kiểm tra, chạy linters và kiểm thử trực tiếp trong PR.

Khuyến nghị để tạo PR tốt

• Kích thước — không quá 300-400 dòng thay đổi. PR lớn khó đánh giá, chất lượng đánh giá giảm.
• Một PR — một tác vụ — tránh trộn lẫn các thay đổi không liên quan trong một yêu cầu.
• Ảnh chụp màn hình — đối với thay đổi giao diện, hãy đính kèm ảnh chụp trước và sau.
• Kiểm thử — đối với chức năng mới, hãy viết kiểm thử đơn vị và bao gồm chúng trong PR.

Chiến lược hợp nhất nhánh feature

Sau khi PR được phê duyệt, nhánh feature có thể được hợp nhất vào develop theo nhiều cách khác nhau. Việc lựa chọn chiến lược hợp nhất ảnh hưởng đến lịch sử commit và khả năng hoàn tác các thay đổi.

• Merge commit — tạo một commit hợp nhất, bảo toàn toàn bộ lịch sử commit của nhánh feature. Lịch sử vẫn đầy đủ, nhưng đồ thị rẽ nhánh trở nên phức tạp hơn.
• Squash merge — kết hợp tất cả các commit của nhánh feature thành một và thêm nó lên develop. Lịch sử trở nên sạch hơn, nhưng thông tin về các commit trung gian bị mất.
• Rebase and merge — viết lại các commit của nhánh feature lên commit mới nhất của develop và hợp nhất mà không cần commit bổ sung. Lịch sử vẫn tuyến tính.

Đối với các dự án di động có bản phát hành thường xuyên, squash merge thường được sử dụng nhất: nó cung cấp lịch sử sạch sẽ trong develop, trong khi chi tiết phát triển vẫn nằm trong mô tả PR và tác vụ tracker.

Lỗi điển hình khi làm việc với Feature Branch

Ngay cả những nhà phát triển giàu kinh nghiệm cũng mắc lỗi khi làm việc với các nhánh feature. Biết được các vấn đề điển hình giúp tránh mất thời gian và dữ liệu.

• Nhánh tồn tại quá lâu — nhánh feature tồn tại hơn 2-3 tuần mà không đồng bộ hóa với develop, dẫn đến xung đột hợp nhất lớn.
• Commit với mô tả không rõ ràng — thông báo như “fix” hoặc “update” không cho biết những gì đã được thay đổi và tại sao.
• Trộn lẫn tác vụ — trong cùng một nhánh feature, hai chức năng không liên quan được phát triển, khiến việc hoàn tác có chọn lọc trở nên bất khả thi.
• Thiếu đồng bộ hóa — nhà phát triển không thực hiện git fetch và không cập nhật develop, gây ra xung đột khi hợp nhất cuối cùng.

Cách tốt nhất để tránh những vấn đề này là thống nhất các quy tắc làm việc khi bắt đầu dự án và sử dụng các kiểm tra tự động trong đường ống CI/CD.

Ví dụ lệnh để làm việc với Feature Branch

Hãy xem xét một kịch bản thực tế: một nhà phát triển bắt đầu một tính năng xác thực mới trong ứng dụng di động. Anh ta tạo một nhánh feature, làm việc trên mã và hoàn thành tác vụ bằng Pull Request.

# Cập nhật develop và tạo nhánh feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# Làm việc trên tính năng: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# Đẩy nhánh feature lên máy chủ
git push origin feature/add-login-screen

# Đồng bộ hóa với develop (rebase)
git fetch origin develop
git rebase origin/develop

# Sau khi PR được phê duyệt: cập nhật develop cục bộ và xóa nhánh
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

Lệnh git branch -d xóa nhánh chỉ sau khi các thay đổi của nó đã được hợp nhất hoàn toàn. Nếu nhánh chưa được hợp nhất, Git sẽ đề xuất sử dụng git branch -D để xóa强制 — hãy sử dụng cờ này một cách thận trọng.

Tự động hóa kiểm tra trong nhánh feature

Đường ống CI/CD nên chạy cho mỗi nhánh feature trước khi tạo PR. Điều này cho phép phát hiện vấn đề ở giai đoạn sớm, trước khi mã đến được đánh giá của các nhà phát triển khác.

# GitHub Actions để kiểm tra nhánh feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

Đường ống kiểm tra rằng mã biên dịch được, kiểm thử đạt yêu cầu và phong cách mã tuân thủ các tiêu chuẩn của nhóm. Chỉ sau khi vượt qua tất cả các kiểm tra mới có thể tạo Pull Request.