Main dan Master Branch di Git: apa itu dan mengapa cabang utama diperlukan

Apa itu Main / Master Branch di Git

Main Branch (atau Master — tergantung pada pengaturan repositori) — adalah cabang default yang dibuat saat inisialisasi repositori Git mana pun. Ini adalah cabang utama proyek dan berisi kode yang siap untuk diterapkan ke produksi.

Tidak seperti develop, di mana pekerjaan sehari-hari dengan fitur baru berlangsung, main adalah etalase proyek. Setiap versi kode di main telah melalui siklus lengkap: pengembangan di cabang feature, integrasi di develop, persiapan rilis di cabang release, dan pengujian akhir. Hanya setelah itu perubahan masuk ke main.

Prinsip Utama: main harus selalu stabil. Jika kesalahan ditemukan di main, itu berarti hotfix mendesak yang harus dirilis di luar jadwal. Oleh karena itu, dalam proyek profesional, main dilindungi dari perubahan yang tidak disengaja oleh branch protection rules.

Menurut Git Book, main bukanlah cabang khusus dengan properti istimewa, melainkan referensi biasa ke sebuah commit yang menurut konvensi dianggap utama. Git tidak membedakan antara main dan cabang lainnya di tingkat sistem.

Transisi dari master ke main

Secara historis, cabang default di Git disebut master. Pada Juni 2020, gerakan Black Lives Matter menyoroti istilah master dan slave di industri IT. GitHub mengumumkan transisi ke istilah main untuk cabang default.

Sejak Oktober 2020, semua repositori baru di GitHub dibuat dengan cabang main. GitLab dan Bitbucket juga menerapkan dukungan untuk main sebagai nama default. Git 2.28 (Juli 2020) menambahkan opsi init.defaultBranch untuk mengonfigurasi nama cabang default.

Secara teknis, mengganti nama cabang yang ada dari master ke main adalah operasi sederhana. Tantangan utamanya adalah memperbarui semua referensi di konfigurasi CI/CD, dokumentasi, dan repositori lokal pengembang.

Untuk mengganti nama cabang di repositori yang ada, jalankan:

# Penggantian nama lokal master menjadi main
git branch -m master main

# Memperbarui repositori jarak jauh
git push -u origin main

# Menghapus master lama di server
git push origin --delete master

# Memperbarui HEAD di server
# (melalui antarmuka web GitHub: Settings → Branches → Default branch)

Peran main di Git Flow dan GitHub Flow

Git Flow dan GitHub Flow mendefinisikan peran cabang main secara berbeda. Pemilihan model tergantung pada ukuran tim, frekuensi rilis, dan persyaratan stabilitas kode.

Untuk pengembangan aplikasi mobile, standarnya adalah Git Flow, karena publikasi aplikasi di App Store dan Google Play memiliki siklus rilis yang tetap. GitHub Flow lebih cocok untuk proyek web dengan kemungkinan penerapan beberapa kali sehari.

GitHub Flow — pendekatan yang disederhanakan

Di GitHub Flow tidak ada cabang develop. Semua cabang feature dibuat langsung dari main, dan setelah selesai digabungkan kembali melalui Pull Request. Setiap penggabungan ke main secara otomatis memicu penerapan ke produksi. Model ini memerlukan otomatisasi pengujian yang tinggi dan disiplin tim.

Di GitHub Flow tidak ada cabang develop. Semua cabang feature dibuat langsung dari main, dan setelah selesai digabungkan kembali melalui Pull Request. Setiap penggabungan ke main secara otomatis memicu penerapan ke produksi. Model ini memerlukan otomatisasi pengujian yang tinggi dan disiplin tim.

Perlindungan cabang main

Branch protection untuk main — pengaturan wajib di setiap proyek komersial. Tanpa itu, push yang tidak disengaja dapat mengirim kode yang belum selesai ke produksi atau merusak aplikasi yang berfungsi untuk semua pengguna.

• Require pull request — push langsung ke main dilarang. Semua perubahan melalui PR dengan peninjauan.
• Require approvals — minimal 2 persetujuan untuk penggabungan ke main (jika terjadi kesalahan satu peninjau).
• Require status checks — semua pemeriksaan CI/CD harus berhasil sebelum penggabungan.
• Require up-to-date — PR harus didasarkan pada commit terbaru main.
• Include administrators — perlindungan berlaku bahkan untuk pemilik repositori.
• Require signed commits — semua commit di main harus ditandatangani dengan kunci GPG.

Mengonfigurasi keenam aturan — standar untuk proyek mobile dengan audiens 10.000+ pengguna. Untuk proyek kecil, tiga aturan pertama sudah cukup.

Perbandingan tingkat perlindungan untuk berbagai jenis proyek

Tingkat perlindungan main tergantung pada skala proyek. Startup dapat bertahan dengan perlindungan minimal, sementara aplikasi enterprise memerlukan batasan maksimal.

Rilis dan tag di main

Penandaan (tagging) — praktik membuat referensi bernama ke commit tertentu di main. Setiap tag sesuai dengan versi aplikasi yang dirilis ke produksi. Ini memungkinkan peralihan cepat ke rilis sebelumnya untuk debugging atau patch.

Standar penamaan tag dalam pengembangan aplikasi mobile — SemVer (Semantic Versioning): v1.2.3, di mana nomor pertama adalah versi utama (breaking changes), kedua — minor (fitur baru), ketiga — patch (perbaikan).

Tag dibuat setelah penggabungan cabang release ke main. Commit ini kemudian dibangun di CI/CD, ditandatangani, dan dikirim ke toko aplikasi. Jika kesalahan ditemukan di tag, cabang hotfix dibuat dari tag tersebut.

# Membuat tag rilis beranotasi
git tag -a v2.4.1 -m "Release version 2.4.1"

# Mengirim tag ke server
git push origin v2.4.1

# Melihat semua tag di repositori
git tag -l "v2.*"

# Membuat cabang hotfix dari tag tertentu
git checkout -b hotfix/crash-fix v2.4.1

Hierarki cabang Git Flow

Memahami hierarki cabang di Git Flow — dasar untuk organisasi pengembangan kolaboratif yang benar. Setiap jenis cabang memiliki sumber, tujuan, dan aturan penggabungan sendiri.

• Main (Level 1) — cabang akar, hanya berisi versi rilis. Dibuat saat inisialisasi repositori.
• Develop (Level 2) — dibuat dari main saat awal proyek. Berisi kode integrasi semua fitur.
• Feature (Level 3) — dibuat dari develop. Pengembangan terisolasi dari fitur individu.
• Release (Level 2) — dibuat dari develop. Persiapan rilis tertentu untuk diluncurkan.
• Hotfix (Level 2) — dibuat dari main. Perbaikan mendesak kesalahan kritis produksi.

Aturan penting: feature tidak pernah digabungkan langsung ke main. feature → develop → release → main — rantai penggabungan yang benar. Pelanggaran aturan ini menghilangkan makna seluruh model Git Flow.

Contoh perintah untuk bekerja dengan main

Pertimbangkan skenario: tim telah menyelesaikan persiapan rilis v2.5.0. Cabang release telah diperiksa dan siap untuk digabungkan ke main. Setelah penggabungan, tag dibuat dan rilis dipublikasikan.

# Beralih ke main dan memperbarui
git checkout main
git pull origin main

# Menggabungkan cabang release yang telah diperiksa
git merge --no-ff release/2.5.0

# Membuat tag rilis
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Mengirim main dan tag ke server
git push origin main --tags

Bendera --no-ff (no fast-forward) menjamin pembuatan commit penggabungan, bahkan jika penggabungan dapat dilakukan dengan perpindahan pointer sederhana. Ini menyimpan informasi bahwa perubahan berasal dari cabang release, yang menyederhanakan analisis riwayat.

Bekerja dengan hotfix melalui main

Jika kesalahan kritis ditemukan di produksi, prosesnya berbeda dari rilis biasa. Hotfix dibuat dari main, dan setelah perbaikan digabungkan baik ke main maupun develop.

Jika kesalahan kritis ditemukan di produksi, prosesnya berbeda dari rilis biasa. Hotfix dibuat dari main, dan setelah perbaikan digabungkan baik ke main maupun develop.

# Membuat cabang hotfix dari main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Memperbaiki dan melakukan commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Menggabungkan hotfix kembali ke main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Menggabungkan hotfix juga ke develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Menghapus cabang hotfix
git branch -d hotfix/2.5.1-crash-fix