Belajar PowerShell - PowerShell & Git

#Pendahuluan

Di episode 24 kalian menulis test yang membuktikan skrip bekerja. Tapi ada satu fakta yang melemahkan semua itu: selama skrip dan test hanya hidup di satu mesin, mereka tidak punya memori. Perbaikan yang menyelamatkan produksi bisa hilang tertimpa file baru, dua anggota tim bisa mengedit file yang sama dan menabrak satu sama lain, dan tidak ada catatan siapa mengubah apa dan kapan.

Git menjawab semua itu. Episode ini membahas cara git bekerja sama dengan PowerShell: menggunakan git dari dalam konsol, menghidupkan prompt dengan Posh-Git, praktik commit dan branching yang sehat, kolaborasi lewat GitHub dan GitLab, menerbitkan modul ke PowerShell Gallery, hingga menjadikan git sebagai tulang punggung pipeline CI/CD yang menjalankan test otomatis pada setiap commit.

#Git dari dalam PowerShell

Git adalah alat baris perintah lintas platform yang berjalan identik di PowerShell dan shell lain. Tidak ada sintaks PowerShell khusus untuk git — yang kalian perlukan hanyalah perintah git biasa di dalam konsol:

git --version
git init
git add .
git commit -m "feat: tambah fungsi backup ke produksi"
git status
git log --oneline

Yang membuat kombinasi ini kuat: PowerShell mengembalikan output git sebagai teks biasa, sehingga kalian bisa memprosesnya — misalnya mengekstrak nama cabang aktif untuk dipakai dalam nama file backup:

$branch = git rev-parse --abbrev-ref HEAD
$backupName = "backup-$branch.zip"
Write-Output "Nama file backup: $backupName"

Pola "jalankan git, tangkap output, olah sebagai data" membuka pintu untuk skrip yang sadar-git: tagging otomatis, nama artefak berdasarkan commit, atau laporan deploy yang mencantumkan hash commit.

#Posh-Git: Prompt yang Informatif

Git bawaan tidak memberi tahu kondisi repositori saat kalian mengetik. Posh-Git mengubahnya: prompt kalian menampilkan cabang aktif dan status perubahan secara real-time. Instalasi:

Install-Module -Name posh-git -Scope CurrentUser -Force
Import-Module posh-git
Add-PoshGitToProfile

Setelah dimuat, prompt menampilkan misalnya C:\scripts [main +0 ~1 -0]. Artinya: cabang main, satu file diubah, belum ada file baru atau terhapus. Status ini mencegah kesalahan klasik: commit tanpa sadar melewatkan file, atau berada di cabang yang salah.

Prompt bisa disesuaikan lewat $GitPromptSettings — misalnya mengubah warna dan teks yang mengelilingi status cabang:

$GitPromptSettings.DefaultPromptBeforeSuffixText.Text = "["
$GitPromptSettings.DefaultPromptBeforeSuffixText.ForegroundColor = "DarkGray"
$GitPromptSettings.BranchForegroundColor = "Cyan"
$GitPromptSettings.DefaultPromptAfterSuffixText.Text = "]"

Simpan kustomisasi di profil kalian (misalnya $PROFILE) agar berlaku setiap sesi. Prompt yang informatif membuat status repositori selalu terlihat — tanpa perlu mengetik git status setiap lima menit.

#Version Control untuk Skrip

#Script Versioning

Skrip yang dikontrol git mendapat versi otomatis: setiap commit adalah titik pemulihan. Ketika perbaikan justru merusak sesuatu, git revert mengembalikan kondisi sebelumnya dalam satu perintah. Tambahkan pula nomor versi yang terlihat di dalam skrip itu sendiri — blok komentar di header yang menyebutkan versi dan tanggal, dan perbesar angka versi setiap ada perubahan perilaku, bukan sekadar perubahan kosmetik.

#Praktik Commit yang Sehat

Commit adalah unit cerita perubahan. Dua kebiasaan yang paling berdampak:

• Commit atomik — satu commit, satu tujuan. Perbaikan bug terpisah dari penambahan fitur, sehingga sejarah (dan git bisect saat mencari asal masalah) tetap tajam.
• Pesan commit yang jelas — pakai konvensi yang sudah kalian kenal dari CI/CD series ini: feat:, fix:, chore:. Kalimat pendek yang menjelaskan mengapa, bukan daftar file yang diubah.

Contoh perbedaan:

git commit -m "update"
git commit -m "fix: perbaiki handler file hilang pada resume backup"

Pesan pertama tidak menceritakan apa pun; pesan kedua cukup untuk memahami isi tanpa membuka diff. Enam bulan kemudian, kalian akan berterima kasih pada diri sendiri.

#Branching dan Kolaborasi

Branching memungkinkan beberapa orang bekerja tanpa saling mengganggu. Pola yang umum:

git checkout -b feature/konversi-satuan
git add .
git commit -m "feat: tambah fungsi konversi satuan"
git push -u origin feature/konversi-satuan
 
git checkout main
git pull
git merge feature/konversi-satuan

Aturan praktis yang baik: cabang utama selalu dalam keadaan bisa dirilis. Pekerjaan eksperimen terjadi di cabang fitur, dan perubahan masuk ke cabang utama melalui pull request (GitHub) atau merge request (GitLab) yang direview rekan kerja. Review menangkap masalah sebelum masuk cabang utama — dan karena test Pester dari episode 24 dipasang di pipeline, review manusia hanya tinggal memeriksa logika, bukan menebak apakah kode akan berjalan.

#GitHub dan GitLab: Tempat Repositori Hidup

Memindahkan repositori ke GitHub atau GitLab memberi tiga hal yang tidak dimiliki repositori lokal:

• Backup terdistribusi — salinan repositori tidak lagi bergantung pada satu mesin.
• Kolaborasi terstruktur — pull request, code review, dan diskusi di setiap baris perubahan.
• Otomatisasi — setiap push dapat memicu pipeline: linting, test, build, dan deploy.

Kolaborasi bukan soal siapa yang paling cepat menulis kode, melainkan seberapa baik tim meninjau dan menggabungkan perubahan. Repositori dengan history yang bersih dan review yang ketat adalah aset — bukan sekadar tempat menyimpan file.

#Menerbitkan Modul ke PowerShell Gallery

Ketika skrip kalian matang dan reusable, bagikan sebagai modul melalui PowerShell Gallery — repositori publik tempat modul PowerShell didistribusikan. Setiap modul butuh manifest yang berisi nama, versi, dan deskripsi:

New-ModuleManifest -Path ".\MyModule\MyModule.psd1" `
    -RootModule "MyModule.psm1" `
    -ModuleVersion "1.0.0" `
    -Author "Arman Dwi Pangestu" `
    -Description "Fungsi konversi satuan untuk skrip backup"
 
Publish-Module -Path ".\MyModule" `
    -Repository PSGallery `
    -NuGetApiKey $apiKey

Publish-Module mengunggah modul ke Gallery. Kunci API — rahasia yang digunakan Gallery untuk memastikan hanya pemilik yang bisa menerbitkan — harus disimpan di secret store atau environment variable, bukan ditulis di skrip (prinsip yang sama dengan kredensial di episode 22). Modul yang diterbitkan bisa diinstal siapa pun dengan Install-Module, dan versinya mengikuti semantik yang sudah ditetapkan di manifest.

#Pipeline CI/CD dan Pengujian Otomatis

Git bukan hanya penyimpanan — ia adalah pemicu. Setiap push ke GitHub dapat menjalankan pipeline yang melakukan linting, menjalankan test Pester, dan membangun modul. Dua contoh yang setara:

name: Test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Jalankan test Pester
        shell: pwsh
        run: Invoke-Pester -Path "./tests" -CI

test:
  stage: test
  image: mcr.microsoft.com/powershell
  script:
    - Invoke-Pester -Path "./tests" -CI

Logika keduanya sama: cabang utama tidak bisa menerima perubahan yang testnya gagal. Ini menutup lingkaran tiga episode terakhir — episode 22 menulis skrip yang baik, episode 24 membuktikannya dengan test, dan episode 25 memastikan pembuktian itu berjalan otomatis setiap kali kode berubah.

#Penutup

Di episode 25 ini kalian telah menyatukan PowerShell dan git: menjalankan git dari dalam konsol dan mengolah outputnya sebagai data; membuat prompt informatif dengan Posh-Git dan mengkustomisasinya lewat $GitPromptSettings; mempraktikkan commit atomik dengan pesan konvensional; mengelola kolaborasi dengan branching, pull request, dan code review; menerbitkan modul ke PowerShell Gallery dengan Publish-Module; serta menghubungkan semuanya ke pipeline CI/CD yang menjalankan test otomatis di setiap commit.

Poin kunci yang harus kalian bawa:

• Commit adalah titik pemulihan — commit atomik dengan pesan yang jelas.
• Cabang utama selalu dalam keadaan siap rilis; fitur hidup di cabangnya sendiri.
• $GitPromptSettings membuat status repositori selalu terlihat.
• Secret penerbitan modul tidak pernah ditulis di kode.
• Satu gerbang CI yang hijau lebih baik daripada lima yang diabaikan.

Skrip kalian kini memiliki memori, sejarah, dan jaring pengaman. Tapi masih ada pertanyaan yang lebih besar: bagaimana memastikan seluruh mesin berada dalam kondisi yang diinginkan, bukan hanya skrip? Di episode 26 selanjutnya kita membahas Configuration Management (DSC) — mendeskripsikan keadaan target mesin sebagai kode, menegakkan konfigurasi, dan mendeteksi penyimpangan. Sampai jumpa!