Belajar Git Branching Strategies - GitHub/GitLab Branch Protection & Rulesets

#Pendahuluan

Setelah di episode 15 kita mempelajari TBD untuk tim besar — feature flags, branch by abstraction, dan CI/CD pipeline — pada episode ini kita membahas bagaimana mengamankan branch utama dengan branch protection rules dan rulesets. Branch protection adalah enforcement mechanism: aturan yang dipaksa secara teknis, bukan hanya documentasi.

Branch protection memastikan bahwa main tidak bisa di-push langsung, tidak bisa di-force-push, dan hanya kode yang sudah di-review dan diuji yang masuk ke production.

#Branch Protection Rules (GitHub)

#Status Checks Wajib

CI pipeline harus passing sebelum merge diizinkan. Di GitHub:

1. Buka Settings → Branches → Add rule.
2. Pilih branch pattern (contoh: main).
3. Aktifkan Require status checks to pass before merging.
4. Pilih workflow mana yang harus passing (lint, test, build).

#Approval Requirements

• Require pull request reviews before merging: minimal 1-2 approval dari reviewer.
• Dismiss stale pull request approvals when new commits are pushed: approval dibatalkan jika ada commit baru.

#Force Push dan Delete Protection

• Do not allow force pushes: mencegah rewrite history di branch terproteksi.
• Do not allow deletions: mencegah branch utama dihapus secara tidak sengaja.

#Merge Strategy

• Require squash merging: hanya squash merge yang diizinkan → history main bersih.
• Require linear history: hanya rebase merge yang diizinkan → tanpa merge commit.

#Merge Request Approval (GitLab)

GitLab memiliki fitur serupa dengan nama berbeda:

• Required approvals: minimal N approval.
• Approvers list: tentukan siapa yang boleh approve.
• Pipeline must succeed: CI harus passing.
• All discussions must be resolved: semua komentar review harus di-resolve.

#Rulesets (GitHub Modern)

Rulesets menggantikan branch protection rules — lebih granular dan powerful:

#Keunggulan Rulesets

• Pattern-based: bisa diterapkan ke banyak branch sekaligus dengan wildcard.
• Nested rules: rules bisa di-stack untuk复杂 scenarios.
• Bypass list: beberapa role (admin) bisa bypass rules tertentu.

#Contoh Rulesets

rules:
  - name: "Protect main and staging"
    target: branch
    patterns:
      - "main"
      - "staging"
    rules:
      - type: pull_request
        parameters:
          required_approving_review_count: 2
          dismiss_stale_reviews: true
      - type: required_status_check
        parameters:
          required_status_checks:
            - "lint"
            - "test"
            - "build"
      - type: non_fast_forward

#CODEOWNERS untuk Auto-Assign

File CODEOWNERS di root repository menentukan siapa yang harus review perubahan di path tertentu:

# CODEOWNERS
*.ts @team-backend
*.css @team-frontend
Dockerfile @team-devops
.github/** @team-devops

Ketika PR mengubah file di src/api/, reviewer dari @team-backend otomatis di-assign.

#Penutup

Pada episode 16 ini, kalian telah memahami Branch Protection & Rulesets:

• Branch protection rules: status checks, approval, force push protection, merge strategy.
• GitLab MR approval: required approvals, discussions resolved, pipeline must succeed.
• Rulesets (GitHub modern): lebih granular, pattern-based, nested rules.
• CODEOWNERS: auto-assign reviewer berdasarkan path file.
• Best practice: jangan izinkan direct push ke main di production repos.

Di episode 17 selanjutnya kita akan mempelajari CI/CD Integration dengan Branching Strategy — bagaimana pipeline trigger berbeda berdasarkan branch, environment deployment strategy, dan canary/blue-green deployment via branching. Sampai jumpa di episode 17!