AGENTS.md

@@ -28,6 +28,6 @@
 
 ## Auto Sync ke Devcpone
 - Repo ini punya **post-commit hook** di `.githooks/post-commit` yang otomatis menjalankan `scripts/devcpone_sync.sh`.
-- Setiap `git commit` di branch `master` akan langsung rsync file yang berubah ke `devcpone.aplikasi.web.id:/home/one/project/one/one-ui/`.
+- Setiap `git commit` di branch `master` atau `staging` akan langsung rsync file yang berubah ke `devcpone.aplikasi.web.id:/home/one/project/one/one-ui/`.
 - Hook sudah aktif (`core.hooksPath = .githooks`), tidak perlu jalankan script deploy manual.
 - Jangan bilang tidak ada hook/sync sebelum mengecek `.githooks/` dan `scripts/` terlebih dahulu.

CLAUDE.md

@@ -10,6 +10,6 @@
 
 # Auto Sync ke Devcpone
 - Repo ini punya **post-commit hook** di `.githooks/post-commit` yang otomatis menjalankan `scripts/devcpone_sync.sh`.
-- Setiap `git commit` di branch `master` akan langsung rsync file yang berubah ke `devcpone.aplikasi.web.id:/home/one/project/one/one-ui/`.
+- Setiap `git commit` di branch `master` atau `staging` akan langsung rsync file yang berubah ke `devcpone.aplikasi.web.id:/home/one/project/one/one-ui/`.
 - Hook sudah aktif (`core.hooksPath = .githooks`), tidak perlu jalankan script deploy manual.
 - Jangan bilang tidak ada hook/sync sebelum mengecek `.githooks/` dan `scripts/` terlebih dahulu.

GIT_WORKFLOW.md

@@ -0,0 +1,138 @@
+# 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
+
+- `master`
+  Branch final. Perubahan ke branch ini masuk lewat PR.
+- `staging`
+  Branch testing dan integrasi sebelum masuk `master`.
+- `feature/*` atau branch task
+  Branch kerja untuk perubahan per task, misalnya `ais_registration_sc`.
+
+## Alur Utama
+
+1. Buat branch kerja dari base yang benar.
+2. Kerjakan perubahan di branch kerja.
+3. Commit dengan format `TASKCODE - deskripsi singkat`.
+4. Push branch kerja ke remote.
+5. Buat PR dari branch kerja ke `staging`.
+6. Setelah lolos testing, buat PR dari `staging` ke `master`.
+7. Setelah merge ke `master`, sinkronkan branch lokal.
+
+## Cara Menentukan Base Branch
+
+- Ambil dari `master` kalau perubahan baru berdiri sendiri dan tidak butuh context terbaru di `staging`.
+- Ambil dari `staging` kalau perubahan baru bergantung pada hasil kerja yang sudah masuk `staging` tetapi belum masuk `master`.
+
+## Diagram Alur
+
+```mermaid
+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
+
+```text
+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.
+- Jangan direct push ke protected branch.
+- `master` dan `staging` dipakai sebagai branch tujuan PR.
+- Untuk repo ini, upload ke `devcpone` dilakukan dari commit di `master` atau `staging`.
+
+## Contoh Skenario 1
+
+Kasus:
+- A membuat `A1`
+- B membuat `B1`
+- `A1` sudah merge ke `staging`
+- `B1` belum butuh hasil `A1`
+
+Patokan:
+- A atau B yang kerja baru dan tidak butuh hasil `staging` terbaru bisa ambil base dari `master`.
+
+## Contoh Skenario 2
+
+Kasus:
+- `A1` sudah merge ke `staging`
+- C mau bikin `C1`
+- `C1` butuh flow, API, atau komponen yang berasal dari `A1`
+
+Patokan:
+- C buat branch baru dari `staging`, bukan dari `master`.
+
+## Contoh Alur Kerja Nyata
+
+### 1. Kerja task baru dari `master`
+
+```bash
+git fetch origin
+git checkout master
+git pull --ff-only origin master
+git checkout -b feature_x
+```
+
+### 2. Update branch kerja sebelum push
+
+```bash
+git fetch origin
+git rebase origin/master
+```
+
+Kalau branch kerja memang berbasis `staging`, ganti target rebase ke `origin/staging`.
+
+### 3. Commit dan push
+
+```bash
+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-commit` menjalankan `scripts/devcpone_sync.sh`
+- Commit di branch `master` atau `staging` akan upload file yang berubah di commit terakhir ke:
+
+```text
+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

README.md

@@ -14,7 +14,7 @@ Setelah itu:
 
 - `core.hooksPath` akan diarahkan ke `.githooks`
 - hook `post-commit` akan aktif
-- commit di branch `master` akan otomatis sync ke:
+- commit di branch `master` atau `staging` akan otomatis sync ke:
 
 ```text
 one@devcpone.aplikasi.web.id:/home/one/project/one/one-ui/

scripts/devcpone_sync.sh

@@ -5,7 +5,7 @@ repo_root=$(git rev-parse --show-toplevel)
 cd "$repo_root"
 
 branch=$(git symbolic-ref --quiet --short HEAD 2>/dev/null || true)
-if [ "$branch" != "master" ]; then
+if [ "$branch" != "master" ] && [ "$branch" != "staging" ]; then
   exit 0
 fi