SSH vs HTTPS

Alamat remote yang kita salip dari platform selalu hadir dalam dua bentuk — dan memilih salah satunya bukan urusan selera. Pilihan protokol menentukan pintu jaringan yang kita lalui setiap fetch dan push, kredensial yang diminta, dan seberapa ramah terhadap firewall kantor. Keduanya mengantarkan ke repository yang sama persis — riwayat, branch, dan berkas identik — jadi keputusannya murni soal akses. Chapter ini membedah kedua jalur itu, lalu menunjukkan bahwa pilihan bisa diganti kapan saja: satu perintah set-url, plus satu trik konfigurasi yang menulis ulang alamat secara otomatis.

Dua Protokol, Dua Pintu #

Kedua protokol sama-sama menjalankan Git di atas koneksi terenkripsi — HTTPS lewat TLS, SSH lewat protokolnya sendiri — jadi pertanyaannya bukan mana yang “lebih aman”, melainkan pintu mana yang terbuka dan kredensial mana yang nyaman kita kelola. Bab credential helper merinci cara Git menyimpan kredensial HTTPS agar tidak ditanyakan berulang.

Format URL per Platform #

Perbedaan bentuk alamatnya mudah dikenali: HTTPS memakai awalan https:// dan garis miring, sedangkan SSH memakai format pengguna@host: dengan titik dua:

Keduanya bisa dipakai untuk clone maupun remote, dan keduanya menuntut autentikasi hanya untuk operasi menulis (push) atau repository privat — clone repository publik lewat HTTPS bahkan tidak meminta apa pun.

Kredensial: Token atau Kunci #

Di jalur HTTPS, platform modern tidak lagi menerima kata sandi akun untuk Git — yang diminta adalah personal access token: deretan karakter buatan sendiri dengan masa berlaku dan cakupan izin yang bisa dibatasi, dibedah khusus di Personal Access Token . Di jalur SSH, autentikasi memakai kunci kriptografi: kunci privat diam di komputer, kunci publik didaftarkan ke platform, dan pasangan itu membuktikan identitas tanpa satu ketikan pun — panduannya menjadi agenda Membuat dan Menggunakan SSH Key .

Praktisnya begini: HTTPS unggul di hari pertama — clone langsung jalan, token tinggal dibuat saat pertama kali diminta. SSH unggul di hari ke-seratus — sekali kunci terpasang, ribuan push berikutnya berlalu tanpa satu prompt pun.

Berpindah Protokol dengan set-url #

Repository lokal tidak perlu di-clone ulang untuk berganti protokol — git remote set-url mengganti isinya dalam satu perintah. Demo berikut memakai alamat GitHub fiktif budi/toko-buku; perintahnya hanya menyentuh konfigurasi tanpa jaringan, dan padanan lengkapnya sudah dibedah di Mengganti Remote URL . Mulai dari repository yang terdaftar lewat HTTPS:

git remote add origin https://github.com/budi/toko-buku.git
git remote -v

Output yang Dihasilkan:

origin  https://github.com/budi/toko-buku.git (fetch)
origin  https://github.com/budi/toko-buku.git (push)

Keinginan berganti muncul — misalnya bosan memasukkan token, atau kunci SSH barusan terpasang. Satu perintah memindahkan pintunya:

git remote set-url origin [email protected]:budi/toko-buku.git
git remote -v

Output yang Dihasilkan:

origin  [email protected]:budi/toko-buku.git (fetch)
origin  [email protected]:budi/toko-buku.git (push)

git remote get-url origin

Output yang Dihasilkan:

[email protected]:budi/toko-buku.git

Kedua baris origin kini memakai format SSH, dan operasi berikutnya — fetch, push — otomatis memakai jalur baru. Riwayat, branch, dan pengaturan upstream tidak tersentuh sama sekali: yang berubah cuma baris alamat di buku alamat.

url.insteadOf: Penulisan Ulang Otomatis #

Kadang ganti protokol sekali tidak cukup: seluruh tim ingin pindah dari HTTPS ke SSH tanpa menyentuh puluhan repository, atau kantor baru hanya membuka port 443. Git punya jawaban konfigurasi: url.<basis>.insteadOf — URL remote yang berawalan string tertentu ditulis ulang otomatis saat dipakai. Demo berikut membuktikannya dengan gudang lokal yang diberi alias bergaya SSH, lalu alias itu dipakai sebagai alamat remote:

git config url."/home/z/my-project/tutorial-extracted/work/sandbox/git-hosting-platforms/part-a/latihan-insteadof/gudang/".insteadOf "git@lokal:"
git remote add origin git@lokal:toko.git

Apa yang tersimpan dan apa yang dipakai Git kini dua hal berbeda — dan ketiganya layak diperiksa:

git config --get remote.origin.url

Output yang Dihasilkan:

git@lokal:toko.git

git remote -v

Output yang Dihasilkan:

origin  /home/z/my-project/tutorial-extracted/work/sandbox/git-hosting-platforms/part-a/latihan-insteadof/gudang/toko.git (fetch)
origin  /home/z/my-project/tutorial-extracted/work/sandbox/git-hosting-platforms/part-a/latihan-insteadof/gudang/toko.git (push)

Berkas konfigurasi tetap menyimpan alias git@lokal:toko.git, sementara git remote -v menampilkan alamat hasil penulisan ulang. Bukti bahwa penulisan ulang benar-benar berfungsi datang dari koneksi sungguhan — git ls-remote membaca isi remote melalui alias dan berhasil:

git ls-remote origin

Output yang Dihasilkan:

2f490dd2df31a488523c1f77608c4e0acad9650e	HEAD
2f490dd2df31a488523c1f77608c4e0acad9650e	refs/heads/main

Bila konfigurasi itu tidak bekerja, ls-remote akan gagal menemukan server bernama lokal — keluaran di atas membuktikan alamat telah dialihkan ke gudang lokal. Di dunia nyata, contoh pemakaiannya kebalikan demo ini — mengalihkan SSH ke HTTPS karena firewall mempersempit pintu:

git config url."https://github.com/".insteadOf "[email protected]:"

Dengan satu baris itu di ~/.gitconfig, seluruh remote berawalan [email protected]: — lama maupun baru — otomatis berjalan lewat HTTPS tanpa disentuh satu per satu. Bila beberapa aturan insteadOf cocok pada satu URL, Git memakai aturan dengan awalan terpanjang. Rincian lengkapnya ada di dokumentasi git config .

Kapan Memilih yang Mana #

Dua catatan menyeimbangkan tabel. Performa: untuk repository ukuran biasa, kecepatan transfer kedua protokol nyaris tak terbedakan — yang terasa berbeda adalah autentikasinya, karena HTTPS berjabat tangan kredensial tiap operasi (sampai credential helper mengambil alih) sementara SSH cukup sekali per koneksi. Audit: token HTTPS dapat dibuat per-peruntungan, dibatasi cakupannya, dan dicabut individual — kualitas yang membuat tim keamanan menyukainya; kunci SSH lebih sulit dibatasi sehalus itu, tetapi pemiliknya tetap jelas di log platform.

Pilihan protokol menetap, dan bila kita memilih jalur SSH, satu urutan pekerjaan masih tersisa sebelum kunci benar-benar bekerja: membuat pasangan kunci, mengamankan kunci privatnya, dan mendaftarkan kunci publiknya ke platform. Itulah seluruh isi chapter berikutnya.