4.3 KiB
4.3 KiB
Git Workflow FE_CPONE
Dokumen ini jadi patokan kerja git di repo FE_CPONE supaya alur branch, PR, dan upload ke devcpone konsisten.
Branch Utama
masterBranch final. Perubahan ke branch ini masuk lewat PR.stagingBranch testing dan integrasi sebelum masukmaster.feature/*atau branch task Branch kerja untuk perubahan per task, misalnyaais_registration_sc.
Alur Utama
- Buat branch kerja dari base yang benar.
- Kerjakan perubahan di branch kerja.
- Commit dengan format
TASKCODE - deskripsi singkat. - Push branch kerja ke remote.
- Buat PR dari branch kerja ke
staging. - Setelah lolos testing, buat PR dari
stagingkemaster. - Setelah merge ke
master, sinkronkan branch lokal.
Cara Menentukan Base Branch
- Ambil dari
masterkalau perubahan baru berdiri sendiri dan tidak butuh context terbaru distaging. - Ambil dari
stagingkalau perubahan baru bergantung pada hasil kerja yang sudah masukstagingtetapi belum masukmaster.
Diagram Alur
flowchart LR
A[master] --> B[branch kerja / feature]
C[staging] --> D[branch kerja lanjutan]
B --> E[PR ke staging]
D --> E
E --> C
C --> F[PR ke master]
F --> A
Diagram Singkat
master
|
+-- branch kerja A --------------> PR ke staging
| |
| v
| staging
| |
+-- branch kerja B dari staging ----> PR ke staging
|
v
PR ke master
|
v
master
Aturan Praktis
- Sebelum push atau menyiapkan merge, jalankan
git fetch origin. - Rebase ke base remote yang benar supaya conflict muncul lebih awal.
- Kalau target merge adalah
staging, sync branch kerja keorigin/staging, bukan keorigin/master. - Kalau target merge adalah
master, sync branch kerja keorigin/master. - Jangan direct push ke protected branch.
masterdanstagingdipakai sebagai branch tujuan PR.- Untuk repo ini, upload ke
devcponedilakukan dari commit dimasterataustaging.
Patokan Sebelum Merge
- Target akhir
stagingBranch kerja harus update dulu daristaging. - Target akhir
masterBranch kerja harus update dulu darimaster.
Kalau staging dipakai paralel oleh beberapa fitur, jangan patokan ke master saat mau merge ke staging, karena bisa ada fitur lain yang sudah lebih dulu masuk staging tetapi belum masuk master.
Contoh Skenario 1
Kasus:
- A membuat
A1 - B membuat
B1 A1sudah merge kestagingB1belum butuh hasilA1
Patokan:
- A atau B yang kerja baru dan tidak butuh hasil
stagingterbaru bisa ambil base darimaster.
Contoh Skenario 2
Kasus:
A1sudah merge kestaging- C mau bikin
C1 C1butuh flow, API, atau komponen yang berasal dariA1
Patokan:
- C buat branch baru dari
staging, bukan darimaster.
Contoh Alur Kerja Nyata
1. Kerja task baru dari master
git fetch origin
git checkout master
git pull --ff-only origin master
git checkout -b feature_x
2. Update branch kerja sebelum push
git fetch origin
git rebase origin/master
Kalau branch kerja memang berbasis staging, ganti target rebase ke origin/staging.
Kalau target merge akhirnya staging, contoh yang benar:
git fetch origin
git rebase origin/staging
Kalau target merge akhirnya master, contoh yang benar:
git fetch origin
git rebase origin/master
3. Commit dan push
git add <file-yang-perlu>
git commit -m "3Z4LPN - contoh perubahan"
git push -u origin feature_x
4. Merge ke staging
- Buat PR
feature_x->staging - Testing di
staging
5. Merge ke master
- Buat PR
staging->master - Setelah merge, sync branch lokal lagi
Sync ke Devcpone
- Hook
post-commitmenjalankanscripts/devcpone_sync.sh - Commit di branch
masterataustagingakan upload file yang berubah di commit terakhir ke:
one@devcpone.aplikasi.web.id:/home/one/project/one/one-ui/
- Delete file tidak ikut dihapus di remote
- Upload mengikuti file yang berubah pada commit terakhir