Kolaborasi: Remote,
PR & Proteksi

Menghubungkan repo lokal dengan workspace tim

Sampai sini Git masih sepenuhnya lokal, hidup di folder .git di laptopmu sendiri. Remote adalah pintu keluarnya ke tim.

Sebuah remote hanyalah repo Git lain yang bisa kamu ajak bertukar commit lewat jaringan, entah itu GitHub, GitLab, atau server internal kantor. Repo lokalmu menyimpan daftar remote beserta URL-nya, dan menurut konvensi remote utama bernama origin. Lihat daftarnya dengan git remote -v (flag -v menampilkan URL fetch dan push). Yang penting dipahami, Git itu terdistribusi: setiap klona membawa salinan riwayat penuh, dan origin bukan “pusat ajaib”, ia cuma satu repo yang kebetulan disepakati tim sebagai titik temu bersama.

Saat kamu menghubungkan ke remote, Git membuat remote-tracking branch seperti origin/main. Ini adalah cermin lokal dari posisi main di remote pada saat terakhir kamu berkomunikasi dengannya. Penting: origin/main tidak diperbarui sendiri, ia hanya bergerak ketika kamu menjalankan fetch atau pull. Jadi main (branch kerjamu) dan origin/main (cermin remote) bisa berbeda, dan justru selisih itulah yang ingin kamu pahami sebelum menggabungkan.

flowchart LR
  subgraph Lokal["Repo lokal"]
    L["main"]
    OM["origin/main (cermin)"]
  end
  subgraph Remote["origin (GitHub)"]
    R["main"]
  end
  R -- "git fetch" --> OM
  L -- "git push" --> R
  OM -. "merge / rebase" .-> L

Fetch lalu push. Fetch memperbarui cermin origin/main, push mengirim commit lokal ke remote. Penggabungan ke main lokal adalah langkah terpisah yang kamu kendalikan.

Di sinilah git fetch dan git pull berbeda secara fundamental.

Untuk push pertama kali sebuah branch, gunakan git push -u origin main. Flag -u (singkatan --set-upstream) menetapkan upstream: relasi tetap antara branch lokalmu dan origin/main. Setelah upstream tersetel, git push, git pull, dan git status tahu lawan bicaranya tanpa kamu sebutkan lagi, dan git status bahkan akan memberitahu “your branch is ahead of origin/main by 2 commits”.

TerminalSalin
# hubungkan repo lokal ke remote dan dorong main pertama kali
git remote add origin git@github.com:kamu/skincare-backend.git
git remote -v
git push -u origin main

# lihat update tim tanpa mengubah branch aktif, lalu bandingkan
git fetch origin
git log --oneline main..origin/main      # commit yang ada di remote, belum di lokal
git status                                # ahead/behind terhadap upstream

Lalu ada momen yang pasti kamu temui: push ditolak dengan pesan ! [rejected] ... (non-fast-forward). Artinya remote sudah punya commit yang belum ada di repo lokalmu (rekan setim mendorong duluan), sehingga push-mu akan menghapus jejak mereka. Git menolak demi keselamatan. Penyelesaiannya bukan memaksa, melainkan menarik dulu pekerjaan mereka, menumpuk commit-mu di atasnya, baru mendorong lagi.

Tempat review, CI, dan keputusan merge

Mendorong branch ke remote baru setengah cerita, pull request adalah tempat branch itu ditinjau, diuji, dan diputuskan layak masuk main.

Pull request (PR di GitHub) atau merge request (MR di GitLab) adalah usulan formal untuk menggabungkan branch-mu ke branch target. Ia jauh lebih dari tombol merge: PR menyatukan judul yang jelas, deskripsi yang menjelaskan kenapa perubahan ini ada, reviewer yang ditunjuk, status check dari CI, dan keputusan approval. Inti reviewnya berbasis diff, jadi reviewer membaca selisih baris demi baris, bukan menjalankan seluruh aplikasi di kepala mereka. Karena itulah PR menjadi titik kendali mutu sekaligus arsip keputusan: enam bulan kemudian, PR-lah yang menjelaskan mengapa PriceRupiah diubah menjadi int64.

flowchart LR
  B["branch feature"] --> P["git push"]
  P --> PR["buka Pull Request"]
  PR --> RV["review + CI checks"]
  RV -->|request changes| FIX["push perbaikan"]
  FIX --> RV
  RV -->|approve + hijau| MG["merge ke main"]
  MG --> DP["deploy"]

Siklus pull request. Branch didorong, PR dibuka, review dan CI berputar sampai hijau dan disetujui, baru merge lalu deploy.

Alur code review yang sehat punya ritme khas, dan empat aksi reviewer ini adalah kosakatanya.

Sebagai penulis, tanggapi setiap komentar, dorong commit perbaikan ke branch yang sama (PR memperbarui dirinya otomatis), dan tandai percakapan selesai. Yang paling menentukan kualitas review bukan ketajaman reviewer, melainkan ukuran PR: diff 60 baris diperiksa teliti dalam sepuluh menit, diff 1.500 baris hanya akan dapat “LGTM” yang sebenarnya berarti “saya menyerah membacanya”.

Deskripsi PR yang baik menjawab tiga hal sekaligus: apa yang berubah, kenapa, dan bagaimana cara memverifikasinya. Reviewer yang membaca diff tidak otomatis tahu konteks bisnisnya, jadi deskripsilah yang memberi mereka peta.

PR descriptionSalin
## Apa
Tambah endpoint POST /v1/products untuk membuat produk skincare.

## Kenapa
Tim katalog perlu menambah SKU baru tanpa akses langsung ke database.
Harga disimpan sebagai PriceRupiah int64 (rupiah penuh, bukan float)
agar bebas galat pembulatan.

## Cara verifikasi
- `go test ./internal/product/...` hijau
- curl contoh ada di komentar pertama

Melindungi main dengan review, status check, dan owner

PR hanya berarti bila aturannya ditegakkan, branch protection memastikan tidak ada perubahan yang menyelinap ke main tanpa review dan CI.

Branch penting seperti main adalah sumber kebenaran yang biasanya jadi dasar deploy, jadi ia layak dipagari. GitHub menyediakan dua mekanisme: branch protection rules klasik dan rulesets modern yang lebih luwes. Rulesets bisa banyak aktif bersamaan, punya status on/off, dan dapat dilihat siapa pun yang punya akses baca; menurut dokumentasi GitHub tentang rulesets, aturan-aturan ini “layer with protection rules” sehingga ketika tumpang tindih, yang paling restriktif yang menang. Aturan yang paling sering dipakai: wajib pull request sebelum merge dengan jumlah approval tertentu, wajib status check (CI) lulus, blokir force push, dan larang penghapusan branch.

Reviewer tidak harus ditunjuk manual setiap kali. File CODEOWNERS memetakan path ke pemilik, sehingga GitHub otomatis meminta review dari tim yang tepat begitu PR menyentuh file di area mereka. File ini dicari di .github/, root, lalu docs/, dan sintaksnya mengikuti pola gitignore diikuti @username atau @org/team-name. Menurut dokumentasi GitHub tentang code owners, bila digabung dengan aturan “require review from Code Owners”, satu approval dari salah satu owner sudah cukup.

CODEOWNERSSalin
# Owner default untuk semua file
*                   @org/maintainers

# Per area: yang paling spesifik menang
/frontend/          @org/team-fe
/backend/           @org/team-be
/infra/             @org/team-infra

# Pola bisa per ekstensi atau direktori dalam
**/*.sql            @org/team-be

Menyetel proteksi pada main hanya beberapa langkah lewat antarmuka GitHub.

Kualitas tim yang ditegakkan, bukan sekadar disepakati

Remote membuka jalur ke tim, PR menjadikannya tempat review, dan branch protection mengubah kebiasaan baik jadi default yang dipaksakan.

Repomu kini bukan catatan pribadi lagi. Remote menyinkronkan kerja lewat fetch, pull, push, dan upstream, dengan kebiasaan “fetch dulu, baru putuskan” dan “jangan force ke branch bersama”. Pull Request memindahkan review ke konteks kode, dan PR kecil mendapat review yang tajam. Branch protection serta CODEOWNERS memastikan review dan CI tidak bisa dilewati, dengan ruleset modern sebagai pilihan utama. Di Chapter 5 kita kembali ke kemampuan lokal yang kuat: merapikan sejarah dengan rebase dan membatalkan perubahan dengan aman, justru karena kini kamu tahu mana sejarah yang sudah dibagikan dan tak boleh ditulis ulang.