Push — apa itu, bagaimana cara kerja git push dan kapan diperlukan

Apa itu push di Git

Git push adalah perintah yang mentransfer commit dari repositori lokal ke repositori jarak jauh. Tidak seperti commit yang menyimpan perubahan hanya di mesin lokal pengembang, push mempublikasikan perubahan ini untuk seluruh tim. Push adalah langkah wajib sebelum membuat Pull Request dan melakukan deployment.

Arsitektur Git mengasumsikan bahwa setiap pengembang bekerja di repositori lokalnya sendiri. Commit dibuat secara lokal dan terakumulasi sampai pengembang memutuskan untuk melakukan push. Ini memberikan kebebasan: dapat melakukan banyak commit lokal, bereksperimen, dan menulis ulang sejarah tanpa memengaruhi rekan kerja.

# Push ke origin remote, cabang main
git push origin main

# Push cabang saat ini ke remote dengan upstream
git push -u origin feature/new-dashboard

# Push semua cabang dengan nama yang cocok
git push --all origin

# Force push dengan lease (force push aman)
git push --force-with-lease

Setelah push, repositori jarak jauh memperbarui refs (referensi ke cabang) sehingga menunjuk ke commit baru. Pengembang lain dapat mengambil perubahan ini melalui git pull atau git fetch. Pertukaran commit inilah yang menjadi dasar pengembangan kolaboratif.

Bagaimana cara kerja git push

Perintah git push membandingkan cabang lokal dan jarak jauh dan hanya mentransfer commit yang hilang. Git tidak mengirim semua file dari awal — hanya mengirim delta, yang membuat push cepat bahkan di repositori besar. Protokol Git menggunakan smart transfer yang meminimalkan jumlah data yang ditransfer.

Jika cabang jarak jauh berisi commit yang tidak ada secara lokal, push akan ditolak. Ini adalah mekanisme perlindungan yang mencegah hilangnya perubahan. Dalam situasi ini, pengembang harus terlebih dahulu menjalankan git pull, menggabungkan perubahan, dan kemudian melakukan push lagi. Alternatifnya adalah force push, yang menimpa cabang jarak jauh, tetapi harus digunakan dengan hati-hati.

Memahami repositori jarak jauh adalah kunci untuk push yang benar. Biasanya origin digunakan — nama default repositori jarak jauh. Perintah git remote -v menampilkan daftar repositori jarak jauh dan URL-nya. Beberapa remote dapat ditambahkan (misalnya, origin untuk repositori utama dan upstream untuk fork).

Kapan harus push perubahan

Aturan utama: push harus dilakukan setelah setiap tahap pekerjaan yang selesai secara logis. Jika pengembang telah menyelesaikan tugas atau bagian darinya — saatnya push. Namun, push pekerjaan yang belum selesai yang merusak build tidak disarankan. Build yang tidak rusak adalah persyaratan minimum untuk push ke cabang mana pun.

Dalam pengembangan tim, ritme berikut diterima: pagi hari — git pull untuk mendapatkan perubahan rekan kerja, sepanjang hari — beberapa commit dan satu atau dua push, sore hari — push akhir dari semua tugas yang selesai. Semakin sering pengembang melakukan push, semakin kecil risiko konflik saat menggabungkan cabang dan semakin transparan kemajuan pekerjaan.

• Setelah menyelesaikan tugas — commit dan push solusi akhir ke cabang feature
• Sebelum pulang — push pekerjaan yang belum selesai ke cabang feature (bukan ke main!)
• Sebelum membuat PR — pastikan semua commit sudah di-push dan tersedia untuk review
• Setelah rebase — push dengan --force-with-lease ke cabang feature sendiri

Aturan push yang aman

Push aman adalah seperangkat aturan yang mencegah kehilangan data dan konflik dalam tim. Aturan pertama dan terpenting: jangan pernah push langsung ke cabang main atau master, kecuali jika deployment langsung telah dikonfigurasi dalam proyek. Di tim modern, perlindungan cabang main dikonfigurasi di tingkat GitHub branch protection.

Aturan kedua: sebelum push, sinkronkan dengan cabang jarak jauh. Jalankan git pull --rebase untuk menghindari merge commit saat penggabungan. Ini menyederhanakan sejarah dan membuatnya linier. Jika push ditolak — jangan gunakan force push mentah, tetapi pertama-tama periksa commit apa yang muncul di cabang jarak jauh.

Aturan ketiga: konfigurasikan hook pre-push yang secara otomatis menjalankan tes dan linter sebelum pengiriman. Jika tes gagal — push diblokir. Hook semacam itu dikonfigurasi melalui Husky atau Git hooks (file pre-push di .git/hooks).

Aturan keempat: jangan push file biner besar. Git tidak dirancang untuk menyimpan artefak biner — mereka membengkakkan repositori dan memperlambat operasi. Untuk file besar, gunakan Git LFS (Large File Storage). Jika file biner sudah di-push dan masuk ke sejarah, harus dihapus melalui git filter-branch.

Apa yang harus dilakukan jika push gagal

Penyebab paling umum dari push yang gagal — cabang jarak jauh berisi commit yang tidak ada secara lokal. Ini terjadi ketika pengembang lain telah melakukan push perubahannya ke cabang yang sama. Solusi: jalankan git pull, selesaikan kemungkinan konflik, dan ulangi push.

# Push ditolak — fetch dan rebase dulu
git fetch origin
git rebase origin/main
# Selesaikan konflik, lalu:
git push --force-with-lease

# Atau cukup gabungkan perubahan jarak jauh
git pull origin main
git push

Penyebab kedua — tidak ada hak tulis ke cabang. Jika cabang main dilindungi oleh aturan branch protection, push langsung dilarang. Solusi: push ke cabang feature dan buat Pull Request. Pengaturan perlindungan biasanya dikelola melalui GitHub settings atau GitLab protected branches.

Penyebab ketiga — masalah autentikasi. Kredensial yang kedaluwarsa, peralihan ke SSH, atau perubahan personal access token. Solusi: periksa URL remote (git remote -v) dan perbarui kredensial. Sejak 2021, GitHub menghapus autentikasi kata sandi untuk HTTPS — menggunakan token pribadi atau kunci SSH.