Anda perlu membuat kasus untuk penggunaan kontrol versi, dan pertama-tama mencoba menjualnya kepada rekan kerja Anda, dan jika itu gagal, naik rantai ke kepemimpinan proyek dan lebih tinggi.
Untuk sesama insinyur perangkat lunak, kasus Anda harus difokuskan pada bagaimana menghemat waktu dan sakit kepala dalam jangka panjang. Temukan waktu dari masa lalu Anda sendiri, atau cerita yang diterbitkan (blog, artikel di majalah, buku putih) tentang bagaimana penggunaan kontrol versi membuat hidup Anda lebih mudah. Jika Anda dibakar dengan tidak memiliki kontrol versi, buat itu menjadi pribadi. Jika rekan pengembang Anda berada dalam situasi yang sama, mereka harus melihat cahaya dan bagaimana alat ini dapat membantu mereka.
Ini adalah taruhan terbaik Anda. Walaupun saya tidak dapat menemukan sumbernya saat ini, saya telah membaca (di beberapa tempat) bahwa perubahan paling efektif untuk proses berasal dari pengembang, yang harus berurusan dengan perubahan. Jika Anda bisa mendapatkan pengembang, Anda mencapai dua hal. Pertama, Anda telah menerima dukungan dari orang-orang yang akan terkena dampak perubahan proses. Kedua, ada sekelompok orang untuk meyakinkan manajemen bahwa ini adalah upaya yang bermanfaat dan akan meningkatkan produk dan proyek.
Namun, jika Anda tidak bisa mendapatkan dukungan dari tim pengembangan dan Anda masih merasa sangat kuat tentang penerapan kontrol versi, maka Anda dapat naik ke manajemen. Tetapi menjadi lebih berisiko jika Anda bersolo karier, karena Anda tidak hanya harus khawatir tentang menjual peningkatan, tetapi juga menghadapi serangan balik dari kolega Anda.
Untuk proyek, program, dan manajemen organisasi, kasusnya harus pada bagaimana menyebarkan kontrol versi dapat menghemat waktu dan uang organisasi. Orang-orang di tingkat ini peduli tentang berapa banyak biaya yang dikeluarkan proyek, di mana ia berdiri dibandingkan dengan perkiraan, dan seterusnya. Cari kertas putih, buku, artikel, dan dokumen dan publikasi profesional lainnya yang menjelaskan bagaimana menggunakan kontrol versi telah menghemat waktu dan uang organisasi lain dalam jangka panjang. Anda juga dapat memperkenalkan perspektif kualitas di sini, jika organisasi Anda tertarik dengan kualitas perangkat lunak.
Anda secara khusus menyebutkan bahwa Anda ingin menggunakan sistem kontrol versi terdistribusi. Jangan memaksakan itu di tenggorokan tim atau organisasi. Perkenalkan mereka ke kontrol versi dan opsinya. Meskipun Anda secara pribadi mungkin lebih suka menggunakan DVCS (seperti Mercurial), itu mungkin bukan yang terbaik untuk tim dan organisasi Anda. Menggunakan alat yang keliru hanya akan memperburuk masalah dengan meronta-ronta.
Juga, waspadai risiko proses pengenalan yang terlambat . Meskipun penggunaan kontrol versi adalah praktik terbaik yang diterima secara umum, mungkin sudah terlambat untuk memperkenalkannya secara efektif pada proyek saat ini tanpa risiko besar untuk penyelesaian proyek. Sebaliknya, saya akan merekomendasikan fokus pada peningkatan status quo untuk proyek dan tim masa depan.
Juga, ini adalah pendekatan umum yang dapat Anda ikuti untuk melakukan setiap proses atau peningkatan teknologi.