Menyiapkan GitLab

GitHub unggul lewat komunitas, tetapi tidak semua tim mencarinya: tim produk kerap ingin pipeline pengujian menyatu di platform, dan perusahaan dengan data sensitif kadang harus memasang semuanya di server sendiri — dua kebutuhan yang diisi GitLab dengan CI/CD bawaan dan opsi self-hosted. Kabar baiknya bagi kita: seluruh operasi Git tetap sama persis, dan alur setup-nya pun nyaris identik dengan GitHub. Chapter ini menyiapkan akun GitLab dan repository pertama dari nol, menghubungkan repository lokal (diuji nyata di sandbox dengan bare repo sebagai padanan), lalu memetakan perbedaan kosakata — mulai dari visibilitas internal yang tidak dimiliki GitHub sampai merge request yang bukan pull request.

Membuat Akun #

Layanan cloud-nya beralamat di gitlab.com: tombol Register membuka formulir email, nama pengguna, dan kata sandi, lalu verifikasi email menuntaskan pendaftaran. Nama pengguna mengikuti prinsip yang sama seperti di GitHub — menjadi bagian alamat repository kita (gitlab.com/budi-santoso/lacak-tugas), jadi buat singkat dan layak tampil di profil profesional. Kalau tim memakai GitLab self-hosted, alamatnya menyusul dari administrator (misalnya git.company.example.com) dan formulirnya serupa; pilihan edisi Community atau Enterprise beserta konsekuensinya sudah kita bahas di Mengenal GitLab . Aktivasi autentikasi dua faktor sama wajibnya: Settings → Account → Two-factor Authentication. Penyimpanan recovery code-nya juga sama penting.

Repository Pertama #

Dari tombol New project pilih Create blank project. Formulirnya lebih panjang dari GitHub karena GitLab memisahkan project name dari path — nama boleh berhuruf besar dan berspasi, sedangkan path otomatis dijadikan huruf kecil berhubung; untuk repository kita, samakan keduanya dengan nama prediktabel seperti lacak-tugas. Isian penting lainnya:

Tingkat visibilitasnya layak dibedah karena inilah perbedaan struktural pertama:

Tingkat Internal bersinar justru pada GitLab self-hosted: seluruh karyawan yang punya akun di instance perusahaan otomatis bisa melihat project internal tanpa diundang satu per satu, sementara dunia luar tetap terkunci. Di gitlab.com, “instance” berarti seluruh pengguna terdaftar gitlab.com — lebih terbuka daripada kedengarannya, jadi baca ulang sebelum memilih.

Menghubungkan Repository Lokal #

Sandbox mensimulasikan GitLab dengan bare repo gitlab-demo.git sebagai padanan project baru yang kosong; di mesin kita, ganti jalur relatifnya dengan URL asli — https://gitlab.com/budi-santoso/lacak-tugas.git untuk HTTPS atau [email protected]:budi-santoso/lacak-tugas.git untuk SSH:

git remote add origin ../gitlab-demo.git
git push -u origin main

Output yang Dihasilkan:

To ../gitlab-demo.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

Push pertama ini mengirim satu commit yang memuat dua berkas (README.md dan .gitattributes) sekaligus mengikat main lokal ke origin/main. Bahwa remote benar-benar menerima riwayatnya bisa diperiksa langsung:

git ls-remote origin

Output yang Dihasilkan:

a13b9077741d7e7d20d93023ee1599b784aad58a        HEAD
a13b9077741d7e7d20d93023ee1599b784aad58a        refs/heads/main

Dua hash yang identik menunjukkan HEAD remote mengarah ke branch main — commit teratas kita. Hash akan berbeda di mesin kita karena isinya dan waktunya berbeda.

Autentikasi #

GitLab menerima jalur yang sama dengan GitHub. Kunci SSH didaftarkan lewat avatar → Edit profile → SSH Keys — tempel seluruh baris ~/.ssh/id_ed25519.pub seperti pada Menyiapkan SSH ; panduan resminya ada di dokumentasi SSH GitLab . Untuk jalur HTTPS, personal access token dibuat dari avatar → Edit profile → Access Tokens dengan cakupan minimal write_repository; perawatan token — masa berlaku dan pencabutan — mengikuti materi Personal Access Token , dan detail bidangnya di dokumentasi PAT GitLab .

Pipeline Pertama #

Inilah fitur yang paling membedakan hidup sehari-hari: pipeline hidup dalam satu berkas .gitlab-ci.yml di akar repository, tanpa layanan eksternal. Contoh teksnya untuk latihan — tidak kita jalankan di sandbox karena eksekusinya terjadi di mesin runner milik GitLab:

stages:
  - uji

uji-gegas:
  stage: uji
  script:
    - echo "pipeline pertama"
    - git --version

Cara membacanya: stages mendefinisikan tahap pipeline — di sini satu tahap bernama uji — dan uji-gegas adalah sebuah job: pekerjaan bernama yang dijalankan runner dengan perintah pada bagian script. Setiap git push membuat GitLab membaca ulang berkas ini dan menjalankan pipeline-nya; statusnya — lulus, gagal, atau berjalan — terlihat langsung di halaman project. Konsep otomasi ini adalah kelanjutan dari Git dalam CI/CD , dan contoh pertamanya sudah kita bedah di Mengenal GitLab .

Perbedaan Kosakata #

Git aslinya sama persis; yang berbeda adalah nama-nama fitur di antarmuka. Peta terjemahannya:

Merge request tetap menuntut branch, commit, dan resolusi konflik — keterampilan yang sudah kita latih di alur pull request — jadi perbedaannya murni kosakata. Perbandingan mendalam kedua platform, termasuk model lisensinya, tersimpan di Mengenal GitLab ; dokumentasi lengkap fitur per fitur ada di docs.gitlab.com .

Dua platform utama kini siap dipakai, dan perangkat kita lengkap dari terminal sampai tanda tangan. Persoalan berikutnya berpindah sifatnya: setelah Course ini selesai, ke mana kita mencari jawaban ketika Git menunjukkan perilaku yang belum pernah kita lihat? Jawabannya dimulai dari peta dokumentasi resmi. Lanjut ke Dokumentasi Git .