Git yang Aman untuk Mengelola Perubahan Website Produksi

Git pada proyek produksi bukan kumpulan perintah untuk dihafal. Ia menjadi pagar agar perubahan UI, artikel, metadata, dan konfigurasi server dapat diperiksa serta dibatalkan tanpa menimpa pekerjaan lain. Studi kasus ini memakai repository NgodingSantai yang dikembangkan di Windows dan dideploy ke Ubuntu.

Mulai setiap sesi dengan status

git status --short membedakan file berubah, baru, dihapus, atau mengalami conflict. Langkah ini penting karena workspace dapat berisi perubahan pengguna yang tidak terkait dengan tugas saat ini. Perubahan tersebut tidak dihapus atau dimasukkan commit tanpa memahami kepemilikannya.

git status --short
git branch --show-current
git log -5 --oneline --decorate

Baca diff sebelum staging

git diff --stat memberi ukuran perubahan, lalu git diff -- path memperlihatkan isi file tertentu. File generated seperti sitemap tetap diperiksa karena generator dapat menghasilkan URL salah walaupun script berhasil.

git diff --stat
git diff -- assets/css/style.css
git diff -- sitemap.xml
git diff --check

git diff --check menemukan whitespace error tertentu. Ia bukan validator HTML atau JavaScript sehingga audit sintaks dan browser tetap dijalankan.

Stage berdasarkan keputusan, bukan semua file

git add . nyaman tetapi mudah menyertakan screenshot sementara, private key, atau perubahan eksperimen. Proyek ini memilih path yang relevan, lalu memeriksa diff staged.

git add articles assets index.html blog.html redaksi.html sitemap.xml
git diff --cached --stat
git diff --cached

Commit menjelaskan satu hasil

Pesan commit menyebut hasil seperti “Fix intrinsic sizing in mobile navigation” atau “Add VPS migration case studies”. Commit terlalu besar menyulitkan review, tetapi memecah perubahan yang saling bergantung menjadi commit setengah jadi juga tidak membantu. Batasnya adalah satu keputusan yang dapat diuji.

Sinkronkan sebelum push

Jika remote berubah, ambil referensi terlebih dahulu. Pada branch bersama, rebase atau merge dipilih di workstation setelah diff dibaca. Konflik tidak diselesaikan langsung di VPS.

git fetch origin
git log --oneline --left-right HEAD...origin/master
git pull --ff-only origin master
git push origin master

pull --ff-only sengaja gagal bila riwayat bercabang. Kegagalan ini lebih aman daripada merge otomatis yang tidak diperiksa.

Bedakan restore, revert, dan reset

Perintah	Kapan dipakai	Dampak
git restore file	Membuang perubahan working tree yang belum diperlukan	Dapat menghilangkan edit lokal; periksa diff dulu
git revert commit	Membalik commit yang sudah dibagikan	Membuat commit baru dan menjaga riwayat
git reset	Mengatur ulang pointer atau staging secara lokal	Mode hard dapat menghapus perubahan; tidak dipakai sembarangan

Untuk produksi, revert biasanya paling dapat dilacak. Reset keras bukan prosedur default dan tidak digunakan untuk membersihkan workspace pengguna.

Periksa server sebelum pull

Working tree VPS harus bersih. Jika ada perubahan lokal, hentikan pull dan selidiki. Bisa saja seseorang melakukan hotfix atau file berubah akibat proses yang tidak semestinya. Simpan diff, tentukan apakah perubahan dibutuhkan, lalu bawa koreksi kembali ke repository utama.

git -C /var/www/ozancicak.biz.id status --short
git -C /var/www/ozancicak.biz.id fetch origin master
git -C /var/www/ozancicak.biz.id pull --ff-only origin master

Jangan simpan rahasia di Git

Private key deploy, password, token API, dan file environment dengan credential tidak ditambahkan. Menambahkan lalu menghapus pada commit berikutnya tidak menghilangkan rahasia dari riwayat. Jika kebocoran terjadi, credential dicabut dan diganti, kemudian riwayat dibersihkan bila memang diperlukan.

Workflow perubahan situs

1. Periksa status dan commit awal.
2. Edit satu kelompok masalah.
3. Jalankan validator serta browser audit.
4. Baca diff unstaged.
5. Stage path yang dimaksud dan baca diff staged.
6. Commit dengan hasil yang spesifik.
7. Push, pull fast-forward di VPS, lalu verifikasi URL publik.

Referensi primer

• Git status.
• Git diff.
• Git revert.

Gunakan branch untuk eksperimen berisiko

Perubahan konten kecil dapat dilakukan langsung pada branch kerja sesuai kebijakan proyek, tetapi refactor generator, navigasi, atau deployment lebih aman pada branch terpisah. Branch memungkinkan audit lengkap sebelum digabung tanpa membuat branch produksi berisi keadaan setengah selesai.

Conflict adalah perbedaan keputusan

Marker conflict tidak dihapus sembarangan. Kedua sisi dibaca, maksud perubahan dibandingkan, lalu hasil final diuji. Untuk file generated, konflik diselesaikan pada sumber datanya kemudian generator dijalankan ulang; menggabungkan output generated secara manual mudah menghasilkan sinkronisasi palsu.

Tag rilis bila frekuensi meningkat

Saat deployment mulai sering, annotated tag dapat menandai versi yang benar-benar live. Tag tidak menggantikan commit atau backup, tetapi membantu menghubungkan laporan produksi dengan source yang tepat. Nama rilis dan changelog tetap berbasis perubahan nyata.