FE_CPONE/GIT_WORKFLOW.md

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

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.
• 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

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.

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-commit menjalankan scripts/devcpone_sync.sh
• Commit di branch master atau staging akan 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