164 lines
4.3 KiB
Markdown
164 lines
4.3 KiB
Markdown
# 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
|