Skip to content

3. commit.md

Latest commit

 

History

History
109 lines (84 loc) · 3.87 KB

3. commit.md

File metadata and controls

109 lines (84 loc) · 3.87 KB
Raw

🔹 Commit Message

Commit message yang baik sangat penting untuk memudahkan tracking perubahan, kolaborasi, dan proses review. Gunakan format Conventional Commit agar konsisten dan mudah dipahami.

Conventional commit adalah standar penulisan pesan commit yang terstruktur dan mudah diproses otomatis oleh tool CI/CD, release, dan changelog.

Format dasar:

<type>: <deskripsi singkat>

Contoh:

  • feat: tambah halaman login
  • fix: perbaiki bug validasi email
  • docs: update README
  • refactor: optimasi fungsi pembayaran

Tipe umum:

  • feat: penambahan fitur baru
  • fix: perbaikan bug
  • docs: perubahan dokumentasi
  • refactor: perubahan kode tanpa mengubah behavior
  • test: menambah/perbaiki test
  • chore: update dependency, build, dsb

Tips Commit Message:

  • Gunakan bahasa yang singkat, jelas, dan aktif
  • Satu commit untuk satu perubahan logis
  • Sertakan ID issue jika relevan, contoh: fix: perbaiki bug login (#123)
  • Hindari commit message seperti "update", "fix bug", atau "wip"
  • Gunakan bahasa Inggris jika tim lintas negara

Keuntungan Conventional Commit

  • Otomatisasi Release & Changelog:
    Commit yang konsisten memudahkan pembuatan changelog otomatis dan proses release (misal dengan semantic-release).
  • Mendukung Semantic Versioning:
    Commit type (feat, fix, dsb) bisa digunakan untuk menentukan kenaikan versi secara otomatis (major, minor, patch).
  • Meningkatkan Keterbacaan & Kolaborasi:
    Semua anggota tim mengikuti format yang sama, sehingga tracking dan review lebih mudah.
  • Memudahkan Review & Audit:
    Commit yang terstruktur memudahkan reviewer dan auditor memahami perubahan yang dilakukan.
  • Integrasi dengan Tools:
    Banyak tools CI/CD, release, dan analisis yang mendukung conventional commit secara langsung.
  • Standarisasi Proses Tim:
    Membantu menjaga konsistensi dan profesionalisme dalam pengembangan perangkat lunak.

Studi Kasus

Penggunaan Otomatisasi Release & Changelog

  1. Project menggunakan semantic-release di CI/CD pipeline.
  2. Developer melakukan commit:
    • feat: implement fitur pembayaran
    • fix: perbaiki bug validasi email
    • feat!: hapus endpoint lama (! menandakan breaking change)
  3. Saat merge ke main, semantic-release:
    • Membaca commit, menentukan versi baru (feat = minor, fix = patch, ! = major)
    • Membuat changelog otomatis berdasarkan commit
    • Membuat tag versi baru dan (jika diatur) publish release ke GitHub/npm/dsb

Contoh

## [1.2.0] - 2025-06-17

### Fitur
- implement fitur pembayaran

### Perbaikan
- perbaiki bug validasi email

### Breaking Change
- hapus endpoint lama

Mendukung Semantic Versioning

Dengan conventional commit, semantic-release dapat menaikkan versi otomatis sesuai tipe perubahan:

  • Patch (perubahan kecil/perbaikan bug):
    Commit: fix: perbaiki bug validasi email
    Versi naik dari 1.2.0 → 1.2.1

  • Minor (penambahan fitur baru tanpa breaking change):
    Commit: feat: tambah fitur pembayaran
    Versi naik dari 1.2.1 → 1.3.0

  • Major (perubahan besar/breaking change):
    Commit: feat!: hapus endpoint lama atau tambahkan BREAKING CHANGE: di body commit
    Versi naik dari 1.3.0 → 2.0.0

commit dengan breaking change

feat!: hapus endpoint lama

BREAKING CHANGE: endpoint /v1/old-endpoint sudah tidak tersedia

Dengan pola ini, tim tidak perlu menaikkan versi manual—semua otomatis berdasarkan commit yang masuk.

Catatan Breaking Change:
Breaking change dapat ditandai dengan tanda seru (!) setelah tipe commit, atau dengan menambahkan BREAKING CHANGE: di body commit.

🔹 Referensi