Release Branch di Git — apa itu, tujuan dan proses kerja

Apa itu Release Branch di Git

Release Branch (cabang rilis) — adalah cabang sementara di Git Flow, dibuat dari develop ketika tim memutuskan bahwa kumpulan fitur saat ini siap untuk dirilis. Cabang ini ada selama persiapan akhir rilis berlangsung — dari beberapa jam hingga beberapa hari.

Tujuan utama cabang release — membekukan kumpulan fitur tertentu untuk rilis, tanpa menghentikan pengembangan versi berikutnya. Sementara cabang release dipersiapkan untuk dirilis, pengembang lain dapat terus menggabungkan cabang feature ke develop untuk rilis berikutnya.

Di cabang release tidak dibuat fitur baru — hanya perbaikan bug, pembaruan versi aplikasi, lokalisasi, dan dokumentasi. Setelah semua pekerjaan selesai, cabang release digabungkan ke main (ditandai sebagai rilis) dan kembali ke develop (agar perbaikan bug masuk ke versi mendatang).

Menurut Atlassian, 2024, cabang release sangat penting untuk proyek dengan siklus rilis reguler — mereka memastikan prediktabilitas dan stabilitas proses rilis.

Siklus hidup cabang release

Siklus hidup cabang release dari pembuatan hingga penghapusan mencakup beberapa tahap. Memahami setiap tahap membantu tim menyinkronkan tindakan dan menghindari kesalahan.

1. Pembuatan — dari commit terakhir develop dibuat cabang dengan nama release/2.5.0. develop terus menerima cabang feature untuk versi berikutnya.
2. Persiapan — di cabang release, versi aplikasi diperbarui di build.gradle, Info.plist, dan file konfigurasi lainnya.
3. Perbaikan bug — bug kritis yang ditemukan selama pengujian akhir diperbaiki. Hanya bug — tanpa fitur baru.
4. Pengujian akhir — tim QA melakukan pengujian regresi pada cabang release. Bug baru dikirim untuk diperbaiki ke cabang yang sama.
5. Penggabungan ke main — cabang release digabungkan ke main dengan flag --no-ff. Tag rilis dibuat: v2.5.0.
6. Penggabungan ke develop — cabang release digabungkan kembali ke develop, agar perbaikan bug dari rilis masuk ke pengembangan saat ini.
7. Penghapusan — cabang release dihapus secara lokal dan jarak jauh, karena tugasnya telah selesai.

Poin 6 — penggabungan kembali ke develop — sering dilupakan, tetapi sangat penting. Tanpanya, perbaikan bug yang dilakukan di release tidak akan masuk ke develop, dan pada rilis berikutnya, kesalahan yang sama dapat muncul kembali.

Durasi tipikal tahapan cabang release

Umur cabang release tergantung pada kompleksitas rilis dan kualitas kode di develop. Rata-rata, persiapan memakan waktu 2 hingga 5 hari kerja untuk aplikasi mobile berukuran sedang.

Apa yang dilakukan di cabang release

Di cabang release, serangkaian tugas yang sangat terbatas dilakukan. Setiap penyimpangan dari daftar ini melanggar model Git Flow dan menciptakan risiko terhadap stabilitas rilis.

Aturan larangan fitur baru — yang terpenting di cabang release. Jika fitur tidak sempat untuk rilis, ia menunggu siklus berikutnya. Upaya mendorong fitur yang belum selesai ke cabang release — penyebab utama keterlambatan tenggat dan bug di produksi.

Memperbarui versi di proyek mobile

Di cabang release, nomor versi aplikasi wajib diperbarui. Untuk Android, ini adalah bidang versionCode dan versionName di build.gradle, untuk iOS — CFBundleShortVersionString di Info.plist.

// build.gradle (app-level) — pembaruan versi di cabang release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Untuk iOS — memperbarui Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Perbedaan antara release dan hotfix

Pengembang pemula sering bingung membedakan cabang release dan hotfix, meskipun tujuannya sangat berbeda. Kesalahan dalam memilih jenis cabang dapat menyebabkan keterlambatan perbaikan kritis atau gangguan proses rilis.

• Sumber — release dibuat dari develop, hotfix — dari main. Ini adalah perbedaan utama yang menentukan segalanya.
• Urgensi — release direncanakan: tim sendiri yang memutuskan kapan memulai persiapan. Hotfix bersifat darurat: masalah di produksi memerlukan perbaikan segera.
• Konten — release dapat mencakup beberapa perbaikan dan pembaruan versi. Hotfix hanya berisi satu perbaikan kritis.
• Penggabungan — release digabungkan ke main dan develop. Hotfix juga digabungkan ke main dan develop, tetapi dengan prioritas.
• Masa hidup — release hidup 1 hingga 7 hari. Hotfix hidup 30 menit hingga 1 hari.

Jika bug ditemukan dalam proses persiapan rilis (di cabang release) — ini adalah perbaikan bug biasa. Jika bug ditemukan di produksi (di main) — ini adalah hotfix, dan dibuat dari main, meskipun cabang release sudah ada.

Aturan penamaan cabang release

Standar seragam penamaan cabang release menyederhanakan navigasi repositori dan memungkinkan sistem CI/CD secara otomatis menentukan bahwa cabang tersebut terkait dengan proses rilis.

• release/X.Y.Z — format standar Git Flow, di mana X.Y.Z adalah versi rilis. Contoh: release/2.5.0.
• release/nama — format alternatif dengan nama kode rilis. Contoh: release/merlin.
• release/tanggal — format dengan tanggal rilis. Jarang digunakan karena versi lebih penting daripada tanggal. Contoh: release/2024-12-01.

Format release/X.Y.Z — lebih disukai, karena secara eksplisit menghubungkan cabang dengan nomor versi yang akan diberikan pada rilis. Ini menyederhanakan pencarian dan pemrosesan otomatis oleh skrip CI/CD.

Strategi penggabungan kembali ke develop

Penggabungan kembali (merge back) cabang release ke develop — salah satu operasi terpenting dan sering terlewatkan. Tanpanya, semua perbaikan bug yang dilakukan di release hanya akan tetap di versi rilis dan tidak masuk ke siklus rilis berikutnya.

Proses penggabungan kembali dilakukan setelah cabang release sudah digabungkan ke main. Pertama, release digabungkan ke develop, kemudian — dihapus. Ini memastikan bahwa develop berisi semua perbaikan yang dilakukan selama persiapan rilis.

Setelah penggabungan kembali, konflik mungkin terjadi — terutama jika di develop sudah muncul cabang feature baru yang mengubah file yang sama. Pengembang yang bertanggung jawab atas rilis menyelesaikan konflik ini dan mendorong develop ke server.

Beberapa tim menggunakan rebase alih-alih merge untuk penggabungan kembali, agar riwayat tetap linier. Namun, merge lebih aman untuk develop karena tidak menulis ulang riwayat commit yang mungkin sudah digunakan oleh pengembang lain.

Contoh perintah untuk bekerja dengan release

Mari kita lihat siklus kerja lengkap dengan cabang release: dari pembuatan hingga penghapusan setelah rilis sukses aplikasi mobile versi 2.5.0.

# 1. Membuat cabang release dari develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Pembaruan versi dan perbaikan bug
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Memperbaiki bug (hanya bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Mengirim cabang release ke server
git push origin release/2.5.0

# 5. Menggabungkan release ke 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. Penggabungan kembali ke develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Menghapus cabang release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Perintah 5 dan 6 — penggabungan ganda — sangat penting. Pertama, main menerima kode rilis dan tag, kemudian develop disinkronkan dengan perbaikan bug dari release. Jika langkah 6 dilewati, perbaikan dari rilis tidak masuk ke siklus pengembangan berikutnya.

Otomatisasi proses rilis

Untuk proyek mobile dengan rilis reguler, proses pembuatan cabang release dan pembaruan versi dapat diotomatisasi melalui skrip CI/CD. GitHub Actions memungkinkan pembuatan workflow yang, dengan menekan tombol, membuat cabang release dengan pembaruan versi otomatis.

Untuk proyek mobile dengan rilis reguler, proses pembuatan cabang release dan pembaruan versi dapat diotomatisasi melalui skrip CI/CD. GitHub Actions memungkinkan pembuatan workflow yang, dengan menekan tombol, membuat cabang release dengan pembaruan versi otomatis.

# GitHub Actions — otomatisasi pembuatan cabang 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 }}