Contoh yang baik dari seseorang yang cocok dengan deskripsi itu mungkin seorang manajer proyek.

Suatu hari saya ditanya oleh bos saya, "apa itu Github itu dan mengapa itu penting?" Dia memiliki beberapa proyek eksklusif sehingga dia akan memerlukan hosting pribadi dan saya menemukan diri saya berjuang untuk menjelaskan di luar biasanya: VCS membuat kolaborasi sepele, memberikan sejarah dan "cadangan" semua data Anda, dan memungkinkan Anda untuk merekam perubahan atom dalam basis kode . Dalam pikiran saya, saya berpikir, "hampir seolah-olah Anda harus menggunakan DRVS untuk benar-benar memahami betapa bermanfaatnya itu".

Saya akhirnya menunjuknya ke BitBucket karena mereka memberi Anda repositori pribadi tanpa batas (saya bahkan harus menjelaskan apa itu repositori).

Apakah ada yang punya contoh konkret yang sangat baik tentang bagaimana VCS telah menyelamatkan pantat mereka atau membuat hidup lebih mudah, dll - pada dasarnya, bagaimana Anda menjual DVSC kepada seseorang yang tidak terbiasa dengan pemrograman, tetapi bukan profesi programmer?

Kontrol versi sangat bagus untuk (setidaknya) tiga empat hal: cadangan, berbagi kode antara pengembang, menemukan + memperbaiki bug dan melacak kemajuan.

1. Cadangkan . Jika tidak ada yang lain, itu cadangan pada steroid. Anda memiliki seluruh riwayat pengembangan, setiap komit adalah snapshot dari seluruh kode Anda dengan id (nomor revisi), deskripsi, cap waktu, info pengguna. Dan mudah untuk membandingkan file di antara revisi. Jika tidak ada yang lain, ini lebih cepat daripada cadangan sederhana (hanya perubahan file yang dikirim dan disimpan), dan mengandung metadata yang jauh lebih berguna. Mengapa menemukan kembali ini?

2. Berbagi kode antar pengembang . Jika Anda memiliki setidaknya dua pengembang yang bekerja pada produk yang sama secara bersamaan, saya tidak melihat cara lain untuk secara andal dan konsisten berbagi perubahan kode dan menggabungkannya. Mengirim ritsleting melalui surat?

3. Menemukan dan memperbaiki bug . Ketika pelanggan Anda melaporkan bug untuk versi produk tertentu, Anda dapat dengan cepat mendapatkan snapshot sumber aktual untuk mereproduksi dan memperbaikinya. Sulit mereproduksi bug jika sumber Anda berbeda dengan pelanggan. Apakah Anda meminta mereka untuk mengirim executable sehingga Anda dapat membongkar itu? Selain itu, jika Anda memiliki masalah dalam mengidentifikasi penyebab bug, Anda dapat menggunakan VCS untuk menunjukkan dengan tepat revisi tempat bug itu diperkenalkan.

4. Pelacakan kemajuan . Saat Anda mengkomit pekerjaan Anda dalam snapshot, ini memungkinkan Anda (dan manajer Anda) untuk melacak kemajuan implementasi fitur dan status bug terbuka. Sistem VC juga mudah diintegrasikan dengan sistem pelacakan dan sistem integrasi berkelanjutan . Hampir mustahil untuk menjaga tingkat kualitas untuk hal lain selain proyek hobi, kecuali Anda memiliki VCS.

Setelah Anda memiliki semua sepakat bahwa tidak ada pengembangan perangkat lunak harus pernah dilakukan di luar VCS (saya tidak akan melewatkannya bahkan untuk proyek hobi), maka Anda dapat mendiskusikan fitur dari (sedikit lebih rumit) DVCS (bagian berikut terang-terangan disalin dari Wikipedia ):

• Setiap pengguna memiliki salinan lokal repositori (dan secara efektif, salinan cadangan)
• Mengizinkan pengguna bekerja secara produktif bahkan saat tidak terhubung ke jaringan
• Membuat sebagian besar operasi lebih cepat karena tidak ada jaringan yang terlibat
• Mengizinkan partisipasi dalam proyek tanpa memerlukan izin dari otoritas proyek
• Mengizinkan pekerjaan pribadi, sehingga pengguna dapat menggunakan sistem kontrol revisi mereka bahkan untuk konsep awal yang tidak ingin mereka terbitkan
• Hindari mengandalkan mesin fisik tunggal sebagai satu- satunya titik kegagalan

"Apakah kamu pernah menemukan tombol 'undo' berguna? Oh, jadi kamu setuju kita harus menggunakan kontrol versi?"

Ketika saya mulai menggunakan kontrol versi, fitur utama yang saya minati adalah kemampuan untuk 'membatalkan' kesalahan saya dan kembali ke versi sebelumnya. Setiap orang dapat menghargai tombol batalkan. Kontrol versi yang diberikan dapat melakukan lebih banyak lagi.

Mulai dengan dasar-dasarnya:

Pertama, VCS melindungi pengembang dari diri mereka sendiri dan dari satu sama lain - jika itu tidak memiliki tujuan lain selain untuk memungkinkan dua atau lebih pengembang untuk bekerja pada basis kode yang sama relatif aman, itu akan bernilai sangat besar (dan saya telah berada dalam tim di mana sebelumnya hari kerja telah ditimpa oleh sedikit penyalinan yang ceroboh).

Kedua menyediakan jejak audit - sejarah - Anda dapat kembali dan melihat siapa yang mengubah apa dan kapan dan Anda dapat kembali dan mengambil kode yang Anda hapus karena itu tidak lagi diperlukan atau sesuai ketika ternyata itu akan diperlukan setelah semua.

Ketiga memberi Anda titik referensi - sumber definitif adalah kode yang dikomit (di dunia nyata sedikit lebih rumit, terutama dengan DVCS, tetapi untuk diskusi ini cukup dekat). Jika Anda memiliki cadangan yang didukung dengan benar, maka aset perusahaan Anda harus dilindungi.

Ketiga hal itu harus menjadi "itu" untuk menjual VCS - jika seorang manajer tidak dapat melihat nilai yang cukup di atas waktunya untuk menemukan manajer lain.

Setelah Anda menjual VCS (yang, setelah semua, hanya digunakan untuk tim pengembangan di mana jumlah devs lebih besar dari nol) maka pertanyaan mengapa DVCS berakhir, katakanlah, SVN atau TFS dan pertanyaan selanjutnya apakah akan bekerja di rumah atau menggunakan layanan yang di-host seperti Kiln atau Bitbucket atau Github (yang bersifat pribadi jika Anda membayar) agak lebih dalam dan lebih tergantung konteks.

VCS

Cukup jelaskan konsep cadangan . Cadangan memungkinkan Anda melihat apa yang sedang Anda kerjakan pada saat tertentu. Ceritakan bagaimana sebelum pemrogram VCS digunakan untuk menyalin seluruh proyek mereka secara kompulsif, umumnya untuk menyimpan setiap rilis baik dan stabil yang mereka miliki, jadi ketika keadaan memburuk mereka memiliki titik referensi yang baik tentang kapan sesuatu bekerja, membandingkannya dengan barang-barang terbaru dan melihat di mana mereka atau orang lain mengacaukan dan memperbaikinya lebih mudah hanya dengan melihat perbedaan daripada keseluruhan dua cadangan proyek.

Singkatnya : VCS memungkinkan Anda menyimpan cadangan pekerjaan Anda dan memberi Anda kemampuan hanya melihat perbedaan di antara cadangan.

DVCS

Sedangkan untuk kontrol versi terdistribusi, jelaskan bagaimana kontrol versi tipikal digunakan untuk memerlukan server dan koneksi internet dan bahwa semua orang bosan akan hal itu karena lebih lambat dan semua orang bekerja dengan satu cadangan, jika ada yang mengacaukan itu mengacaukan proyek untuk semua orang, jadi dengan kontrol versi terdistribusi, setiap orang dapat bekerja pada cadangan mereka sendiri di mesin mereka tanpa koneksi internet, dan semua orang senang karena tidak ada yang mengacaukan cadangan mereka saat mereka bekerja dan mereka dapat khawatir tentang berbagi pekerjaan mereka nanti ketika mereka selesai.

Satu lagi yang bagus adalah bahwa tidak seperti VCS terpusat di mana hanya ada satu cadangan, jika mesin dengan cadangan terbakar masih ada cadangan lengkap lainnya untuk berkeliling (setidaknya satu untuk setiap pengembang).

Singkatnya : DVCS memungkinkan Anda bekerja dalam cadangan Anda sendiri tanpa semua orang harus dijejalkan dalam satu server mengganggu satu sama lain, dan membiarkan Anda khawatir tentang perubahan orang lain setelah Anda selesai dengan barang-barang Anda. Juga, tidak ada yang terjadi jika mesin repositori utama terbakar .

Saya bekerja sebagian besar dengan insinyur (bukan pengembang per se, tetapi mereka menulis kode)

Poin utama, ketika saya menjelaskan kepada mereka tentang kontrol versi, adalah kemungkinan untuk membatalkan dan mengelola kode / dokumentasi Anda / apa pun dan menyederhanakan kolaborasi dengan pengembang / penulis lain / dll ...

Itu nilai jual yang bagus - dan merupakan alasan utama bagi saya untuk menggunakan VCS untuk semua pekerjaan saya, juga keuntungan lainnya: memiliki sejarah, repo yang dapat dengan mudah didukung ...

Sebagian besar dari mereka menyukai ide itu dan merasa cukup berguna, mengadopsinya untuk proyek mereka (khususnya jika mereka melibatkan kolaborasi dengan insinyur lain).

Ketika mencoba meyakinkan siapa pun tentang apa pun, Anda selalu perlu mencoba melakukannya dari sudut pandang mereka.

Manajer proyek Anda memiliki tujuan sederhana - menyelesaikan proyek tepat waktu dan sesuai anggaran.

Jika saat ini Anda tidak menggunakan kontrol versi, maka tim pengembangan Anda memecahkan masalah yang diselesaikan oleh kontrol versi dengan tangan. Semua masalah itu telah disebutkan dengan baik oleh jawaban lain, jadi saya tidak akan membahasnya di sini.

Yang perlu Anda lakukan adalah menjelaskan kepada manajer proyek Anda bahwa tim menghabiskan Xwaktu berjam-jam setiap minggu untuk memecahkan masalah yang dapat diselesaikan GIT secara otomatis, atau, katakanlah, 0.1 * Xjumlah jam pengembang.

Jangan mendekatinya dengan alasan GIT akan membuat hidup Anda lebih mudah atau kehidupan sesama pengembang Anda lebih mudah, dekati dari perspektif bahwa GIT akan mengirimkan perangkat lunak lebih cepat dan lebih murah.

Saya suka uraian @ Buttons840 tentang itu sebagai tombol undo untuk basis kode. Mungkin juga membantu membandingkannya dengan versi Word (yang tidak membuat frustrasi) atau fitur "Track Changes" InDesign. Dalam pengalaman saya, ini jelas mengurangi kebutuhan bagi satu orang untuk memberi tahu orang lain agar tidak menyentuh file X, Y, dan Z selama beberapa jam ke depan, yang berguna untuk menyelesaikan sesuatu.

Saya juga menemukan info versi berbutir halus sangat berguna untuk memperbaiki / mengatasi bug. Saya menyimpan nomor versi SVN (melalui properti $ Id) di hampir setiap file data yang saya hasilkan. Dengan begitu, jika (kapan?) Bug ditemukan, itu sepele untuk mengidentifikasi file dengan masalah potensial dan membuat ulang mereka atau meminta kode lain untuk mengkompensasi bug.

Jika Anda tidak menggunakan kontrol versi, bagaimana Anda tahu cara membangun kembali lingkungan produksi Anda?

1 Orang yang berbeda (penguji, pengembang) akan mencari informasi yang sama di tempat yang berbeda

mengarah ke DUPLICATE DATA yang keluar dari sinkronisasi.
Kontrol versi adalah cara termudah untuk menghilangkan data duplikat.

2 Jika Anda menggunakan kontrol versi, mudah untuk memastikan lingkungan produksi cocok dengan apa yang ada di kontrol versi.

Ini membuatnya mudah untuk mendeteksi apakah masalah disebabkan oleh build yang buruk (prod tidak cocok dengan kontrol versi), atau bug desain atau pengkodean (prod tidak cocok dengan kontrol versi).

Kontrol versi memudahkan untuk menetapkan nomor rilis untuk setiap lingkungan pengujian dan Anda tentu berharap produksi memiliki nomor rilis lebih rendah daripada pengujian atau pengembangan, dan pengujian memiliki nomor rilis lebih rendah daripada pengembangan. Jika ini bukan masalahnya, beberapa bagian dari kode belum diuji dengan benar ..

Juga jika Anda merilis perangkat lunak, fitur berikut dari VCS agak penting: Asumsikan pelanggan Anda menemukan bug. Pengembangan perangkat lunak saat ini mungkin dalam keadaan yang sangat berbeda dari versi yang dimiliki pelanggan. Mungkin bug sudah diperbaiki sekarang, mungkin tidak, tetapi dalam kasus apa pun perangkat lunak saat ini tidak dalam keadaan bahwa Anda bisa mengirimkannya kepada pelanggan.

VCS membuatnya sepele untuk kembali ke versi yang dikirimkan ke pelanggan, memperbaiki bug yang dimintanya, membangunnya, dan mengirimkannya versi revisi. Semua ini tanpa mengganggu perkembangan saat ini, tanpa harus mengirimnya versi dengan fitur yang belum selesai / tidak stabil atau bug tambahan yang diperkenalkan karena pengembangan baru yang belum selesai.

Selain itu, VCS memudahkan Anda untuk port fix ini kembali ke cabang pengembangan baru jika bug masih ada di sana juga.

Dengan disiplin yang kuat Anda mungkin dapat mengelola ini tanpa VCS untuk tim yang sangat kecil, tetapi menggunakan satu akan menghemat waktu Anda dan pada akhirnya uang. Kemungkinan besar itu juga akan membantu Anda mempertahankan pelanggan Anda.

Jika perusahaan Anda memiliki lebih dari dua orang, maka Anda mungkin memiliki dokumen kata atau dokumen excel yang terletak di suatu tempat yang diedit oleh banyak orang. Dan kadang-kadang orang-orang itu membuat salinan lokal, untuk melakukan perjalanan bisnis, dll. Atau dokumen dikirim melalui email setelah setiap perubahan.

Jika Anda memiliki file seperti itu, maka beberapa modifikasi orang telah hilang di masa lalu, atau akan hilang di masa depan. Atau orang berpikir mereka telah kehilangan perubahan, tetapi tidak dapat membuktikannya. Atau mereka ingin melihat siapa yang membuat perubahan kapan dan mengapa. Itulah masalah yang dipecahkan oleh VCS.

Saat memilih perangkat lunak / pustaka sumber terbuka, memiliki repositori DVCS jelas merupakan keuntungan dalam kriteria pemilihan.

1) Kita dapat mengkloning seluruh repositori, tidak perlu khawatir tentang proyek atau situs webnya sudah mati.

2) Orang-orang lebih bersedia untuk mengirimkan perbaikan bug melalui permintaan tarik, menghasilkan perbaikan bug yang lebih cepat untuk masalah yang mendesak.