Skip to main content
Workflow kontribusinya GitHub Flow polos: fork, branch dari main, commit, buka pull request, review, squash merge. Gak ada yang lain. Satu-satunya aturan internal cuma soal gimana commit dan PR ditulis.

​
Commit message

Ketiga repo pake Conventional Commits. Formatnya:

​
Tipe

​
Scope

Scope nge-namain area-nya, dan dia mencerminkan susunan repo. Contoh beneran dari sejarah dua repo contoh (yang terakhir itu yang beneran nambahin CODEOWNERS dan issue template mereka - repo docs belum punya itu, liat CODEOWNERS dan Issues):
Dengan scope, commit yang sama bakal jadi fix(gpu): correct GPU keypair and account-id typing atau docs(tutorials): add example repos page. Dua-duanya boleh. Aturan yang selalu berlaku:
  • Imperative mood, present tense: “add X”, jangan pernah “added X” atau “adds X”.
  • Tipe pake huruf kecil, gak ada titik di akhir.
  • Satu perubahan logis per commit. Pisahin kerjaan yang gak berhubungan.
  • Commit message juga gak boleh pake em dash atau en dash, sama kayak di tempat lain di project ini.

​
Body dan footer

Body ngejelasin kenapa-nya kalau title aja gak cukup, terutama buat apa pun yang ngubah behavior yang ditagih. Baris footer kayak Closes #123 nge-link issue dan nutupnya otomatis pas merge, liat referensi GitHub.

​
Penamaan branch

Branch dari main, kasih nama <type>/<short-description>, kayak fix/gpu-keypair-id atau docs/contribute-section. Namanya cuma perlu kebaca di daftar PR; gak ada yang maksa.

​
Pull request

Pas lu buka PR, GitHub ngisi description dari pull request template repo. Template-nya berupa checklist, dan checklist itu definisi selesainya:
  • Komentar bilingual di kode baru, gak ada em atau en dash
  • Contohnya build di bahasanya, atau validate di folder yang disentuh
  • Gak ada secret, payWithCreditCard tetep false
  • README dan tabel di root di-update
  • Halaman situs docs di-update dalam dua bahasa kalau behavior berubah
Tiap kotak yang gak dicentang itu komentar review yang tinggal nunggu waktu. Centang sendiri sebelum minta review; reviewer bakal ngecek ulang.
1

Fork dan branch

Fork repo dari GitHub web UI, clone fork lu, dan bikin branch dari main yang terbaru. Pertahanin upstream remote tetap terkonfigurasi biar lu bisa pull main terbaru sebelum push.
2

Bikin perubahannya dan cek secara lokal

Ikutin Conventions, terus jalanin check dari Local setup di setiap folder yang lu sentuh. Buat repo docs, jalanin mint dev dan liat halamannya di browser.
3

Buka draft PR

Buka PR sebagai draft kalau lu mau feedback awal, terus tandai ready pas checklist-nya kelar. Link issue yang ditutup di description atau footer.
4

Review

CODEOWNERS otomatis minta review dari pemilik repo, liat CODEOWNERS and reviews. Harapin review-nya ngecek checklist template, konvensi, dan apakah docs dan kode berubah barengan.
5

Merge

Maintainer squash merge ke main, yang bikin history tetap linear dan satu commit per perubahan. Buat repo docs, merge ke main juga sekaligus deploy; aplikasi Mintlify nge-ship situsnya dalam hitungan menit. Buat repo contoh, maintainer boleh jalanin CI manual setelahnya.

​
Yang terjadi setelah merge

  • Repo docs: mint validate dan mint broken-links jalan otomatis pas push, terus situs di biznetgio.creations.ren redeploy otomatis dari main - liat Pipeline situs docs. Kedua step itu gak nge-order apapun atau makan biaya, jadi gak ada yang perlu digate manual di sini.
  • Repo contoh: gak ada yang jalan otomatis. Pipelines sengaja manual dispatch, karena apply dan up bikin order beneran. Maintainer nge-trigger run validate atau build setelah review, dan apa pun yang punya side effect beneran cuma pas emang diinginkan.
Satu aturan terakhir: gak ada apapun di project ini yang jalanin apply, up, atau step rilis secara otomatis pas push, dan gak ada branch protection dengan required check. Model safety buat apapun yang punya side effect beneran itu review manusia plus jalanin pipeline manual dengan sengaja - CI situs docs yang jalan pas push itu bukan pengecualian dari itu, soalnya dia cuma bisa gagal di validasi, gak pernah nge-order apapun. Itu pilihan desain yang dijelasin di Pipelines, dan itu sebabnya checklist PR lebih penting di sini daripada di kebanyakan repo.