Git yang Independen dari Platform

Sebelas chapter memutari tiga platform: akun, URL, tombol web, format token. Menutup section ini perlu satu pemeriksaan yang jarang dilakukan orang: dari semua yang kita pelajari, mana yang sebenarnya milik Git, dan mana yang hanya milik satu layanan? Pertanyaannya bukan akademik. Karier berpindah perusahaan dengan platform berbeda, proyek open source menyebar di mana-mana, dan tim kadang harus memindahkan atau memasang server sendiri. Pemisahan yang jelas membuat perpindahan itu jadi urusan kosakata — bukan kuliah ulang. Chapter penutup ini memetakan wilayahnya, lalu melatih satu perintah migrasi yang nyata.

Keterampilan yang Portabel #

Daftar berikut membaca section-section yang sudah kita lalui sebagai bekal bawaan — keterampilan yang bekerja identik di GitHub, GitLab, Bitbucket, server kantor, bahkan folder toko-pusat.git di sandbox:

Keterampilan	Dipelajari di	Dibawa ke mana saja
staging area dan commit	Dasar Repository	setiap repository Git, dengan atau tanpa remote
branch dan merge	Branch dan Merging	konflik dan resolusinya identik di semua platform
rebase dan pengeditan riwayat	Rebasing dan Riwayat Lanjutan	penulisan ulang riwayat terjadi di lokal, bukan di server
tag dan kemasan rilis	Tags dan Releases	`git tag` dan `git archive` bekerja di mana pun
stash dan reflog	Pemulihan dan Recovery	penyangga dan jaring pengaman murni lokal
remote, fetch, push	Remote Repository	satu kosakata untuk semua alamat

Alasannya struktural: platform tidak menyimpan versi khusus dari riwayat kita. Seluruh section ini membuktikannya diam-diam — setiap “server” di sandbox kita adalah bare repo biasa, dan clone dari GitHub, GitLab, maupun folder sebelah menghasilkan repository yang sama bentuknya. Platform hanya berbicara protokol transfer (HTTPS dan SSH) di atas objek-objek Git yang sudah kita kenal; sisanya adalah lapisan web untuk kolaborasi.

Fitur Platform-Locked dan Padanannya #

Lapisan web itu bagian yang tidak portabel — tetapi konsepnya saling bermuatan, dan padanannya mudah dipetakan:

Kemampuan	GitHub	GitLab	Bitbucket
Usulan penggabungan	pull request	merge request	pull request
Pelacak pekerjaan	issues	issues	issues
CI/CD	Actions — `.github/workflows/`	GitLab CI — `.gitlab-ci.yml`	Pipelines — `bitbucket-pipelines.yml`
Kemasan rilis	Releases	Releases	Downloads
Halaman statis	Pages	Pages	— (lewat integrasi pihak ketiga)

Perhatikan pola yang berulang: padanan CI/CD di ketiganya adalah berkas YAML di dalam repository — formatnya berbeda, tetapi tempat hidupnya sama, dan perintah yang dijalankan mesin-mesin itu adalah perintah Git yang sama seperti yang kita ketik (materi Git dalam CI/CD ). Begitu pula pull request dan merge request: beda nama, sama mekanisme — branch, diff, review, merge, seperti dilatih di Kolaborasi Tim . Berpindah platform berarti membaca ulang formulirnya, bukan belajar ulang Git-nya.

Migrasi Antar Platform #

Sisi riwayat dari migrasi adalah urusan satu perintah — dan kita sudah menguasainya. Repository lokal berikut terdaftar di GitHub, lalu dipindahkan ke GitLab; yang berubah hanya baris alamat di buku alamatnya:

bash

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

Output yang Dihasilkan:

text

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

bash

git remote set-url origin https://gitlab.com/budi/toko-buku.git
git remote -v

Output yang Dihasilkan:

text

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

bash

git remote get-url origin

Output yang Dihasilkan:

text

https://gitlab.com/budi/toko-buku.git

set-url sudah dibedah tuntas di SSH vs HTTPS dan Mengganti Remote URL — perintah yang sama, arahnya kini antar-platform. Untuk migrasi yang harus memindahkan seluruh branch dan tag sekaligus, resepnya dua perintah: git clone --mirror <url-lama> membuat salinan lengkap seluruh ref, lalu git push --mirror <url-baru> menumpahkannya — teknik yang juga menjadi resep cadangan di Backup Repository . Rincian kedua perintah itu terdokumentasi di dokumentasi git remote .

Self-Hosted: Server Sendiri #

Ujung independensi adalah memasang platform sendiri. Dua nama yang paling sering dipakai: GitLab CE — edisi Community dari model open-core yang dibedah di Mengenal GitLab , lengkap dengan merge request dan pipeline; serta Gitea yang ringan dan mudah dipasang di satu server kecil, dengan proyek Forgejo lahir sebagai fork-nya pada 2022 dan berkembang berdampingan. Keduanya berbicara protokol Git standar: seluruh perintah dari section ini — clone, push, set-url, hingga ssh -T — bekerja tanpa perubahan.

Motivasinya biasanya bukan teknis, melainkan kepemilikan data: kode dan riwayat internal yang tidak boleh keluar dari jaringan kantor, atau biaya langganan yang tidak sebanding untuk tim kecil. Konsekuensinya juga jujur disebut: server sendiri berarti urus sendiri — cadangan, pembaruan, dan ketersediaan menjadi tugas kita, bukan tim platform.

Kuasi Git, Semua Platform Terbuka #

Peta akhirnya sederhana. Fondasi — commit, branch, merge, tag, remote — milik Git dan berlaku di mana pun. Lapisan kolaborasi — pull request, issues, CI — milik platform, tetapi padanannya mudah dipelajari karena mekanismenya menumpuk pada fondasi yang sama. Itulah sebabnya section ini sengaja menempatkan Git lebih dulu dan tombol web kemudian: kuasi Git-nya, semua platform tinggal dipilih; kuasi tombolnya saja, kita terikat seumur hidup pada satu layanan.

Dengan akses tersebar di banyak platform, satu urusan baru muncul dan menjadi agenda section berikutnya: kredensial kita kini berupa kunci SSH, token terbatas, dan passphrase — banyak rahasia yang perlu disimpan, diputar, dan diamankan dengan benar. Kita bedah semuanya di Keamanan dan Akses .