Workflow Git Main dan Develop untuk Project Pribadi yang Tidak Ribet
Git sering terasa menakutkan bukan karena perintahnya terlalu banyak, melainkan karena satu perintah bisa mengubah riwayat pekerjaan. Untuk proyek pribadi, kamu tidak harus menggunakan proses serumit tim perusahaan. Yang dibutuhkan adalah alur yang mudah dipahami dan sulit membuat kesalahan besar.
Salah satu pilihan yang cukup nyaman adalah memakai dua branch tetap: main untuk versi produksi dan develop untuk proses pengembangan.
Apa bedanya main dan develop?
Bayangkan main sebagai etalase toko. Apa pun yang ada di sana sebaiknya sudah bisa dipakai pengunjung. Sementara develop adalah meja kerja: kita bebas menggabungkan perubahan yang masih perlu diperiksa.
Saat membuat fitur baru, jangan langsung menumpuk semua eksperimen di develop. Buat branch sementara seperti feature/search atau feature/article-card sehingga perubahan lebih mudah dilacak.
Memulai repository dengan benar
Pastikan Git telah terpasang dan nama pengguna sudah diatur:
git --version
git config --global user.name "Nama Kamu"
git config --global user.email "email-yang-sudah-terverifikasi"
Di folder proyek yang belum memiliki repository:
git init
git add .
git commit -m "Initial commit"
git branch -M main
Kenapa perlu commit sebelum push? Karena branch tanpa commit belum punya referensi perubahan untuk dikirim. Ini salah satu penyebab pesan src refspec main does not match any yang cukup sering dialami pemula.
Membuat branch develop
Setelah main memiliki commit, buat branch pengembangan:
git switch -c develop
git push -u origin develop
Tanda -u menyimpan hubungan antara branch lokal dan branch di remote. Setelah itu, git push biasanya cukup tanpa menyebut nama remote setiap kali.
Untuk fitur baru:
git switch develop
git pull --ff-only
git switch -c feature/search
Kerjakan fitur, lalu commit dengan pesan yang menjelaskan hasilnya:
git add src/components/Search.astro
git commit -m "Add search component"
git push -u origin feature/search
Buka pull request di GitHub dari feature/search ke develop. Periksa daftar file yang berubah sebelum merge.
Kapan perubahan masuk ke produksi?
Jika fitur di develop sudah diuji, buat pull request dari develop ke main. Hosting yang terhubung ke main dapat menerbitkan versi baru otomatis setelah merge. Dengan begitu, kamu punya batas yang jelas antara pekerjaan dan rilis.
Untuk keadaan mendesak, buat branch hotfix/nama-masalah dari main, selesaikan perbaikannya, lalu pastikan hasilnya juga dibawa kembali ke develop.
Tiga kebiasaan yang sangat membantu
Pertama, selalu jalankan git status sebelum commit. Kedua, baca git diff sebelum menambahkan file. Ketiga, pastikan .gitignore melarang node_modules, .env, hasil build, dan file editor sementara masuk ke repository.
Kalau suatu hari salah langkah, jangan langsung memakai git reset --hard hanya karena terlihat cepat. Cari tahu dulu apakah perubahan sudah ter-commit dan apakah orang lain mungkin mengandalkan riwayat itu.
Alur Git yang bagus tidak harus rumit. Ia cukup memberi kamu keberanian untuk bereksperimen karena selalu ada cara melihat kembali apa yang sudah berubah.



