Merge, Tag, dan Rilis: Melacak Apa yang Masuk ke Produksi

Kamu baru saja selesai meninjau sebuah pull request. Kodenya terlihat bagus, pengujian lolos, dan rekan setimmu menyetujui perubahan tersebut. Lalu apa?

Sebagian besar tim tahu bahwa mereka perlu menggabungkan perubahan ke branch utama. Namun, cara kamu melakukan merge, catatan yang kamu tinggalkan, dan bagaimana kamu menandai apa yang sedang berjalan di produksi, semua itu menentukan apakah timmu bisa menjawab pertanyaan sederhana enam bulan dari sekarang: "Kode apa yang sebenarnya di-deploy pada tanggal itu?"

Merge Commit Adalah Jejak Kertasmu

Ada beberapa cara untuk menggabungkan perubahan dari branch fitur ke branch utama. Pendekatan yang paling umum adalah membuat merge commit.

Merge commit melakukan lebih dari sekadar memindahkan kode. Ia mencatat dua informasi: dari branch mana perubahan berasal, dan ke branch mana perubahan itu masuk. Ini menciptakan entri yang jelas di riwayat commit yang mengatakan, "Sesuatu telah digabungkan di sini."

Bandingkan dengan fast-forward merge, di mana Git hanya memindahkan pointer ke depan tanpa membuat commit baru. Fast-forward merge menjaga riwayat tetap linier, tetapi mereka kehilangan konteks bahwa sebuah merge terjadi. Jika nanti kamu perlu melacak bug kembali ke sumbernya, merge commit memberimu tautan langsung ke diskusi pull request, komentar tinjauan, dan perubahan persis yang digabungkan.

Saat kamu menggunakan merge commit, git log-mu menceritakan sebuah kisah. Kamu bisa melihat bahwa feature-x digabungkan ke main pada hari Selasa, dan feature-y digabungkan pada hari Rabu. Jika sesuatu rusak pada hari Kamis, kamu tahu persis merge mana yang harus diselidiki terlebih dahulu.

Diagram alir berikut menunjukkan bagaimana setiap langkah terhubung untuk menciptakan jejak kertas yang jelas:

Berikut adalah urutan perintah yang tepat untuk diikuti setelah pull request disetujui:

# 1. Merge dengan non-fast-forward merge commit
git checkout main
git merge --no-ff feature-x -m "Merge feature-x into main"

# 2. Tag rilis pada merge commit
git tag -a v1.2.3 -m "Release v1.2.3"

# 3. Push main dan tag baru ke remote
git push origin main --tags

# 4. Hapus branch fitur secara lokal dan remote
git branch -d feature-x
git push origin --delete feature-x
flowchart TD A[Branch Fitur] --> B[Merge Commit] B --> C[Hapus Branch Fitur] C --> D[Buat Tag: v1.2.0] D --> E[Buat Catatan Rilis] E --> F[Deploy ke Produksi] B -.-> G[Info Branch: sumber & target] D -.-> H[Titik referensi permanen] F -.-> I[Dapat dilacak ke merge commit]

Bersihkan Setelah Merge

Setelah merge selesai, branch fitur telah memenuhi tujuannya. Menghapusnya menjaga repositori tetap rapi dan mencegah branch lama memenuhi daftar saat seseorang perlu membuat yang baru.

Beberapa tim menghapus branch segera setelah merge. Yang lain menunggu hingga versi baru telah berjalan di produksi selama satu atau dua hari, untuk berjaga-jaga jika mereka perlu membuat branch hotfix dari titik yang sama. Either approach works, as long as you have a consistent practice.

Sebelum menghapus, pastikan semua perubahan dari branch itu benar-benar ada di branch utama. Pemeriksaan cepat: jika branch telah digabungkan melalui pull request, sebagian besar platform hosting Git akan menampilkannya sebagai "merged" dan mengizinkan penghapusan satu klik.

Tag: Memberi Nama pada Versi

Branch utama sekarang berisi kode terbaru. Tapi bagaimana kamu tahu persis commit mana yang sedang berjalan di produksi saat ini? Branch utama terus bergerak maju seiring masuknya perubahan baru. Tanpa titik referensi tetap, kamu hanya menebak.

Di sinilah tag berperan. Tag adalah label yang dilampirkan ke commit tertentu. Tidak seperti branch, tag tidak bergerak. Setelah kamu membuat tag, tag itu akan menunjuk ke commit yang tepat selamanya.

Tim biasanya membuat tag saat mereka merilis versi baru. Misalnya, setelah pengujian selesai dan tim siap untuk deploy ke produksi, mereka membuat tag seperti v1.2.0 pada commit terakhir dari branch utama. Tag itu menjadi referensi permanen. Enam bulan kemudian, jika seseorang bertanya kode apa yang berjalan pada tanggal itu, kamu periksa tag-nya.

Beri Nama Tag Secara Konsisten

Nama tag harus mengikuti konvensi yang dipahami semua orang di tim. Semantic versioning adalah pilihan populer: v1.2.3 di mana:

  • Angka pertama berubah untuk rilis besar yang memutus kompatibilitas mundur
  • Angka kedua berubah untuk fitur baru
  • Angka ketiga berubah untuk perbaikan bug dan peningkatan kecil

Tapi semantic versioning bukan satu-satunya pilihan. Beberapa tim menggunakan tanggal: release-2024-11-15. Yang lain menggunakan nomor build: build-142. Yang penting adalah konsistensi. Pilih format, dokumentasikan, dan gunakan untuk setiap rilis.

Format apa pun yang kamu pilih, pastikan tag dibuat dari commit persis yang di-deploy. Jika kamu menandai commit yang berbeda, tag akan kehilangan nilainya sebagai titik referensi yang andal.

Catatan Rilis: Apa yang Berubah dan Mengapa

Setelah membuat tag, sebagian besar tim menulis catatan rilis. Catatan rilis adalah ringkasan singkat tentang apa yang berubah di versi ini. Tidak perlu panjang atau detail. Hanya perlu menjawab pertanyaan: "Haruskah saya peduli dengan rilis ini?"

Catatan rilis yang baik mencakup:

  • Fitur baru yang akan diperhatikan pengguna
  • Perbaikan bug yang menyelesaikan masalah yang diketahui
  • Perubahan besar yang memerlukan tindakan dari tim atau pengguna lain
  • Masalah atau keterbatasan yang diketahui dalam versi ini

Catatan rilis tidak harus ditulis dari awal. Banyak tim menghasilkannya dari judul pull request atau pesan commit antara tag terakhir dan yang sekarang. Tinjauan cepat untuk menghapus detail teknis dan menambahkan konteks yang berorientasi pengguna biasanya sudah cukup.

Jembatan Antara Pengembangan dan Produksi

Merge dan tagging membentuk jembatan antara menulis kode dan menjalankannya di produksi. Merge memastikan bahwa perubahan yang telah ditinjau masuk ke basis kode bersama. Tag memastikan bahwa kamu dapat menunjuk ke commit tertentu dan berkata, "Ini adalah versi yang sedang berjalan saat ini."

Tanpa tag, kamu memiliki riwayat commit yang panjang dan tidak tahu commit mana yang benar-benar dirilis. Kamu akhirnya menebak, memeriksa log deployment, atau bertanya kepada rekan tim yang mungkin tidak ingat. Tag menghilangkan ketidakpastian itu.

Daftar Periksa Praktis

Sebelum rilis berikutnya, lakukan langkah-langkah ini:

  • Gabungkan pull request dengan merge commit, bukan fast-forward
  • Hapus branch fitur setelah mengonfirmasi merge
  • Buat tag pada commit persis yang akan di-deploy
  • Tulis catatan rilis yang mencakup apa yang berubah dan mengapa itu penting
  • Konfirmasi bahwa tag telah di-push ke repositori jarak jauh sehingga seluruh tim dapat melihatnya

Artinya bagi Timmu

Lain kali kamu menggabungkan pull request, pikirkan tentang apa yang kamu tinggalkan. Merge commit dan tag adalah tindakan kecil, tetapi mereka menciptakan sejarah yang akan membuat dirimu di masa depan berterima kasih. Ketika sesuatu salah pada jam 2 pagi dan kamu perlu tahu apa yang berubah, kamu tidak perlu menebak. Kamu akan memiliki jejak yang jelas dari masalah produksi kembali ke merge commit, pull request, dan diskusi yang mengarah pada perubahan tersebut.