# 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.
- Kalau target merge adalah `staging`, sync branch kerja ke `origin/staging`, bukan ke `origin/master`.
- Kalau target merge adalah `master`, sync branch kerja ke `origin/master`.
- 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`.

## Patokan Sebelum Merge

- Target akhir `staging`
  Branch kerja harus update dulu dari `staging`.
- Target akhir `master`
  Branch kerja harus update dulu dari `master`.

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

Kalau target merge akhirnya `staging`, contoh yang benar:

```bash
git fetch origin
git rebase origin/staging
```

Kalau target merge akhirnya `master`, contoh yang benar:

```bash
git fetch origin
git rebase origin/master
```

### 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