GitHub Perinci Migrasi Git ke Azure: Mengurangkan Kesesakan Kerja Serentak

Pada 21 Oktober 2026, GitHub memperincikan langkah baharu dalam pembinaan semula infrastruktur Gitnya. Tumpuannya ialah mengurangkan kesesakan apabila banyak perubahan dihantar serentak, sambil meneruskan migrasi ke Azure. Perkembangan ini menawarkan bahan pembelajaran menarik tentang sistem teragih.

Migrasi sudah bergerak, tetapi belum selesai

Menurut GitHub, salinan bagi 99.99999% repositorinya sudah berada di Azure, sementara salinan turut kekal di pusat datanya sendiri. Angka itu merujuk kepada repositori yang mempunyai salinan di Azure, bukannya peratus keseluruhan migrasi yang selesai.

GitHub menyatakan kebanyakan repositori mempunyai dua daripada lima replika di Azure. Azure pula mengendalikan kira-kira separuh trafik Git ketika laporan diterbitkan.

Sumber: The bridge to agent-scale Git infrastructure.

Mengubah tempat operasi perlu menunggu

GitHub menerangkan perubahan penyelarasan penulisan daripada seluruh repositori kepada setiap rujukan secara individu. Dengan pendekatan ini, kemas kini pada rujukan berbeza boleh bergerak serentak; operasi yang bersaing pada rujukan sama masih perlu menunggu.

Syarikat itu melaporkan peningkatan daya pemprosesan tiga hingga empat kali dalam ujian dalaman bagi penulisan pada rujukan berbeza. Keputusan tersebut bukan jaminan kelajuan untuk setiap pengguna atau projek.

Sumber: The bridge to agent-scale Git infrastructure.

Mengapa menambah pelayan sahaja tidak mencukupi

Laporan terdahulu GitHub pada 6 Oktober menerangkan masalah reka bentuk asal: salinan repositori digunakan untuk ketahanan data dan juga menampung bacaan. Menambah replika bagi melayani lebih banyak bacaan turut menambah penyelarasan ketika menulis, kerana replika mengambil bahagian dalam proses tersebut.

GitHub mengaitkan tekanan baharu dengan pembangun, ejen perisian dan automasi yang bekerja serentak. Matlamat pembinaan semula ini termasuk mengekalkan aliran branching, semakan dan penggabungan kod, serta kawalan pemilik projek.

Ini ialah penerangan syarikat mengenai infrastrukturnya sendiri. Ia memberi konteks kepada keputusan reka bentuk, tetapi tidak mengukur pengalaman sambungan internet atau masa menunggu pasukan di Malaysia.

Sumber: Building Git infrastructure for agent-scale development.

Asas Git yang membantu memahami berita ini

Dokumentasi GitHub menerangkan bahawa repositori mengandungi fail projek bersama sejarah semakannya. Commit menyimpan keadaan perubahan, manakala branch membolehkan pembangunan disusun dalam laluan berasingan. Git ialah sistem kawalan versi teragih; GitHub menyediakan pengehosan dan alat kerjasama di atasnya.

Perbezaan commit dan push juga berguna: commit merekodkan perubahan dalam sejarah setempat, sementara push mengemas kini repositori jauh. Membuka pull request pula membawa perubahan ke ruang cadangan dan perbincangan sebelum penggabungan.

Istilah ini membantu pembaca membezakan kerja pada komputer sendiri, penghantaran perubahan dan proses semakan pasukan. Ketiga-tiganya berkaitan, tetapi menjalankan peranan berbeza dalam pembangunan perisian.

Sumber: About Git — GitHub Docs.

Cadangan editorial untuk pasukan Malaysia

Bagi pasukan pembangunan tempatan, kami mencadangkan penilaian bermula dengan satu projek kecil. Pilih aliran kerja yang biasa digunakan, kemudian catat masa penghantaran perubahan, tempoh menunggu automasi bermula dan masa ujian selesai. Asingkan ukuran tersebut supaya perbincangan tentang kelewatan mempunyai bukti yang jelas.

Sebagai contoh rekaan, sebuah pasukan yang membina portal tempahan boleh membandingkan perubahan dokumentasi dengan perubahan kod yang menjalankan ujian penuh. Catat saiz perubahan, jenis sambungan dan pekerjaan automasi yang dicetuskan. Jangan terus menyimpulkan bahawa semua kelewatan berpunca daripada storan repositori.

Jika menggunakan ejen pengekodan, tetapkan dahulu jenis tugas dan had percubaannya. Minta setiap cadangan perubahan disertakan tujuan serta cara menyemaknya. Nilai sama ada kerja tambahan itu membantu penyelenggara, bukannya sekadar menghasilkan lebih banyak aktiviti.

Cadangan ini ialah panduan editorial untuk pemerhatian dalaman, bukan arahan migrasi atau keperluan baharu GitHub. Pasukan boleh menggunakannya sebagai asas perbincangan antara pembangun, penguji dan penjaga infrastruktur.

Cadangan editorial untuk latihan dan portfolio

Pelajar atau pencari kerja boleh menjadikan berita ini latihan reka bentuk sistem. Lakarkan sebuah perkhidmatan rekaan yang menerima perubahan daripada beberapa pengguna. Tandakan bahagian yang boleh berjalan serentak dan bahagian yang perlu menunggu giliran. Terangkan sebab pilihan tersebut dalam bahasa sendiri.

Kemudian sediakan dua senario: semua pengguna mengubah item sama, dan setiap pengguna mengubah item berbeza. Nyatakan andaian, cara mengukur masa menunggu dan keadaan yang mungkin menyebabkan keputusan ujian mengelirukan. Tidak perlu meniru skala GitHub untuk menghasilkan latihan yang bermakna.

Dalam portfolio, sertakan rajah ringkas, pemerhatian dan batas eksperimen. Bezakan perkara yang benar-benar diuji daripada jangkaan reka bentuk. Hasil sebegini boleh menjadi bahan perbualan teknikal yang lebih jelas tentang kebolehpercayaan, penyelarasan dan pertimbangan prestasi.

Rujukan

• The bridge to agent-scale Git infrastructure — 2026-10-21
• Building Git infrastructure for agent-scale development — 2026-10-06
• About Git — GitHub Docs

Disediakan secara automatik dengan bantuan AI berdasarkan sumber yang dipautkan. Semakan sumber: 2026-10-24. Gambar utama ialah ilustrasi janaan AI, bukan foto peristiwa sebenar.