원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Sejak mengadopsi alat AI, kecepatan pembuatan kode menjadi sangat cepat. Namun, kecepatan review tidak dapat mengimbanginya. Menurut laporan DORA (DevOps Research and Assessment) tahun 2024, tim dengan tingkat adopsi AI yang tinggi mengalami peningkatan ukuran PR rata-rata sebesar 154% dan peningkatan waktu review sebesar 91%. Akibatnya, siklus deployment justru menjadi lebih lambat. Meminta seseorang untuk mereview kode yang melebihi 1.000 baris sekaligus akan membuat siapa pun kelelahan. Untuk mengakhiri kekacauan ini, kita harus beralih ke struktur rantai Stacked PRs (PR bertumpuk) di mana kode ditumpuk sel demi sel.
Jika Anda memotong kode secara sembarangan, kompilasi akan gagal atau dependensi akan rusak. Anda memerlukan kriteria yang jelas. Batasi PR tunggal hingga maksimal 200 baris kode yang diubah dan kurang dari 10 file yang dimodifikasi agar reviewer dapat menyelesaikannya dalam waktu 15 menit. Bagilah satu fitur besar menjadi rantai maksimum 3 branch turunan:
Ikuti urutan ini dengan ketat. Tetapkan juga nama branch dengan format feature/<nama-fitur>/stack-<tahap>-<deskripsi>. Proses untuk mendekonstruksi branch 1.000 baris yang sudah kusut (legacy-giant-branch) menjadi sebuah rantai sangatlah sederhana.
Pertama-tama, perbarui branch main dan buat cadangan untuk aslinya.
`bash
git checkout main
git pull origin main
git checkout legacy-giant-branch
git branch backup/legacy-giant-branch
`
Selanjutnya, buat branch Layer 1 dari main dan lakukan cherry-pick hanya pada commit yang berkaitan dengan skema.
`bash
git checkout -b feature/order-refactor/stack-1-schema main
git cherry-pick
git push origin feature/order-refactor/stack-1-schema
`
Sekarang, jadikan Layer 1 sebagai induk dan rentangkan Layer 2 serta Layer 3 secara berurutan.
`bash
git checkout -b feature/order-refactor/stack-2-service feature/order-refactor/stack-1-schema
git cherry-pick
git push origin feature/order-refactor/stack-2-service
git checkout -b feature/order-refactor/stack-3-controller feature/order-refactor/stack-2-service
git cherry-pick
git push origin feature/order-refactor/stack-3-controller
`
Pemilihan alat juga merupakan faktor pertimbangan. Pure Git CLI gratis tetapi membutuhkan banyak usaha manual, sementara alat khusus seperti Graphite sangat nyaman namun menimbulkan biaya dan dependensi infrastruktur.
| Item Evaluasi | Pure Git CLI | GitHub CLI (gh stack) | Graphite / External Tools |
|---|---|---|---|
| Pelacakan Dependensi | Pengaturan Base branch manual | .git lokal dan metadata GitHub | Engine remote terpisah dan DB Lokal |
| Otomatisasi Rebase | Pekerjaan manual branch individu | Menjalankan perintah gh stack rebase | Penanganan otomatis rantai anak saat commit berubah |
| Kurva Belajar | Tinggi (Perlu memahami prinsip Git) | Rendah (Instalasi ekstensi CLI) | Sedang (Perlu beradaptasi dengan UI khusus) |
| Stabilitas Operasional | 100% kompatibel dengan Git standar | Status Public Preview | Sangat tinggi |
Menggunakan Stacked PR membuat momen permintaan modifikasi PR induk menjadi hal yang paling menyiksa. Hash commit berubah dan menyebabkan semua branch anak di bawahnya rusak total. Jika Anda langsung menjalankan git rebase, commit akan masuk dua kali lipat. Anda harus menentukan rentang yang akan dipotong menggunakan sintaks git rebase --onto.
Jika Layer 1 dimodifikasi, pindahlah ke Layer 2 dan susun ulang dari titik commit Layer 1 sebelum modifikasi hingga HEAD saat ini di atas titik akhir Layer 1 yang baru.
`bash
git checkout feature/order-refactor/stack-2-service
git rebase --onto feature/order-refactor/stack-1-schema feature/order-refactor/stack-2-service
git push --force-with-lease
`
Pindahkan Layer 3 ke atas Layer 2 yang baru dengan cara yang sama.
`bash
git checkout feature/order-refactor/stack-3-controller
git rebase --onto feature/order-refactor/stack-2-service feature/order-refactor/stack-3-controller
git push --force-with-lease
`
Jika pekerjaan ini dilakukan secara manual setiap saat, manusia pasti akan membuat kesalahan. Buatlah skrip shell untuk mengotomatiskan rebase berurutan.
`bash
#!/usr/bin/env bash
set -e
STACK_BRANCHES=(
"feature/order-refactor/stack-1-schema"
"feature/order-refactor/stack-2-service"
"feature/order-refactor/stack-3-controller"
)
TARGET_BASE="main"
git fetch origin
CURRENT_PARENT="$TARGET_BASE"
for BRANCH in "BRANCH"
OLD_BASE=CURRENT_PARENT" "OLD_BASE" ]; then
git rebase --onto "OLD_BASE" "BRANCH"
CURRENT_PARENT="$BRANCH"
done
`
Jangan lupa untuk mengaktifkan fungsi pencatatan riwayat penyelesaian konflik di pengaturan Git. Fitur ini akan melewati konflik berulang secara otomatis.
`bash
git config --global rerere.enabled true
git config --global rerere.autoupdate true
git config --global rebase.autoStash true
git config --global rebase.updateRefs true
`
Memecah PR menjadi 3 bagian menimbulkan masalah di mana runner CI juga berjalan 3 kali lipat. Tidak perlu menjalankan tes E2E yang berat di setiap PR. Konfigurasikan lingkungan GitHub Actions sedemikian rupa sehingga layer bawah hanya menjalankan unit test yang solid, sementara verifikasi integrasi penuh hanya dilakukan pada PR paling atas.
Tambahkan pernyataan bersyarat posisi stack ke .github/workflows/ci.yml.
`yaml
ame: Stack-Aware CI Pipeline
on:
pull_request:
branches: [ main ]
jobs:
fast-lint-and-unit-test:
name: Fast Validation (All Layers)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Linter & Unit Tests
run: |
npm ci
npm run test:unit
heavy-integration-test:
name: Full E2E Test (Top Layer Only)
runs-on: ubuntu-latest
if: |
github.event.pull_request.stack == null ||
github.event.pull_request.stack.position == github.event.pull_request.stack.size
steps:
- uses: actions/checkout@v4
- name: Run Heavy Integration & E2E Tests
run: |
npm ci
npm run test:e2e
`
Menetapkan aturan perlindungan branch di tingkat organisasi juga merupakan hal yang wajib.
main terlebih dahulu saat PR bawah belum digabungkan menggunakan 'Require Status Checks to Pass Before Merging'.Agar Stacked PR dapat berjalan dengan baik, reviewer harus dapat melihat gambaran keseluruhannya. Tentukan peta stack di .github/PULL_REQUEST_TEMPLATE.md.
`markdown
Stack Overview
PR ini adalah bagian dari rantai Order Refactoring Stack.
Current Layer Scope
Dependency Status
`
Setelah PR bawah #101 masuk ke main melalui Squash Merge, GitHub UI Diff dari PR anak #102 tiba-tiba meledak. Ini adalah fenomena di mana seluruh kode dari #101 yang sudah digabungkan tertangkap sebagai perubahan PR anak. Masalah ini terjadi karena SHA dari commit Squash dan SHA dari commit induk menjadi berbeda pada Git Commit Graph. Jangan panik, cukup naikkan commit branch anak ke atas main dengan urutan di bawah ini.
`bash
git log --graph --oneline
git checkout feature/order-refactor/stack-2-service
git fetch origin
git rebase --onto origin/main feature/order-refactor/stack-2-service
git push --force-with-lease origin feature/order-refactor/stack-2-service
`
Pekerjaan memecah PR 1.000 baris yang raksasa bukanlah sekadar masalah menangani teknologi Git. Hal ini lebih mendekati pekerjaan teknik untuk merapikan metode inspeksi kode tim dan seluruh rantai deployment dengan bersih. Ketika Anda menemui branch legacy yang berantakan, buatlah cadangan terlebih dahulu dan cobalah memotongnya menjadi 3 tahap layer. Kelelahan reviewer tidak hanya akan berkurang, tetapi Anda juga akan dapat mengontrol kode dengan jauh lebih jelas.