Release Branch trong Git — nó là gì, mục đích và quy trình làm việc

Release Branch trong Git là gì

Release Branch (nhánh phát hành) là một nhánh tạm thời trong Git Flow, được tạo từ develop khi nhóm quyết định rằng tập hợp tính năng hiện tại đã sẵn sàng để phát hành. Nó tồn tại chính xác trong khoảng thời gian chuẩn bị phát hành cuối cùng — từ vài giờ đến vài ngày.

Mục đích chính của nhánh release là cố định một tập hợp tính năng cụ thể cho bản phát hành mà không dừng phát triển các phiên bản tiếp theo. Trong khi nhánh release đang được chuẩn bị để triển khai, các nhà phát triển khác có thể tiếp tục hợp nhất các nhánh tính năng vào develop cho bản phát hành tiếp theo.

Không có tính năng mới nào được tạo trong nhánh release — chỉ sửa lỗi, cập nhật phiên bản ứng dụng, bản địa hóa và tài liệu. Sau khi hoàn tất tất cả công việc, nhánh release được hợp nhất vào main (đánh dấu là bản phát hành) và trở lại develop (để các bản sửa lỗi đến được các phiên bản tương lai).

Theo Atlassian, 2024, các nhánh release cực kỳ quan trọng đối với các dự án có chu kỳ phát hành thường xuyên — chúng đảm bảo tính dự đoán và ổn định của quy trình phát hành.

Vòng đời của nhánh release

Vòng đời của nhánh release từ khi tạo đến khi xóa bao gồm nhiều giai đoạn. Hiểu từng giai đoạn giúp nhóm đồng bộ hóa hành động và tránh sai lầm.

1. Tạo — từ commit cuối cùng của develop, một nhánh có tên release/2.5.0 được tạo. develop tiếp tục chấp nhận các nhánh tính năng cho phiên bản tiếp theo.
2. Chuẩn bị — trong nhánh release, phiên bản ứng dụng được cập nhật trong build.gradle, Info.plist và các tệp cấu hình khác.
3. Sửa lỗi — các lỗi nghiêm trọng được tìm thấy trong quá trình kiểm thử cuối cùng được sửa. Chỉ lỗi — không có tính năng mới.
4. Kiểm thử cuối cùng — nhóm QA thực hiện kiểm thử hồi quy trên nhánh release. Các lỗi mới được gửi để sửa trong cùng nhánh.
5. Hợp nhất vào main — nhánh release được hợp nhất vào main với cờ --no-ff. Thẻ phát hành được tạo: v2.5.0.
6. Hợp nhất vào develop — nhánh release được hợp nhất trở lại develop để các bản sửa lỗi từ bản phát hành đến được quá trình phát triển hiện tại.
7. Xóa — nhánh release bị xóa cục bộ và từ xa vì nhiệm vụ của nó đã hoàn thành.

Bước 6 — hợp nhất ngược vào develop — thường bị quên nhưng cực kỳ quan trọng. Nếu không có nó, các bản sửa lỗi được thực hiện trong nhánh release sẽ không đến được develop và các lỗi tương tự có thể xuất hiện lại trong bản phát hành tiếp theo.

Thời gian điển hình của các giai đoạn nhánh release

Thời gian tồn tại của nhánh release phụ thuộc vào độ phức tạp của bản phát hành và chất lượng mã trong develop. Trung bình, việc chuẩn bị mất từ 2 đến 5 ngày làm việc đối với một ứng dụng di động cỡ trung bình.

Những việc làm trong nhánh release

Trong nhánh release, một tập hợp nhiệm vụ giới hạn nghiêm ngặt được thực hiện. Bất kỳ sai lệch nào khỏi danh sách này đều vi phạm mô hình Git Flow và tạo rủi ro cho sự ổn định của bản phát hành.

Quy tắc cấm tính năng mới là quan trọng nhất trong nhánh release. Nếu một tính năng không kịp cho bản phát hành, nó chờ chu kỳ tiếp theo. Cố gắng đẩy một tính năng chưa hoàn thành vào nhánh release là nguyên nhân chính dẫn đến trễ hạn và lỗi trong sản phẩm.

Cập nhật phiên bản trong dự án di động

Trong nhánh release, số phiên bản ứng dụng bắt buộc phải được cập nhật. Đối với Android, đó là các trường versionCode và versionName trong build.gradle; đối với iOS — CFBundleShortVersionString trong Info.plist.

// build.gradle (cấp ứng dụng) — cập nhật phiên bản trong nhánh release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Đối với iOS — cập nhật Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Sự khác biệt giữa release và hotfix

Các nhà phát triển mới thường nhầm lẫn giữa nhánh release và hotfix, mặc dù mục đích của chúng hoàn toàn khác nhau. Chọn sai loại nhánh có thể làm chậm bản sửa lỗi quan trọng hoặc làm gián đoạn quy trình phát hành.

• Nguồn gốc — release được tạo từ develop, hotfix từ main. Đây là sự khác biệt chính quyết định mọi thứ khác.
• Tính khẩn cấp — release có kế hoạch: nhóm tự quyết định khi nào bắt đầu chuẩn bị. Hotfix khẩn cấp: vấn đề trong sản phẩm yêu cầu sửa ngay lập tức.
• Nội dung — release có thể bao gồm nhiều bản sửa lỗi và cập nhật phiên bản. Hotfix chỉ chứa một bản sửa lỗi quan trọng.
• Hợp nhất — release được hợp nhất vào main và develop. Hotfix cũng được hợp nhất vào main và develop, nhưng ưu tiên hơn.
• Thời gian tồn tại — release sống từ 1 đến 7 ngày. Hotfix sống từ 30 phút đến 1 ngày.

Nếu lỗi được tìm thấy trong quá trình chuẩn bị phát hành (trong nhánh release) — đó là sửa lỗi thông thường. Nếu lỗi được tìm thấy trong sản phẩm (trên main) — đó là hotfix và nó được tạo từ main, ngay cả khi nhánh release đã tồn tại.

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

Một tiêu chuẩn thống nhất về đặt tên nhánh release giúp đơn giản hóa việc điều hướng kho lưu trữ và cho phép hệ thống CI/CD tự động phát hiện nhánh thuộc quy trình phát hành.

• release/X.Y.Z — định dạng Git Flow chuẩn, trong đó X.Y.Z là phiên bản phát hành. Ví dụ: release/2.5.0.
• release/tên — định dạng thay thế với tên mã phát hành. Ví dụ: release/merlin.
• release/ngày — định dạng với ngày phát hành. Ít được sử dụng vì phiên bản quan trọng hơn ngày. Ví dụ: release/2024-12-01.

Định dạng release/X.Y.Z được ưa chuộng vì nó liên kết rõ ràng nhánh với số phiên bản sẽ được gán cho bản phát hành. Điều này đơn giản hóa việc tìm kiếm và xử lý tự động bằng các tập lệnh CI/CD.

Chiến lược hợp nhất ngược vào develop

Hợp nhất ngược (merge back) của nhánh release vào develop là một trong những thao tác quan trọng nhất và đồng thời thường bị bỏ qua nhất. Nếu không có nó, tất cả các bản sửa lỗi được thực hiện trong nhánh release chỉ còn lại trong phiên bản phát hành và không đến được chu kỳ phát hành tiếp theo.

Quá trình hợp nhất ngược được thực hiện sau khi nhánh release đã được hợp nhất vào main. Đầu tiên, release được hợp nhất vào develop, sau đó bị xóa. Điều này đảm bảo rằng develop chứa tất cả các bản sửa lỗi được thực hiện trong quá trình chuẩn bị phát hành.

Sau khi hợp nhất ngược, xung đột có thể xảy ra — đặc biệt nếu các nhánh tính năng mới đã xuất hiện trong develop và đã sửa đổi cùng các tệp. Nhà phát triển chịu trách nhiệm về bản phát hành giải quyết các xung đột này và đẩy develop lên máy chủ.

Một số nhóm sử dụng rebase thay vì merge để hợp nhất ngược nhằm giữ lịch sử tuyến tính. Tuy nhiên, merge an toàn hơn cho develop vì nó không ghi lại lịch sử commit mà các nhà phát triển khác có thể đã sử dụng.

Ví dụ lệnh làm việc với release

Hãy xem xét toàn bộ chu kỳ làm việc với nhánh release: từ tạo đến xóa sau khi phát hành thành công ứng dụng di động phiên bản 2.5.0.

# 1. Tạo nhánh release từ develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Cập nhật phiên bản và sửa lỗi
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Sửa lỗi (chỉ bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Đẩy nhánh release lên máy chủ
git push origin release/2.5.0

# 5. Hợp nhất release vào main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Hợp nhất ngược vào develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Xóa nhánh release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Lệnh 5 và 6 — hợp nhất kép — cực kỳ quan trọng. Đầu tiên, main nhận mã phát hành và thẻ, sau đó develop đồng bộ hóa với các bản sửa lỗi từ release. Nếu bỏ qua bước 6, các bản sửa lỗi từ bản phát hành sẽ không đến được chu kỳ phát triển tiếp theo.

Tự động hóa quy trình phát hành

Đối với các dự án di động có bản phát hành thường xuyên, quy trình tạo nhánh release và cập nhật phiên bản có thể được tự động hóa thông qua các tập lệnh CI/CD. GitHub Actions cho phép tạo một quy trình làm việc mà khi nhấn nút sẽ tạo nhánh release với cập nhật phiên bản tự động.

Đối với các dự án di động có bản phát hành thường xuyên, quy trình tạo nhánh release và cập nhật phiên bản có thể được tự động hóa thông qua các tập lệnh CI/CD. GitHub Actions cho phép tạo một quy trình làm việc mà khi nhấn nút sẽ tạo nhánh release với cập nhật phiên bản tự động.

# GitHub Actions — tự động hóa tạo nhánh release
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}