Memeriksa dan memilih Git
Beralih dari sistem kontrol versi terpusat ke Git mengubah cara tim pengembangan Anda membuat perangkat lunak.
Jika Anda adalah perusahaan yang mengandalkan perangkat lunak untuk aplikasi yang sangat penting, mengubah alur kerja pengembangan akan berdampak pada seluruh bisnis.
Pengembang akan mendapatkan keuntungan berikut dengan pindah ke Git.
Community
Di banyak kalangan, Git telah menjadi sistem kontrol versi yang diharapkan untuk proyek-proyek baru.
Jika tim menggunakan Git, kemungkinan besar Anda tidak perlu melatih karyawan baru di alur kerja karena mereka sudah terbiasa dengan pengembangan terdistribusi.
Selain itu, Git populer di antara proyek-proyek sumber terbuka. Sangat mudah untuk menggunakan pustaka pihak ketiga dan mendorong orang lain untuk melakukan fork kode sumber terbuka Anda.
Pengembangan terdistribusi
Di TFVC, setiap pengembang mendapatkan salinan aktif yang menunjuk kembali ke satu repositori pusat. Tetapi Git adalah sistem kontrol versi terdistribusi. Daripada salinan aktif, setiap pengembang mendapatkan repositori lokal mereka, lengkap dengan seluruh riwayat penerapan.
Memiliki riwayat lokal yang lengkap membuat Git cepat karena itu berarti Anda tidak memerlukan koneksi jaringan untuk membuat penerapan, memeriksa versi file sebelumnya, atau melakukan diff antara penerapan.
Pengembangan terdistribusi juga mempermudah penskalaan tim teknis Anda. Jika seseorang memutus cabang produksi di SVN, pengembang lain tidak dapat memeriksa perubahan mereka hingga diperbaiki. Dengan Git, pemblokiran semacam ini tidak ada. Semua orang dapat melanjutkan bisnis mereka di repositori lokal mereka.
Dan, seperti cabang fitur, pengembangan terdistribusi menciptakan lingkungan yang lebih andal. Bahkan jika pengembang menghapus repositori mereka, pengembang dapat mengkloning dari orang lain dan memulai dari awal.
Pengembangan berbasis trunk
Salah satu keuntungan paling signifikan dari Git adalah kemampuan pencabangannya. Tidak seperti sistem kontrol versi terpusat, cabang Git murah dan mudah digabungkan.
Pengembangan berbasis trunk menyediakan lingkungan yang terisolasi untuk setiap perubahan pada dasarkode Anda. Ketika pengembang ingin mulai mengerjakan sesuatu—tidak peduli seberapa besar atau kecil—mereka membuat cabang baru. Ini memastikan bahwa cabang utama selalu berisi kode kualitas produksi.
Menggunakan pengembangan berbasis trunk lebih dapat diandalkan daripada mengedit kode produksi secara langsung, tetapi pengembangan berbasis trunk juga memberikan keuntungan organisasi.
Pengembangan berbasis trunk memungkinkan Anda merepresentasikan pekerjaan pengembangan dengan granuralitas yang sama dengan backlog agile Anda.
Misalnya, Anda dapat menerapkan kebijakan di mana setiap item pekerjaan ditangani di cabang fitur.
Permintaan pull
Banyak alat manajemen kode sumber seperti Repositori Azure meningkatkan fungsionalitas Git inti dengan permintaan pull.
Permintaan pull adalah cara untuk meminta pengembang lain untuk menggabungkan salah satu cabang Anda ke dalam repositori mereka.
Hal ini memudahkan pimpinan proyek untuk melacak perubahan dan memungkinkan pengembang memulai diskusi seputar pekerjaan mereka sebelum mengintegrasikannya dengan dasarkode lainnya.
Karena permintaan pull pada dasarnya adalah rangkaian komentar yang dilampirkan ke cabang fitur, permintaan pull sangat serbaguna.
Ketika pengembang terjebak dengan masalah yang kompleks, mereka dapat membuka permintaan pull untuk meminta bantuan dari anggota tim lainnya.
Sebaliknya, pengembang junior dapat yakin bahwa mereka tidak menghancurkan keseluruhan proyek dengan memperlakukan permintaan pull sebagai tinjauan kode formal.
Siklus rilis lebih cepat
Siklus rilis yang lebih cepat adalah hasil akhir dari cabang fitur, pengembangan terdistribusi, permintaan pull, dan komunitas yang stabil.
Kemampuan ini mempromosikan alur kerja agile di mana pengembang didorong untuk lebih sering membagikan perubahan kecil.
Pada gilirannya, perubahan dapat didorong ke bawah alur penyebaran lebih cepat daripada standar rilis monolitik dengan sistem kontrol versi terpusat.
Seperti yang Anda harapkan, Git berfungsi dengan baik dengan integrasi berkelanjutan dan lingkungan pengiriman berkelanjutan.
Hook Git memungkinkan Anda menjalankan skrip ketika peristiwa tertentu terjadi di dalam repositori, yang memungkinkan Anda mengotomatiskan penyebaran sesuai keinginan.
Anda bahkan dapat membangun atau menyebarkan kode dari cabang tertentu ke server yang berbeda.
Misalnya, Anda mungkin ingin mengonfigurasi Git untuk menyebarkan penerapan terbaru dari cabang pengembangan ke server uji setiap kali ada yang menggabungkan permintaan pull ke dalamnya.
Menggabungkan otomatisasi build semacam ini dengan tinjauan serekan berarti Anda memiliki keyakinan setinggi mungkin terhadap kode saat bergerak dari pengembangan ke pentahapan ke produksi.