Belajar Git Branching Strategies - Monorepo Branching Strategy

#Pendahuluan

Setelah di episode 17 kita mempelajari CI/CD Integration — pipeline trigger berdasarkan branch dan environment deployment — pada episode ini kita membahas tantangan khusus: monorepo. Di monorepo, banyak package atau aplikasi tinggal dalam satu repository. Branch yang sama bisa mempengaruhi banyak komponen — dan CI harus tahu package mana yang berubah.

Monorepo branching strategy menjawab pertanyaan: bagaimana menjaga CI tetap efisien saat satu repo berisi banyak package?

#Tantangan Monorepo

#Banyak Package, Satu Branch

Bayangkan monorepo dengan struktur:

plaintext

packages/
  api/
  web/
  mobile/
  shared/

Developer membuat branch feature/api-auth yang hanya mengubah packages/api/. Tetapi CI mungkin menjalankan test untuk semua package — tidak efisien.

#CI Harus Tahu Package Mana yang Berubah

Tanpa path-based filtering, setiap push ke monorepo akan trigger CI untuk semua package. Ini membuang-buang waktu dan compute resource.

#Path-Based Filtering

#GitHub Actions: `paths` Filter

CI dengan path filter

on:
  push:
    paths:
      - 'packages/api/**'
      - 'packages/shared/**'
  pull_request:
    paths:
      - 'packages/api/**'
      - 'packages/shared/**'
jobs:
  test-api:
    runs-on: ubuntu-latest
    steps:
      - run: cd packages/api && npm test

CI hanya berjalan jika file di packages/api/ atau packages/shared/ berubah. Perubahan di packages/web/ tidak trigger CI untuk API.

#Turborepo/Nx: Affected-Based Execution

Tools monorepo seperti Turborepo dan Nx bisa mendeteksi package mana yang terpengaruh oleh perubahan:

Turborepo: run test hanya untuk affected packages

npx turbo run test --filter=...[HEAD^]

Perintah ini menjalankan test hanya untuk package yang berubah (dan dependennya). Sangat efisien untuk monorepo besar.

#Monorepo Branching Best Practice

#Sama seperti Feature Branch Workflow

Prinsip dasar tetap sama: buat branch dari main, kerja, buka PR, review, merge. Yang berubah adalah CI efficiency.

#Path Filtering di CI

Tambahkan path filtering agar CI hanya berjalan untuk package yang berubah:

100%

#CODEOWNERS per Package

plaintext

# CODEOWNERS
packages/api/** @team-backend
packages/web/** @team-frontend
packages/mobile/** @team-mobile
packages/shared/** @team-platform

Reviewer otomatis di-assign berdasarkan package yang berubah. Perubahan di packages/api/ akan di-review oleh tim backend.

Tip

Untuk monorepo, pertimbangkan menggunakan Turborepo atau Nx untuk affected-based task execution. Path filtering di CI saja tidak cukup — kalian juga perlu memastikan test dan build hanya berjalan untuk package yang benar-benar berubah.

#Penutup

Pada episode 18 ini, kalian telah memahami Monorepo Branching Strategy:

Tantangan: banyak package dalam satu repo, CI harus tahu package mana yang berubah.
Path-based filtering: GitHub Actions paths filter, Turborepo/Nx affected-based execution.
Branching principle: tetap sama seperti feature branch workflow, tambahkan path filtering.
CODEOWNERS per package: auto-assign reviewer berdasarkan package.

Di episode 19 selanjutnya kita akan mempelajari Git Bisect, Bisection & Debugging Workflow — bagaimana mencari commit penyebab bug dengan binary search, branching untuk eksperimen, dan bisect automation. Sampai jumpa di episode 19!