Git dan kontrol versi dalam pengembangan seluler: apa itu, perintah dasar dan cara kerjanya

Kontrol versi dan Git: apa itu?

Git adalah sistem kontrol versi terdistribusi (VCS) yang dibuat oleh Linus Torvalds pada tahun 2005 untuk pengembangan kernel Linux. Tidak seperti sistem terpusat (SVN, CVS), Git menyimpan salinan lengkap riwayat proyek di setiap komputer pengembang. Ini berarti Anda dapat melakukan commit, menelusuri riwayat, dan membuat cabang bahkan tanpa koneksi internet.

Git bekerja dengan snapshot — setiap commit menyimpan keadaan semua file proyek pada saat penyimpanan. Jika file tidak berubah, Git membuat referensi ke versi sebelumnya, menghemat ruang. Menurut analisis GitHub (2025), repositori rata-rata berisi 1.200 commit dan 15 cabang.

Di IT Sectr, kami telah menggunakan Git sejak 2017 di semua proyek. Pengalaman kami menunjukkan bahwa konfigurasi Git yang tepat sejak hari pertama menghemat waktu tim hingga 30% dalam penggabungan dan penyelesaian konflik. Git telah menjadi standar de facto — didukung oleh semua IDE modern (Android Studio, Xcode, VS Code) dan sistem CI/CD.

# Pengaturan dasar Git
git config --global user.name "Nama Anda"
git config --global user.email "email@anda.com"

# Membuat repositori baru
git init my-project
cd my-project

# Menambahkan file dan commit
git add README.md
git commit -m "Initial commit"

# Bekerja dengan repositori jarak jauh
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Kode di atas menunjukkan urutan dasar: menginisialisasi repositori, commit pertama, dan publikasi ke server jarak jauh. Perintah git init membuat folder .git tersembunyi yang akan menyimpan seluruh riwayat proyek. Setiap git commit membuat titik pemulihan yang dapat Anda kembalikan kapan saja.

Konsep dasar: Repository, Branch, Commit

Memahami tiga konsep dasar — Repository, Branch, dan Commit — sangat penting untuk bekerja dengan sistem kontrol versi apa pun. Repositori adalah wadah untuk seluruh proyek. Commit adalah keadaan file yang disimpan. Branch adalah jalur pengembangan terpisah.

Repository (repositori) bisa lokal (di komputer Anda) atau jarak jauh (di server GitHub, GitLab). Setiap pengembang mengkloning repositori jarak jauh ke mesin mereka dan bekerja dengan salinan lokal. Perubahan disinkronkan melalui push (mengirim) dan pull (mengambil). Dalam kontrol versi terdistribusi, setiap pengembang menyimpan salinan lengkap riwayat.

Branch (cabang) adalah penunjuk ke salah satu commit. Cabang memungkinkan pengembangan paralel: satu pengembang bekerja pada fitur baru (feature branch), yang lain memperbaiki bug (hotfix branch), yang ketiga menyiapkan rilis (release branch). Menurut GitLab Flow (2025), proyek rata-rata memiliki 3–5 cabang aktif secara bersamaan.

Commit adalah unit perubahan. Setiap commit berisi hash unik (SHA-1), pesan, penulis, dan stempel waktu. Praktik yang baik adalah membuat commit kecil yang bermakna dengan pesan deskriptif — ini menyederhanakan Code Review dan pengembalian perubahan. Kontrol versi melalui commit memberi Anda riwayat proyek yang lengkap.

Feature Branch

Feature Branch (cabang fitur) adalah cabang sementara yang dibuat dari develop atau main untuk mengembangkan tugas tertentu. Setelah pekerjaan selesai, cabang digabungkan kembali melalui Pull Request dan dihapus. Praktik ini memungkinkan isolasi perubahan tanpa mengganggu stabilitas basis kode utama.

Alur kerja tipikal: buat cabang feature/add-login → lakukan beberapa commit → buat Pull Request → lalui Code Review → gabungkan ke develop. Di IT Sectr kami menggunakan pendekatan ini: setiap tugas Jira sesuai dengan cabang fitur terpisah. Ini menyederhanakan pelacakan perubahan dan pengembalian jika diperlukan.

Rebase vs Merge

Merge membuat commit penggabungan yang menggabungkan dua cabang. Ini mempertahankan riwayat lengkap, termasuk jalur pengembangan paralel. Rebase menulis ulang riwayat: ia mengambil commit dari satu cabang dan "menerapkan kembali" di atas cabang lain, menciptakan riwayat linier.

Merge lebih cocok untuk cabang publik dan tim besar di mana kronologi penting. Rebase nyaman untuk cabang fitur pribadi sebelum membuat PR — membuat riwayat lebih bersih dan mudah dipahami. Namun, rebase tidak boleh pernah diterapkan pada cabang yang sedang dikerjakan oleh pengembang lain, karena menulis ulang riwayat.

# Membuat dan beralih ke cabang fitur
git checkout -b feature/add-login main

# Bekerja di cabang
git add login-screen/
git commit -m "Add login screen layout"

# Rebase ke main terbaru sebelum PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push ke repositori jarak jauh
git push origin feature/add-login

Contoh ini menunjukkan alur kerja tipikal: membuat cabang fitur dari main, beberapa commit dan rebase untuk mendapatkan riwayat linier yang bersih sebelum dikirim untuk ditinjau. Pendekatan ini meminimalkan konflik penggabungan.

Git Flow vs Trunk-Based Development

Git Flow dan Trunk-Based Development adalah dua strategi kontrol versi utama yang menentukan bagaimana tim mengatur pekerjaan dengan Git. Pilihan tergantung pada ukuran tim, frekuensi rilis, dan persyaratan stabilitas.

Git Flow adalah model ketat dengan beberapa cabang permanen: main (kode rilis), develop (pengembangan saat ini), feature/* (fitur baru), release/* (persiapan rilis) dan hotfix/* (perbaikan mendesak). Model ini baik untuk proyek dengan siklus rilis yang jelas (misalnya, aplikasi seluler dengan versi 1.0, 2.0).

Trunk-Based Development adalah pendekatan dengan satu cabang utama (trunk/main) di mana semua pengembang menggabungkan perubahan beberapa kali sehari. Bendera fitur digunakan untuk menyembunyikan fitur yang belum selesai. Pendekatan ini populer dalam pengembangan web dan startup di mana kecepatan pengiriman penting.

Git Flow

Git Flow, yang diusulkan oleh Vincent Driessen pada tahun 2010, tetap menjadi salah satu model paling populer. Keuntungan utamanya adalah pemisahan kode yang ketat berdasarkan tahap siklus hidup. Cabang main hanya berisi kode rilis, develop berisi pengembangan saat ini, dan cabang fitur mengisolasi fitur baru satu sama lain.

Cabang hotfix dibuat dari main untuk perbaikan mendesak dan setelah penggabungan digabungkan kembali ke main dan develop. Cabang release dibuat dari develop ketika tim siap untuk rilis. Hanya perbaikan bug dan metadata (versi, build) yang ditambahkan ke dalamnya. Setelah rilis, cabang release digabungkan ke main dan develop. Menurut survei JetBrains (2024), 37% tim menggunakan Git Flow. Model kontrol versi ini tetap menjadi standar untuk proyek dengan rilis tetap.

# Contoh Git Flow: memulai pekerjaan pada rilis
git checkout -b release/1.2.0 develop

# Memperbaiki bug di cabang release
git commit -m "Fix login button crash"

# Menyelesaikan rilis — gabungkan ke main dan develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Menghapus cabang release
git branch -d release/1.2.0

Kode mengilustrasikan pembuatan cabang release, stabilisasi, dan penggabungan ke cabang utama. Bendera --no-ff menjamin commit penggabungan, mempertahankan informasi bahwa perubahan berasal dari cabang release.

Pull Request dan Code Review

Pull Request (PR) adalah mekanisme di mana pengembang mengusulkan perubahan dari cabang mereka ke cabang utama. PR adalah elemen kunci kontrol versi dalam kerja tim — ini bukan hanya cara untuk menggabungkan kode, tetapi proses diskusi, peninjauan, dan pemeriksaan kualitas. Di GitLab, mekanisme serupa disebut Merge Request (MR), tetapi esensinya sama: memberi tahu tim tentang perubahan dan mendapatkan persetujuan.

PR yang baik harus kecil (hingga 300 baris kode), fokus pada satu tugas, dan berisi deskripsi tentang apa yang dilakukan dan mengapa. Menurut studi Google (2025), PR dengan lebih dari 400 baris membutuhkan waktu dua kali lipat untuk ditinjau, dan kemungkinan mendeteksi bug berkurang 30%. Code Review adalah pemeriksaan kode oleh pengembang lain sebelum penggabungan.

Di IT Sectr, kami menerapkan Code Review wajib untuk setiap PR. Ini tidak hanya meningkatkan kualitas kode tetapi juga membantu menyebarkan pengetahuan di dalam tim. Code Review memeriksa: apakah kode mengikuti prinsip arsitektur, apakah ada bug, apakah ada cukup pengujian, apakah variabel dinamai dengan benar. Semua komentar didiskusikan dalam PR hingga penggabungan.

Platform: GitHub, GitLab, Bitbucket

Git adalah protokol, tetapi untuk kolaborasi diperlukan platform kontrol versi yang menyediakan antarmuka web, manajemen akses, CI/CD, dan alat peninjauan. Tiga platform mendominasi pasar: GitHub, GitLab, dan Bitbucket.

GitHub adalah platform terbesar dengan lebih dari 56 juta pengembang. Dimiliki oleh Microsoft, menawarkan Actions (CI/CD), Pages (hosting), Discussions, dan Copilot. Paket gratis mencakup repositori pribadi tak terbatas untuk tim hingga 3 orang. GitHub populer di komunitas open-source.

GitLab adalah platform DevOps lengkap dengan CI/CD terintegrasi, registri wadah, dan manajemen infrastruktur. Tidak seperti GitHub, GitLab dapat diinstal di server Anda sendiri (Self-Managed). Bitbucket dari Atlassian terintegrasi erat dengan Jira dan Confluence, menjadikannya pilihan untuk tim yang sudah menggunakan ekosistem Atlassian.