Workflow Open Source

Rilis 1.3.0 di chapter sebelumnya sampai ke pengguna yang dikenal: tim sendiri dan pelanggan yang menunggu. Proyek open source membalik peta itu — siapa pun di dunia boleh datang membawa perbaikan, dan pemilik repository harus siap menjadi penjaga gerbang. Kolaborasinya asimetris: kontributor tidak punya akses tulis ke repository asal, maintainer tidak mengenal semua penyumbang, dan seluruh dialog berlangsung di platform — bukan di meja rapat. Pola yang menjawabnya sudah dikenal di Fork dan Pull Request ; chapter ini memainkan kedua sisinya sebagai satu workflow utuh: maintainer menerima, kontributor mengirim.

Dua Sisi, Dua Rutinitas #

Kedua peran memakai peralatan Git yang sama tetapi menari urutan yang berbeda:

Sisi maintainer berdiri di atas peralatan yang sudah pernah kita bangun: Protected Branches menjaga main dari push langsung, Code Review menjadi gerbang kualitas, Issues dan Discussions menjadi tempat triage — label good first issue di sana bukan dekorasi, melainkan pintu masuk paling realistis bagi kontributor baru. Rilisnya terjadwal: tag diterbitkan berkala dari kumpulan PR yang ter-merge, pola Workflow Release yang dipadatkan.

Sesi Nyata: Kontribusi Pertama dari Fork #

Sisi yang butuh sesi Git nyata adalah kontributor, karena di situlah tiga repository bertemu. panduan-mini.git adalah upstream milik Budi — repository asal yang dijaga. Siti tidak meminta akses; Siti membuat fork (salinan server-side) lalu meng-clone fork-nya:

git clone fork-siti.git siti
cd siti
git remote set-url origin ../fork-siti.git
git remote add upstream ../panduan-mini.git
git remote -v

Output yang Dihasilkan (perintah terakhir):

origin  ../fork-siti.git (fetch)
origin  ../fork-siti.git (push)
upstream  ../panduan-mini.git (fetch)
upstream  ../panduan-mini.git (push)

Dua remote, dua arah: origin menerima push Siti bebas, upstream hanya ditarik — struktur model fork yang dibangun murni di Fork dan Upstream . Perubahan Siti dimulai dari issue kecil: panduan instalasi menuliskan npm intsall. Satu branch per topik, nama menjelaskan isi:

git switch -c perbaikan/typo-instalasi

Output yang Dihasilkan:

Switched to a new branch 'perbaikan/typo-instalasi'

printf '# Panduan Mini\n\n## Instalasi\n\n1. Klon repositori ini.\n2. Install dependensi dengan `npm install`.\n' > README.md
git add README.md
git commit -m "docs: perbaiki typo npm intsall pada panduan instalasi"
git push -u origin perbaikan/typo-instalasi

Output yang Dihasilkan (git commit dan git push):

[perbaikan/typo-instalasi a2447ee] docs: perbaiki typo npm intsall pada panduan instalasi
 1 file changed, 1 insertion(+), 1 deletion(-)

To ../fork-siti.git
 * [new branch]      perbaikan/typo-instalasi -> perbaikan/typo-instalasi
branch 'perbaikan/typo-instalasi' set up to track 'origin/perbaikan/typo-instalasi'.

Push mengarah ke fork, bukan ke upstream — Siti tidak punya hak tulis ke sana, dan memang tidak membutuhkannya. Di platform, Siti membuka pull request dari perbaikan/typo-instalasi di fork menuju main di upstream, lengkap dengan rujukan issue yang diperbaiki. Pesan commit bergaya docs: mengikuti Conventional Commits — kebiasaan yang memudahkan maintainer menimbang perubahan.

Review datang dua hari kemudian: maintainer menyetujui perbaikan typo, tetapi meminta satu tambahan — panduan berhenti di npm install tanpa memberi tahu cara menjalankan aplikasi. Respons Siti tetap di branch yang sama, satu commit di atas yang lama:

printf '# Panduan Mini\n\n## Instalasi\n\n1. Klon repositori ini.\n2. Install dependensi dengan `npm install`.\n3. Jalankan `npm start`.\n' > README.md
git add README.md
git commit -m "docs: tambahkan langkah menjalankan aplikasi"
git push

Output yang Dihasilkan (git commit dan git push):

[perbaikan/typo-instalasi ca164dd] docs: tambahkan langkah menjalankan aplikasi
 1 file changed, 1 insertion(+)

To ../fork-siti.git
   a2447ee..ca164dd  perbaikan/typo-instalasi -> perbaikan/typo-instalasi

Push inkremental a2447ee..ca164dd masuk ke branch PR yang sama; halaman pull request otomatis menampilkan commit baru itu — siklus respons-feedback persis pola Code Review . Setelah maintainer menyetujui, tombol merge menyatukan branch ke main upstream; Siti menutup sesi dengan git fetch upstream dan menghapus branch di fork.

Etika Open Source #

Etika bukan hiasan di proyek publik — ia adalah syarat kolaborasi jangka panjang. Tiga hal menopangnya:

• Lisensi. Repository tanpa berkas lisensi secara bawaan berarti semua hak dilindungi — orang lain boleh melihat, tetapi tidak berhak memakai. Kontribusi ke repository berlisensi MIT seperti sesi kita di atas berjalan mulus karena aturan penggunaan dan atribusinya eksplisit; panduan memilihnya ada di dokumentasi lisensi GitHub .
• CONTRIBUTING.md. Konvensi gaya, cara menjalankan tes, ukuran PR yang diharapkan — semuanya ditulis maintainer di satu berkas yang dibaca kontributor sebelum mengirim. Pola penulisannya sudah pernah kita susun di Commit Conventions .
• Komunikasi. Fitur besar dibicarakan di issue sebelum satu baris kode ditulis; pertanyaan dirunut di diskusi, bukan email pribadi; dan maintainer yang menimbang puluhan PR sekaligus diberi waktu — PR yang menunggu seminggu bukan penolakan.

Open source mengkolaborasikan orang asing lewat gerbang yang ketat tapi ramah. Tim kecil bekerja di kebalikannya: rekan yang dikenal, satu repository bersama, dan kecepatan yang justru dibunuh kalau gerbangnya terlalu ketat. Workflow tim kecil, chapter berikutnya, merancang aturan secukupnya untuk dua sampai lima orang — termasuk alasan kuat untuk menolak upacara GitFlow penuh di ukuran itu.