Menghubungkan ke Repository Git dengan Banyak Identitas

Bekerja dengan lebih dari satu akun Git dalam satu mesin adalah hal yang umum bagi seorang engineer — ada akun pribadi untuk open source dan side project, akun kantor untuk pekerjaan utama, dan kadang akun organisasi atau klien untuk project tertentu. Kalau tidak diatur dengan benar, situasi ini memunculkan masalah klasik: commit memakai email yang salah, push ke repository dengan akun yang tidak seharusnya, atau error autentikasi SSH yang membingungkan karena Git mencoba key yang salah. Artikel ini membahas cara yang benar, bersih, dan scalable untuk menghubungkan banyak repository Git dengan identitas berbeda dalam satu komputer.

Prinsip Dasar

Sumber kebingungan terbesar dalam mengelola banyak identitas Git adalah mencampurkan dua hal yang sebenarnya berbeda: autentikasi ke Git server dan identitas commit. Autentikasi ke Git server — yaitu proses yang menentukan apakah kamu punya hak akses ke sebuah repository — diatur lewat SSH key. Identitas commit — yaitu nama dan email yang tercatat di setiap commit yang kamu buat — diatur lewat user.name dan user.email di konfigurasi Git.

Keduanya harus dipisahkan secara eksplisit. SSH key menentukan siapa yang boleh masuk, sementara user.name dan user.email menentukan atas nama siapa commit itu dibuat. Salah satu sumber bug paling umum adalah mengasumsikan bahwa SSH key yang benar otomatis berarti identitas commit juga benar — padahal keduanya dikonfigurasi secara terpisah dan tidak saling memengaruhi.

Kebingungan ini sering muncul karena di permukaan, keduanya terasa seperti “satu hal yang sama” — toh keduanya berhubungan dengan akun Git yang sama. Tapi secara teknis, SSH key bekerja di level transport layer saat Git berkomunikasi dengan server ([email protected]), sedangan user.name dan user.email hanya metadata teks biasa yang ditulis ke dalam objek commit itu sendiri. Kamu bisa saja terautentikasi dengan benar lewat SSH key akun kantor, tapi tetap membuat commit dengan email pribadi — Git tidak akan memvalidasi atau mencocokkan keduanya secara otomatis.

flowchart TD
    A[Git Operation] --> B{Push / Pull / Clone}
    B --> C[SSH Key: Autentikasi ke server]
    A --> D{Commit}
    D --> E[user.name + user.email: Identitas commit]
    C -.->|Tidak terhubung otomatis| E

Buat SSH Key Terpisah untuk Setiap Identitas

Jangan pernah memakai satu SSH key yang sama untuk semua akun. Satu key yang dipakai di banyak akun membuat audit jadi sulit — kalau key tersebut bocor, kamu harus mencabut akses di semua akun sekaligus, bukan hanya satu. Buat SSH key terpisah untuk setiap identitas:

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_personal
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_work

Flag -t ed25519 memilih algoritma Ed25519, yang lebih cepat dan lebih aman dibanding RSA untuk ukuran key yang sama. Flag -C menambahkan komentar (biasanya email) untuk memudahkan identifikasi key saat melihat daftar key yang terdaftar di akun Git. Flag -f menentukan path dan nama file output, sehingga kedua key tidak saling menimpa id_ed25519 default.

Setelah key dibuat, tambahkan public key (.pub) ke akun Git yang sesuai — GitHub, GitLab, atau Bitbucket biasanya punya menu khusus “SSH Keys” di halaman setting akun.

Private key (file tanpa ekstensi .pub, misalnya id_ed25519_personal) tidak boleh dibagikan ke siapa pun dan tidak boleh ter-commit ke repository manapun. Hanya public key (id_ed25519_personal.pub) yang aman dibagikan dan didaftarkan ke server Git.

Konfigurasi ~/.ssh/config

Setelah dua SSH key dibuat, SSH masih belum tahu key mana yang harus dipakai untuk koneksi ke github.com yang mana — karena secara default semua key akan dicoba satu per satu. Untuk mengatasi ini, gunakan host alias di file ~/.ssh/config:

# Akun pribadi
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal
  IdentitiesOnly yes

# Akun kerja
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

Setiap blok Host mendefinisikan alias baru. HostName menentukan domain sebenarnya yang dituju (dalam kasus ini, keduanya tetap github.com), sementara Host di baris pertama adalah nama alias yang kamu pakai sendiri saat menjalankan perintah Git — bukan nama domain yang harus cocok dengan apapun di sisi server. IdentityFile menunjuk ke private key yang sesuai, dan IdentitiesOnly yes memberitahu SSH untuk hanya mencoba key yang disebutkan secara eksplisit, bukan mencoba semua key yang ada di ~/.ssh/.

Dengan konfigurasi ini, SSH tidak akan menebak-nebak key mana yang dipakai — setiap alias terhubung secara eksplisit ke satu key tertentu.

Gunakan Host Alias di Git Remote

Konfigurasi SSH di atas baru benar-benar berfungsi kalau remote URL repository menggunakan host alias, bukan domain asli github.com secara langsung. Ini adalah langkah yang paling sering terlewat — banyak yang sudah membuat SSH key dan konfigurasi ~/.ssh/config dengan benar, tapi tetap memakai URL remote default yang mengarah ke github.com tanpa alias.

Clone Repository

# Repo pribadi
git clone git@github-personal:username/repo-pribadi.git

# Repo kerja
git clone git@github-work:company/repo-kerja.git

Perhatikan bagian setelah git@ — di sini host alias (github-personal atau github-work) menggantikan github.com. SSH akan membaca alias ini, mencocokkannya dengan konfigurasi di ~/.ssh/config, lalu otomatis memakai IdentityFile yang sesuai tanpa perlu menentukan key secara manual setiap kali.

Mengubah Remote yang Sudah Ada

Untuk repository yang sudah ada dan masih memakai URL default, ubah remote-nya dengan:

git remote set-url origin git@github-work:company/repo-kerja.git

Setelah remote diubah, setiap operasi push, pull, atau fetch di repository tersebut akan otomatis memakai SSH key yang terhubung ke alias github-work.

Atur Identitas Commit Per Repository

SSH key hanya mengatur hak akses — siapa yang boleh push ke mana — bukan identitas yang tercatat di commit. Identitas commit harus dikonfigurasi terpisah, dan idealnya dilakukan per repository, bukan secara global. Masuk ke masing-masing repository, lalu jalankan:

git config user.name "Nama Pribadi"
git config user.email "[email protected]"

Untuk repository kerja, masuk ke direktorinya dan jalankan konfigurasi yang berbeda:

git config user.name "Nama Kantor"
git config user.email "[email protected]"

Tanpa flag --global, perintah git config di atas hanya berlaku untuk repository yang sedang aktif (tersimpan di file .git/config repository tersebut), bukan untuk seluruh repository di mesin. Ini adalah kuncinya — setiap repository punya identitas commit-nya sendiri, terlepas dari konfigurasi global apa pun yang ada.

Hindari mengandalkan git config --global user.email kalau kamu sering berpindah konteks kerja. Konfigurasi global hanya jadi fallback yang dipakai ketika sebuah repository tidak punya konfigurasi lokalnya sendiri — kalau lupa mengatur identitas lokal di satu repository, commit akan otomatis memakai identitas global, yang sering kali bukan identitas yang seharusnya.

Otomatisasi dengan includeIf Berdasarkan Direktori

Mengatur user.name dan user.email secara manual di setiap repository baru bisa jadi merepotkan, terutama kalau kamu sering clone repository baru untuk satu konteks kerja tertentu. Git menyediakan includeIf yang memungkinkan konfigurasi otomatis diterapkan berdasarkan lokasi direktori repository — pendekatan ini sangat berguna kalau kamu konsisten menaruh semua repository kerja di satu folder, dan repository pribadi di folder lain.

Pertama, buat file konfigurasi terpisah untuk masing-masing konteks:

# ~/.gitconfig-personal
[user]
  name = Nama Pribadi
  email = [email protected]

# ~/.gitconfig-work
[user]
  name = Nama Kantor
  email = [email protected]

Lalu, di ~/.gitconfig utama, tambahkan blok includeIf yang mengarah ke masing-masing file berdasarkan path direktori:

# ~/.gitconfig
[includeIf "gitdir:~/projects/personal/"]
  path = ~/.gitconfig-personal

[includeIf "gitdir:~/projects/work/"]
  path = ~/.gitconfig-work

Dengan konfigurasi ini, setiap repository yang berada di dalam ~/projects/personal/ otomatis memakai identitas dari ~/.gitconfig-personal, dan repository di ~/projects/work/ otomatis memakai identitas dari ~/.gitconfig-work — tanpa perlu menjalankan git config user.email secara manual setiap kali clone repository baru di direktori tersebut.

Pastikan path di gitdir: diakhiri dengan / agar Git mencocokkan seluruh repository di dalam direktori tersebut, bukan hanya satu path yang persis sama. Struktur folder yang konsisten — misalnya semua repo kerja selalu di bawah satu folder tertentu — adalah prasyarat agar pendekatan ini berfungsi dengan baik.

Kesalahan Umum yang Harus Dihindari

✗ Satu SSH key dipakai untuk semua akun
  -- menyulitkan audit, berisiko keamanan, rawan salah akses

✗ Mengandalkan git config --global user.email sebagai satu-satunya sumber identitas
  -- penyebab utama commit dengan identitas yang salah

✗ Tidak memakai IdentitiesOnly yes di SSH config
  -- SSH mencoba semua key yang ada, memicu error Permission denied (publickey)

Ketiga kesalahan ini saling berkaitan. Satu SSH key untuk semua akun biasanya muncul karena proses setup awal yang terburu-buru — lebih cepat memakai key yang sudah ada daripada membuat key baru untuk setiap akun. Mengandalkan user.email global muncul karena terasa lebih praktis di awal, padahal justru membuat kesalahan identitas commit jadi mudah terjadi begitu kamu mulai bekerja di lebih dari satu repository dengan konteks berbeda. Sementara tanpa IdentitiesOnly yes, SSH akan mencoba seluruh key yang ada di ~/.ssh/ secara berurutan sampai salah satu cocok atau server menolak semuanya — proses ini sering menghasilkan error Permission denied (publickey) yang membingungkan, padahal key yang benar sebenarnya ada, hanya saja tidak dicoba lebih dulu atau urutan percobaannya salah.

Pola yang sama juga berlaku untuk kebiasaan menunda setup yang benar. Banyak engineer baru menyadari pentingnya memisahkan identitas setelah commit salah akun sudah ter-push ke repository publik atau repository kerja — momen yang biasanya memalukan dan kadang sulit diperbaiki tanpa mengubah riwayat commit. Menginvestasikan waktu sepuluh menit di awal untuk setup SSH key, host alias, dan identitas commit per repository jauh lebih murah dibanding memperbaiki riwayat commit yang sudah salah identitas, apalagi kalau commit tersebut sudah dibagikan ke rekan tim lain melalui pull atau fetch.

Verifikasi Setup

Setelah seluruh konfigurasi di atas selesai, lakukan verifikasi sebelum benar-benar mulai bekerja. Cek koneksi SSH untuk masing-masing alias:

ssh -T github-personal
ssh -T github-work

Flag -T menonaktifkan alokasi pseudo-terminal, karena tujuannya hanya menguji autentikasi, bukan membuka sesi interaktif. Kalau berhasil, GitHub (atau platform Git lainnya) akan merespons dengan pesan yang mengonfirmasi username yang terautentikasi untuk masing-masing alias — biasanya berupa pesan singkat seperti “Hi username! You’ve successfully authenticated” diikuti catatan bahwa GitHub tidak menyediakan shell akses interaktif.

Cek juga identitas commit di repository yang sedang aktif:

git config user.name
git config user.email

Jalankan kedua perintah ini di setiap repository yang relevan untuk memastikan user.name dan user.email sudah sesuai dengan identitas yang seharusnya dipakai di repository tersebut. Kalau hasilnya kosong, berarti repository tersebut belum punya konfigurasi lokal dan akan jatuh kembali ke konfigurasi global — yang berarti perlu diatur ulang sesuai konteks repository tersebut.

Sebagai langkah verifikasi tambahan, kamu juga bisa memeriksa commit terakhir untuk memastikan identitas yang tercatat benar, sebelum sempat melakukan push:

git log -1 --format="%an <%ae>"

Perintah ini menampilkan nama dan email dari commit paling terakhir di branch yang sedang aktif. Kalau hasilnya tidak sesuai dengan identitas yang diharapkan, kamu masih bisa memperbaikinya dengan git commit --amend --author="Nama Benar <[email protected]>" sebelum commit tersebut di-push ke remote.

Kalau semua benar, Git akan bekerja tanpa konflik identitas — push akan masuk dengan akun yang tepat, dan commit akan tercatat dengan nama serta email yang sesuai konteks kerja.

Ringkasan

• SSH key dan identitas commit adalah dua hal berbeda — SSH key mengatur hak akses, user.name/user.email mengatur identitas commit.
• Buat SSH key terpisah untuk setiap akun, jangan pernah berbagi satu key untuk semua identitas.
• Gunakan host alias di ~/.ssh/config dengan IdentitiesOnly yes agar SSH tidak menebak-nebak key yang harus dipakai.
• Remote URL harus memakai host alias, bukan domain default — ini langkah yang paling sering terlewat.
• Atur user.name dan user.email per repository (tanpa --global), jangan mengandalkan konfigurasi global sebagai satu-satunya sumber identitas.
• Verifikasi setup dengan ssh -T <alias> untuk autentikasi dan git config user.email untuk identitas commit, sebelum mulai bekerja.
• Setup yang benar sejak awal menghilangkan masalah klasik commit salah akun dan error Permission denied (publickey).