Develop Branch di Git — apa itu, tujuan dan prinsip kerja

Apa itu Develop Branch di Git

Develop Branch (cabang pengembangan) — adalah cabang berumur panjang dalam Git Flow yang berfungsi sebagai simpul pusat untuk integrasi kode dari semua pengembang. Cabang feature digabungkan ke dalamnya setelah pengembangan selesai dan melewati code review.

Kode di develop selalu dalam keadaan siap untuk membuat rilis, meskipun belum dipublikasikan ke produksi. Ini berarti semua fitur di develop telah melalui review, pengujian, dan pemeriksaan integrasi, tetapi masih menunggu siklus rilis mereka.

Berbeda dengan main, di mana setiap versi kode adalah rilis, develop berisi aliran perubahan yang berkelanjutan. Commit di develop muncul seiring dengan penggabungan cabang feature, yang dapat terjadi beberapa kali sehari.

Menurut data Vincent Driessen, 2010, develop adalah elemen kunci dari model percabangan yang sukses, karena memisahkan pekerjaan yang sedang berlangsung dari versi yang siap dirilis.

Perbedaan antara develop dan main branch

Memahami perbedaan antara develop dan main sangat penting untuk bekerja dengan benar dalam Git Flow. Cabang-cabang ini menjalankan fungsi yang berbeda dan memiliki persyaratan stabilitas yang berbeda.

Pemisahan develop dan main memungkinkan tim untuk terus mengintegrasikan kode baru tanpa membahayakan stabilitas versi produksi. Pengembang dapat melihat kode mereka di develop segera setelah PR disetujui, bahkan sebelum rilis resmi.

Peran develop dalam Git Flow

Dalam model Git Flow, develop menempati tempat sentral antara cabang feature (sumber perubahan) dan cabang release (persiapan rilis). Memahami hierarki ini adalah dasar dari percabangan yang efektif.

• Feature → Develop — setiap fitur yang selesai digabungkan ke develop melalui Pull Request dengan code review.
• Develop → Release — ketika volume perubahan yang cukup untuk rilis terkumpul, cabang release dibuat dari develop.
• Release → Main + Develop — setelah persiapan akhir, cabang release digabungkan ke main (rilis) dan kembali ke develop (perbaikan bug).
• Hotfix → Main + Develop — perbaikan kritis dibuat dari main dan digabungkan ke kedua cabang.

Struktur seperti itu menjamin bahwa develop selalu berisi versi kode terbaru dengan semua fitur baru, dan main — hanya kode produksi yang terverifikasi. Ini sangat penting untuk proyek mobile dengan siklus review yang panjang di App Store dan Google Play.

Hubungan develop dengan cabang Git Flow lainnya

Develop bertindak sebagai penghubung sentral antara cabang feature, release, dan hotfix. Memahami arah penggabungan adalah dasar untuk mencegah konflik dan kehilangan commit.

Persyaratan kualitas kode di develop

Kualitas kode di develop harus tinggi, tetapi tidak absolut. Berbeda dengan main, di mana setiap kesalahan berarti hotfix mendesak, develop memungkinkan kekurangan kecil yang akan diperbaiki sebelum rilis.

Persyaratan minimal untuk kode sebelum penggabungan ke develop:

• Kompilasi — kode harus dikompilasi tanpa kesalahan. Kompilasi yang rusak di develop memblokir pekerjaan seluruh tim.
• Pengujian unit — semua pengujian yang ada harus lulus. Kode baru harus memiliki cakupan pengujian minimal 70%.
• Code style — kode harus sesuai dengan standar pemformatan dan penamaan yang diterima di tim.
• Tidak ada API yang tidak berlaku — penggunaan metode usang tidak diizinkan dalam kode baru.

Pemeriksaan otomatis dalam pipeline CI/CD harus dijalankan pada setiap push ke develop. Jika kompilasi rusak, pengembang yang bertanggung jawab harus memperbaiki masalah dalam waktu satu jam atau mengembalikan commit-nya.

Pemeriksaan CI/CD untuk develop

Konfigurasi GitHub Actions untuk develop menjamin bahwa setiap PR sebelum penggabungan melewati pemeriksaan otomatis. Pipeline tipikal mencakup kompilasi, pengujian, dan linting.

# GitHub Actions — memeriksa develop setelah penggabungan
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Aturan penggabungan ke develop

Penggabungan ke develop harus mengikuti aturan ketat untuk menjaga stabilitas cabang integrasi. Pelanggaran aturan ini menyebabkan konflik, kompilasi rusak, dan kehilangan waktu tim.

• Hanya melalui Pull Request — push langsung ke develop dilarang. Semua perubahan melewati code review.
• Minimal satu setujuan — PR harus mendapatkan persetujuan dari setidaknya satu pengembang yang tidak berpartisipasi dalam tugas.
• Squash merge — disarankan untuk menggabungkan semua commit cabang feature menjadi satu saat penggabungan ke develop untuk riwayat yang bersih.
• Keaktualan PR — sebelum penggabungan, PR harus diperbarui terhadap commit terakhir develop (rebase atau merge).

Aturan keaktualan PR sangat penting. Jika cabang feature dibuat seminggu yang lalu dan develop telah maju 50 commit, penggabungan langsung dapat menyebabkan konflik yang lebih baik diselesaikan dalam konteks PR, bukan di develop.

Melindungi develop dari penggabungan yang salah

Branch protection rules (aturan perlindungan cabang) — adalah pengaturan di tingkat GitHub, GitLab, atau Bitbucket yang mencegah perubahan yang salah di develop. Mereka menjamin bahwa bahkan push yang tidak disengaja tidak akan merusak cabang integrasi.

Aturan perlindungan yang disarankan untuk develop:

• Require pull request — larang push langsung ke develop. Semua perubahan hanya melalui PR.
• Require approvals — minimal 1-2 persetujuan sebelum penggabungan PR.
• Require status checks — blokir penggabungan jika pipeline CI/CD tidak lulus.
• Require up-to-date — cabang PR harus diperbarui terhadap develop sebelum penggabungan.
• Restrict push access — batasi hak push ke develop hanya untuk pengembang senior.

Konfigurasi perlindungan develop membutuhkan waktu 10 menit, tetapi mencegah minggu-minggu waktu henti yang terkait dengan cabang integrasi yang rusak. Untuk proyek mobile dengan tim multi-platform, ini sangat relevan.

Contoh perintah untuk bekerja dengan develop

Mari kita lihat hari tipikal seorang pengembang: pagi hari dia memperbarui develop, membuat cabang feature baru, dan setelah menyelesaikan tugas, menggabungkan perubahan kembali ke develop.

# Sinkronisasi pagi develop
git checkout develop
git pull origin develop

# Membuat cabang feature baru dari develop
git checkout -b feature/add-push-notifications

# Bekerja pada fitur...
git add . && git commit -m "Add FCM integration"

# Memperbarui develop selama pengembangan
git fetch origin develop
git rebase origin/develop

# Setelah PR disetujui — memperbarui develop lokal
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

Perintah git pull di develop melakukan dua operasi sekaligus: git fetch (mengambil commit baru dari server) dan git merge (menggabungkannya dengan cabang lokal). Untuk develop, ini adalah cara standar sinkronisasi.

Memulihkan develop setelah penggabungan yang rusak

Jika kode yang merusak kompilasi masuk ke develop, harus bertindak cepat. Setiap jam waktu henti develop berarti pekerjaan seluruh tim pengembang terblokir.

Jika kode yang merusak kompilasi masuk ke develop, gunakan git revert untuk membuat commit baru yang membatalkan perubahan bermasalah. Jangan gunakan git reset di develop — ini menulis ulang riwayat yang sudah ada di peserta lain.

# Menemukan commit bermasalah
git log --oneline develop

# Membatalkan commit melalui revert (aman)
git revert a1b2c3d

# Mengirim perbaikan ke develop jarak jauh
git push origin develop

# Melihat perubahan dalam commit tertentu
git show a1b2c3d --stat