Mengatur Dotfiles supaya Setup Mesin Baru Cepat

Sebagai developer yang kerja lintas peran—dari nulis kode Laravel/Vue sampai ngurusin server Docker di kantor—saya cukup sering pindah atau ganti mesin kerja. Kadang laptop rusak, kadang perlu setup mesin baru untuk tim, kadang cuma remote ke server dan pengin shell-nya terasa familiar. Kalau konfigurasi shell, git, editor, dan tool CLI cuma nyangkut di satu mesin secara manual, tiap kali ganti device saya harus mengingat-ingat ulang semua pengaturan itu dari nol. Di sinilah dotfiles jadi penyelamat: konfigurasi disimpan di repo Git, jadi tinggal clone dan jalankan satu skrip, mesin baru langsung terasa seperti mesin lama.

Dotfiles adalah istilah umum untuk file-file konfigurasi yang biasanya diawali titik di home directory—seperti .zshrc, .gitconfig, .vimrc, atau folder konfigurasi seperti .config/nvim. Karena file-file ini menentukan bagaimana shell, editor, dan tool CLI kita berperilaku, menyimpannya secara terversi bukan cuma soal backup, tapi juga soal reproducibility: mesin baru bisa dikonfigurasi persis seperti yang biasa dipakai, tanpa proses coba-coba yang membosankan.

Kenapa dotfiles perlu diversi, bukan sekadar disalin manual

Pendekatan paling sederhana adalah menyalin file konfigurasi dari mesin lama ke mesin baru lewat USB atau AirDrop. Masalahnya, cara ini tidak punya riwayat perubahan. Begitu saya menambah satu alias git baru atau mengubah tema shell, saya tidak punya cara mudah melacak kapan dan kenapa perubahan itu dibuat, apalagi membatalkannya kalau ternyata bikin masalah.

Dengan menaruh dotfiles di repo Git, setiap perubahan konfigurasi jadi commit. Saya bisa lihat riwayatnya, revert kalau ada yang salah, dan yang penting: repo itu jadi satu sumber kebenaran yang bisa di-pull dari mesin mana pun. Praktik umum yang saya pakai adalah membuat repo khusus bernama dotfiles, isinya file-file konfigurasi yang sudah dirapikan, plus satu skrip instalasi.

Struktur repo yang praktis

Struktur yang saya sarankan cukup sederhana. Taruh tiap file konfigurasi apa adanya di root repo atau di folder bernama sesuai tool-nya, misalnya:

dotfiles/
  zsh/.zshrc
  git/.gitconfig
  nvim/init.lua
  install.sh

Skrip install.sh tugasnya cuma satu: membuat symlink dari file di repo ke lokasi aslinya di home directory. Ilustrasinya kira-kira begini:

#!/bin/bash
DOTFILES_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
ln -sf "$DOTFILES_DIR/zsh/.zshrc" "$HOME/.zshrc"
ln -sf "$DOTFILES_DIR/git/.gitconfig" "$HOME/.gitconfig"
ln -sf "$DOTFILES_DIR/nvim" "$HOME/.config/nvim"

Kenapa pakai symlink, bukan copy? Karena dengan symlink, perubahan yang saya buat di file aslinya (misalnya edit .zshrc langsung dari terminal) otomatis tersimpan di dalam repo, tinggal git commit. Kalau pakai copy manual, saya harus ingat menyalin balik setiap kali ada perubahan—dan itu gampang terlupa.

Hal-hal yang wajib dipisahkan: rahasia vs konfigurasi

Ini bagian yang paling sering diabaikan pemula, padahal krusial. Dotfiles itu untuk konfigurasi, bukan untuk kredensial. Token API, password database, atau key SSH tidak boleh ikut nyangkut di repo dotfiles, apalagi kalau repo itu publik. Pendekatan yang aman:

  • Simpan nilai rahasia di file terpisah yang tidak diversi, misalnya .env.local atau ~/.secrets, lalu di-source dari .zshrc dengan baris seperti [ -f ~/.secrets ] && source ~/.secrets.
  • Tambahkan pola file-file rahasia itu ke .gitignore sejak awal, sebelum sempat ke-commit sekali pun.
  • Untuk key SSH atau GPG, cukup versi-kan konfigurasi (misalnya ~/.ssh/config untuk alias host), bukan private key-nya sendiri.

Kalau butuh menyimpan rahasia secara terenkripsi di repo juga, ada tool khusus untuk itu (misalnya yang berbasis GPG atau age), tapi untuk kebanyakan kasus sehari-hari, cukup memisahkan rahasia ke luar repo sudah aman dan simpel.

Menjaga dotfiles tetap portable antar OS

Kalau kerja di beberapa jenis mesin—katakanlah macOS di kantor dan Linux di server—konfigurasi tidak selalu bisa disamakan seratus persen. Cara yang saya pakai adalah menambahkan pengecekan OS di dalam file konfigurasi itu sendiri, bukan bikin dua repo terpisah. Misalnya di .zshrc, saya taruh blok kondisional yang hanya aktif kalau berjalan di macOS (mengatur alias khusus Homebrew) atau di Linux (mengatur path package manager berbeda). Dengan begitu, satu repo dotfiles tetap jadi satu sumber kebenaran, tapi cukup adaptif untuk lingkungan yang berbeda.

Takeaway

Intinya, dotfiles yang dikelola dengan baik mengubah proses setup mesin baru dari yang tadinya bisa berjam-jam jadi sesederhana git clone lalu jalankan satu skrip instalasi. Mulai dari yang kecil: kumpulkan .zshrc, .gitconfig, dan konfigurasi editor ke satu repo, pisahkan rahasia sejak awal, dan biasakan commit setiap kali ada perubahan kecil. Begitu terbiasa, dotfiles bukan lagi proyek sampingan, tapi bagian dari rutinitas kerja yang bikin hidup sebagai developer jauh lebih ringan setiap kali harus mulai dari mesin kosong.