Apa cara paling efektif / efisien untuk mengembangkan aplikasi dengan banyak orang tanpa kendali sumber?

Pengantar situasi saya

Saya bekerja untuk perusahaan pengembangan web kecil. Kami memiliki tim yang terdiri dari empat pengembang ASP.NET, termasuk saya. Hampir semua proyek kami (> 98%) adalah proyek satu orang yang membutuhkan waktu sekitar 1-4 minggu untuk menyelesaikannya. Kami tidak menggunakan kontrol sumber atau versi. Satu-satunya yang kami miliki adalah folder bersama di server lokal yang berisi sumber terbaru (== sumber aplikasi langsung) dari semua proyek.

Pada kesempatan langka yang kami perlukan untuk mengerjakan proyek yang sama dengan lebih dari satu orang, kami menggunakan ... Beyond Compare. Satu atau dua kali sehari pengembang saling bertanya apakah mereka memiliki versi yang mengkompilasi dan kemudian mereka menyinkronkan kode mereka menggunakan Beyond Compare. Ketika hanya dua orang yang mengerjakan suatu proyek, ini bekerja "cukup baik", tetapi begitu pengembang ketiga memasuki proses, itu menjadi bagian dari sampah yang tidak dapat dikelola. Terutama ketika semua orang mulai membuat perubahan pada database.

Saya (dan satu atau dua rekan pengembang saya) telah memberi tahu bos saya beberapa kali bahwa kita harus mulai menggunakan beberapa bentuk kontrol sumber dan versi seperti Git, Mercurial atau TFS (bos kami sangat berpikiran Microsoft). Sayangnya, bos saya tidak melihat keuntungan dari beralih ke sistem kontrol sumber dan versi, karena di matanya semuanya bekerja dengan baik sekarang dan dia tidak ingin menginvestasikan waktu dan uang dalam menyiapkan sistem baru dan memastikan semua orang tahu cara menggunakannya. Bahkan setelah saya menjelaskan kelebihannya (seperti kolaborasi yang disederhanakan, versi aplikasi yang berbeda, cara yang lebih aman untuk mengubah kode, ...) kepadanya, dia masih tidak berpikir itu adalah sesuatu yang kita butuhkan.

Dari empat pengembang, hanya dua (termasuk saya) yang memiliki pengalaman dengan kontrol sumber (Git). Dan pengalaman itu sangat terbatas. Saya tahu bagaimana cara mengkloning repositori Github ke komputer saya, membuat beberapa perubahan, mengkomitnya dan mendorongnya kembali ke Github. Itu dia.

Penjelasan masalah / kekhawatiran saya

Dalam beberapa minggu kita akan mulai mengerjakan proyek yang agak besar untuk standar kita. Mungkin perlu 2-3 pengembang beberapa bulan untuk menyelesaikannya. Saya akan menjadi pemimpin proyek (manajer proyek dan pengembang utama) dan saya akan bertanggung jawab untuk semuanya. Saya memiliki banyak masalah dengan pendekatan Beyond Compare kami dan saya tidak ingin mengambil jalan ini dengan proyek besar ini yang akan menjadi tanggung jawab saya.

Karena saya ragu kita akan bisa

• mengatur server Git kita sendiri,
• ajarkan semua orang untuk bekerja dengan Git dan
• mempekerjakan Git dengan sukses dalam proyek besar ini,

Saya tertarik jika ada di antara Anda tahu beberapa cara yang baik untuk memungkinkan banyak orang berkolaborasi pada proyek yang sama tanpa menggunakan kontrol sumber atau versi.

Memperbarui

Saya ingin berterima kasih kepada semua orang atas jawaban dan komentar mereka. Ini rencananya:

1. Lakukan rapat dengan pengembang untuk memastikan semua orang teknis merasakan hal yang sama tentang penerapan kontrol sumber. Kami akan membuat poin yang lebih kuat ketika semua orang di belakangnya.
2. Sampaikan gagasan itu kepada bos dan katakan kepadanya bahwa kita benar - benar membutuhkan kendali sumber.
3. Implementasikan sesegera mungkin.

Silakan luangkan satu hari untuk menginstal kontrol versi dan ajari semua orang di proyek untuk menggunakannya. Tidak sesulit itu. Secara pribadi saya tidak menggunakan Git, tetapi saya telah mengatur dan menggunakan sistem kontrol versi lainnya dan mereka tidak terlalu sulit untuk bekerja. Pastikan Anda memilih satu yang terintegrasi dengan lingkungan pengembangan Anda. Ini akan membuatnya menggunakannya secara mulus.

Ini tidak akan membuang waktu.

Waktu Anda akan kehilangan ketika seseorang menimpa atau menghapus beberapa kode akan dikenakan biaya lebih banyak.

Jika Anda tidak memiliki kontrol versi, Anda juga akan menghabiskan banyak waktu untuk mencadangkan proyek Anda dan mengkhawatirkan versi yang dimiliki setiap orang dan versi mana yang ada di server, dll.

Jika Anda perlu meyakinkan atasan Anda membuat perkiraan waktu yang diperlukan untuk mengatur dan memantau solusi kontrol non-versi dan menambahkan biaya penulisan ulang pekerjaan yang hilang beberapa hari. Jangan lupa menambahkan biaya menggabungkan editan secara manual dari 3 pengembang yang bekerja pada file sumber yang sama dan biaya tambahan untuk mendapatkan kesalahan penggabungan tersebut. Kontrol versi yang baik memberi Anda ini secara gratis

Kemudian bandingkan dengan biaya untuk mendapatkan kontrol versi - nihil (jika Anda membuka open source) dan mengaturnya - 3 hari kerja.

Jangan lupa bahwa suatu kesalahan nanti dalam proyek akan menelan biaya lebih dari satu sejak awal. Jika Anda harus mengulang seluruh proyek karena kesalahan yang dapat dilakukan siapa pun, ini akan menelan biaya jauh lebih banyak daripada sekadar waktu menulis ulang, mungkin bos Anda akan kehilangan reputasi perusahaannya.

Jika Anda membagikan sumber pada folder, Anda dapat membagikan repo di sana juga. Bos tidak akan tahu tentang hal itu kecuali ada folder .git di sana.

Anda seharusnya tidak perlu meminta izin untuk melakukan pekerjaan Anda dengan benar - Seth Godin.

Atur kontrol sumber, pelajari cara menggunakannya dan jangan beri tahu atasan Anda. Saya biasanya tidak menganjurkan manajemen yang tidak taat, tetapi dalam hal ini bos Anda bersikap bodoh. Jika Anda benar-benar berpikir git akan terlalu lama untuk dipelajari, maka mulailah dengan sistem kontrol versi yang lebih sederhana seperti svn - git tidak melakukan semua hal keren yang dilakukan git, tetapi bahkan lebih mudah untuk mendapatkan pemahaman dasar tentang git.

Jangan menunggu sampai Anda berada di tengah-tengahnya dan dalam masalah serius sebelum Anda menerapkan sesuatu. Lakukan saja, dan selesaikan pekerjaan.

Diedit untuk menambahkan: Apa pertanyaan Anda sebenarnya adalah 'bagaimana cara saya melakukan kontrol sumber tanpa menggunakan sistem kontrol sumber'. Anda telah mengenali kebutuhannya, dan saya pikir semua orang di sini benar-benar memberi tahu Anda hal yang sama: Tidak ada cara yang waras untuk melakukan kontrol sumber tanpa sistem kontrol sumber.

Saya hanya memiliki ringkasan Anda, tetapi dari itu sepertinya bos Anda membuat argumen waktu dan uang, dan Anda membuat argumen keunggulan teknis. Anda harus membuat argumen waktu dan uang. Pelajari cara git dalam melakukan sesuatu dan melacak sementara waktu dari waktu yang bisa dihematnya, lalu berikan catatan pada bos Anda dengan entri seperti "28/3/2011 harus menunggu 30 menit agar Joe kembali ke bangunan yang dapat dikompilasi jadi kita bisa melakukan penggabungan, perintah git merge terhadap komit terakhirnya sekitar 5 detik "dengan total yang bagus di bagian bawah.

Jika pelatihan dan pengaturan server adalah penghalang bisnis, ada banyak cara untuk mengatur alur kerja git, termasuk memiliki hanya satu anggota tim yang benar-benar menggunakan git, dengan folder bersama untuk "server."

Instruksikan kolega Anda untuk menyalin kode mereka ke folder bersama yang diberikan setiap kali ada saat yang tepat untuk dibagikan. Anda dapat menyimpan repositori untuk masing-masing dari mereka dan melakukan sendiri semua hal kontrol sumber, dan perlahan-lahan menyerahkan semakin banyak tanggung jawab kontrol sumber ke mereka ketika Anda menjadi cukup percaya diri untuk melatih mereka. Itu jauh dari cara ideal untuk melakukannya, tetapi dibandingkan dengan apa yang Anda miliki sekarang, bahkan itu akan menghemat waktu Anda pada penggabungan. Lebih mudah meyakinkan atasan Anda dengan sedikit kurva pembelajaran tim, dan Anda mendapatkan semua manfaat kemunduran dan versi yang Anda inginkan.

Saya tidak melakukan banyak pekerjaan basis data, tetapi untuk pengetahuan saya, penggabungan perubahan skema basis data tidak ditangani dengan baik oleh kontrol sumber. Jika penggabungan tersebut sulit, Anda mungkin ingin mempertimbangkan perubahan proses di mana semua perubahan basis data melalui gatekeeper tunggal.

Ini gila. Anda harus menggunakan VCS bahkan jika Anda bekerja sendiri. Dilarang menggunakan VCS di perusahaan. Lakukan saja. Sekarang juga! Sungguh ... Anda tidak perlu barang-barang canggih sejak awal. GitHub dan GitLab sangat mudah digunakan, tetapi saya yakin Anda dapat menemukan lebih banyak layanan hosting yang kompatibel dengan Windows jika bos Anda bersikeras (meskipun tidak sulit untuk mensetup dan menggunakan Git pada Windows).

Pemikiran yang Anda tanyakan tidak mungkin . Jika banyak orang bekerja pada proyek yang sama tanpa menggunakan kontrol sumber apa pun, Anda akan dengan cepat memiliki banyak masalah, dan karena Anda akan menjadi pengembang utama, Anda harus berurusan dengan mereka.

Dari pengalaman pribadi saya, mengerjakan proyek tanpa kendali sumber menjadi tidak mungkin dari dua pengembang . Bukan tiga. Bukan empat. Dua. Anda mungkin dapat mengelola situasi dengan dua pengembang dalam beberapa keadaan luar biasa : jika pengembang tersebut sangat terorganisir dan profesional, jika mereka berinteraksi dengan baik, jika mereka dapat dengan mudah bertukar (jadi berlokasi di ruangan yang sama pada jam yang sama, setiap waktu) dan jika mereka dapat menghindari kesalahan manusia (memodifikasi secara tidak sengaja file yang dimodifikasi oleh orang lain pada saat yang sama, kemudian menghapus perubahan yang dilakukan oleh orang ini).

Dalam kasus saya, itu selalu merupakan bencana ketika membuat dua orang berpartisipasi dalam sebuah proyek tanpa kontrol versi. Dalam kasus terbaik, satu orang mengirim file yang diubah ke yang kedua, dan yang kedua ini menggunakan alat diff untuk menerapkan perubahan secara manual. Dalam kasus terburuk, satu orang melacak perubahan yang dia lakukan, lalu menerapkannya setiap kali orang kedua memodifikasi kode sumber. Hasil: hilangnya waktu, uang, dan produktivitas yang sangat besar.

Sekarang, dari sudut pandang saya dan pengalaman saya sendiri, saya melihat tiga solusi untuk masalah yang Anda miliki:

• Instal kontrol versi yang mudah digunakan . Saya biasa menginstal CollabNetSubversion sebagai server SVN, cukup cepat dan mudah diatur, jika Anda tidak peduli sama sekali tentang keamanan . Jika Anda menggunakan Visual Studio, AnkhSvn dapat diinstal untuk memungkinkan pengembang memperbarui / melakukan kode sumber dengan mudah dari dalam Visual Studio.

• Yakinkan bos Anda bahwa tes Joel ditulis oleh orang yang tahu betul pekerjaannya, dan jika tes Joel menunjukkan memiliki kontrol versi, ada alasan bagus di baliknya. Lagipula, ia juga dapat memutuskan bahwa pengembang tidak memerlukan alat penyorotan IDE / sintaks untuk menulis kode. Windows Notepad baik-baik saja, bukan? Dan juga, mengapa memiliki akses internet? Yang kita butuhkan adalah PC yang sangat, sangat lama yang menjalankan Windows 3.1.

• Keluarlah dari perusahaan ini , karena saya mempunyai keraguan bahwa segalanya kecuali kontrol versi sempurna dan profesional di sana.

Tidak menggunakan VCS pada proyek yang lebih besar karena Anda tidak ingin menginvestasikan waktu menyiapkannya adalah seperti mengambil perjalanan panjang tanpa alas kaki, karena Anda tidak ingin menginvestasikan waktu memakai sepatu.

VCS apa pun adalah urutan besarnya lebih baik daripada tidak memiliki sama sekali.

Cara mudah mati untuk mengatur VCS adalah untuk mendapatkan TortoiseSVN (karena Anda tampaknya menggunakan C #, saya menganggap Anda menggunakan Windows). Anda membuat repositori di folder lokal yang Anda pilih (navigasikan ke sana, klik kanan> TortoiseSVN> Buat Repositori Di Sini). Bagikan folder ini di jaringan Anda (sebaiknya ada di mesin, yang selalu tersedia) dan lakukan checkout dengan url file://computername/path/to/that/repository. Pengunduhan tidak termasuk, ini membutuhkan waktu tidak lebih dari satu menit untuk menyiapkan.

Jawaban Anda adalah tautan sederhana ke bos Anda ... kirimkan halaman ini kepadanya dan sorot berapa kali kata "keluar" muncul dari para profesional.

Sementara kata "bisu" muncul mungkin beberapa kali, saya yakin bos Anda tidak. Tidak jelas baginya nilai absolut dari ini. Pertanyaan untuk ditanyakan kepadanya adalah pertanyaan terkait bisnis apa yang akan menghasilkan respons yang sama (mungkin seorang akuntan menyarankan, "Lebih baik jangan mengasuransikan gedung ini bahwa Anda terikat dengan max, itu akan menghemat beberapa dolar!")

Kontrol sumber hanya diperlukan jika jumlah pengembang pada proyek> 0. Saya mulai berpikir bahwa orang mungkin mengatakan hal yang sama tentang integrasi berkelanjutan ...

(-:

Karena Anda adalah pengembang ASP.NET, saya sarankan Anda ingin menggunakan salah satu dari Subversion, TFS atau Mercurial - tetapi jujur ​​saja itu tidak masalah yang mana selama Anda menggunakan sesuatu. Berkembang tanpa kontrol versi sama sekali tidak masuk akal - apalagi ketika alat lebih atau kurang bebas untuk digunakan dan overhead untuk menggunakannya sangat minim.

TFS akan memberi Anda tingkat integrasi yang menakjubkan. DVCS (mercurial atau git) mungkin akan memberi Anda fleksibilitas dan kapabilitas terbanyak. Tidak ada alasan untuk TIDAK melakukan ini.

Jika saya mulai dari awal hampir pasti dengan Mercurial.

Setelah Anda memiliki kontrol versi, Anda dapat maju ke server build (TFS, TeamCity) dan dari sana ke integrasi berkelanjutan dan pada saat itu Anda mulai memenangkan hand over fist.

Untuk kembali ke titik awal Anda:

Saya akan menjadi pemimpin proyek (manajer proyek dan pengembang utama) dan saya akan bertanggung jawab untuk semuanya

Benar, Anda bertanggung jawab sehingga Anda memutuskan bahwa Anda memerlukan kontrol versi (karena memang demikian), Anda memutuskan bahwa Anda memerlukan server build (karena memang demikian), Anda memutuskan bahwa Anda perlu memiliki output yang dapat digunakan dari proyek Anda sejak hari pertama (karena jika Anda selalu dapat menyebarkannya - dan karenanya memfasilitasi lebih banyak pengujian) dan bahwa penyebaran akan sangat otomatis - ini adalah langkah-langkah yang Anda ambil untuk memastikan keberhasilan proyek Anda (yang menjadi tanggung jawab Anda ...)

Seperti disebutkan di atas, Anda dapat meletakkan repositori di folder bersama yang sudah Anda miliki. Anda tidak perlu menghabiskan waktu mengkonfigurasi server jika Anda menggunakan sistem kontrol sumber terdistribusi, seperti Git, Mercurial atau Bazaar.

Saya sarankan Anda untuk menggunakan Git, karena Anda sudah memiliki pengalaman dengannya, atau Mercurial, yang memiliki integrasi yang baik ke dalam Visual Studio.

Jika di masa depan bos Anda akan memberitahu Anda untuk beralih ke TFS, itu masih lebih baik daripada tidak memiliki kontrol versi sama sekali.

Kembali di hari-hari Powerbuilder saya, kami memiliki seluruh tim mengerjakan serangkaian aplikasi tanpa menggunakan kontrol sumber. Oh, Powerbuilder memiliki kontrol sumber, tetapi benar - benar menggunakannya adalah omong kosong - jika PB crash saat Anda memeriksa file (dan itu menabrak BANYAK), file kode sumber biner yang dipatenkan itu sekarang tidak dapat diakses. Beberapa flag telah diatur dalam file, dan tidak ada salinan PB lainnya dapat memuatnya, bahkan orang yang sama yang memeriksanya.

Jadi apa yang kami lakukan cukup sederhana. "Hei, Tom, aku akan mengerjakan xyz.pbl. Jadi, jangan membuat perubahan". Dalam skema besar, kami jarang punya masalah.

Dengan anggapan Anda tidak dapat meyakinkan tim Anda untuk mengadopsi kontrol versi atau bahwa bos Anda memahami dalih dan bersikeras bahwa tim berhenti, ada pendekatan yang kurang optimal yang dapat Anda ambil.

Instal Git atau Mercurial di komputer Anda sendiri. Versi pekerjaan Anda sendiri. Saat tim menyinkronkan pekerjaan mereka melalui proses Beyond Compare, tambahkan perubahan ke repo lokal Anda sebagai komit baru. Anda akan selalu dapat mengambil versi kerja sebelumnya dari repo lokal Anda jika sinkronisasi tim merusak sesuatu.

Menggunakan DVCS memastikan bahwa tidak ada persyaratan untuk memiliki server dan tidak ada proses pengaturan yang rumit. Memasang Mercurial dan bangun dan berjalan dengan dasar-dasar seharusnya tidak lebih dari 30 menit.

Ini bukan solusi ideal, tetapi lebih baik daripada tidak sama sekali.

Reaksi awal saya untuk ini adalah bahwa Anda sudah memiliki proses kerja yang ideal tanpa kontrol versi. Anda semua tampaknya memiliki cara yang baik untuk mengelola penggabungan dan sebagainya. Dari perspektif manajerial, ini sepertinya situasi yang baik. Saya sudah bertemu tim yang menggunakan kontrol versi, tetapi harus berjuang dengan proses pengembangan itu sendiri.

Jadi meyakinkan bos Anda hanya mendasarkan argumen Anda pada kontrol versi yang akan menghasilkan "proses yang lebih baik" tidak ada gunanya. Namun ada argumen lain yang jauh lebih penting tentang mengapa Anda perlu menggunakan kontrol versi atau sumber di tempat pertama, yang dapat dengan mudah dihitung dengan uang. Dan itu adalah:

Risiko

Masalahnya bukan bahwa menggunakan kontrol sumber membuat proses pengembangan Anda lebih baik. Ini lebih merupakan masalah yang akan terjadi jika Anda tidak memiliki kendali sumber sama sekali. Apa risikonya?

Katakanlah seseorang keliru menghapus fungsi dalam kode atau seluruh file? Berapa biaya perbaikan? Semoga seseorang memiliki yang tertutup, jadi perbaikannya kecil.

Tetapi apa yang terjadi jika tidak ada orang yang memiliki cadangan file yang hilang? Berapa banyak jam kerja yang harus dikeluarkan untuk memperbaiki itu? Itu mungkin akan memakan waktu berhari-hari, dan itu mudah dihitung dalam rata-rata jam kerja. Apakah itu terlalu banyak untuk perusahaan? Mungkinkah ini diperbaiki lebih cepat?

Ya, dengan semacam kontrol sumber. Sebaliknya: berapa lama waktu yang dibutuhkan untuk mengatur kontrol versi dan mendukungnya? Kebanyakan open source seperti git atau mercurial tidak membutuhkan banyak waktu untuk mengatur. Mengajari orang cara menggunakannya tidak akan sulit, mengingat Anda sudah tahu cara bergabung dengan Beyond Compare dan Anda "check in" ke folder bersama. Ini adalah biaya pengaturan satu kali. Apakah jumlah jam kerja pria ini lebih sedikit daripada risiko yang dimilikinya? Jika ini benar maka menggunakan kontrol sumber harus menjadi prioritas.

Selama Anda dapat menunjukkan alasan bisnis mengapa penting untuk memiliki kontrol sumber, dan manajemen risiko akan menjadi salah satu faktor yang sangat besar, yang akan meyakinkan sebagian besar bos.

Gunakan Sistem Kontrol Versi Terdistribusi seperti git dan gunakan mesin folder bersama Anda untuk menyimpan repositori referensi. Inilah alasannya:

Setiap klon adalah cadangan

Jika hard drive server macet, semua orang memiliki salinan, siap untuk digunakan pada drive atau server baru. Karena perusahaan Anda tidak serius tentang kontrol versi, saya kira itu mungkin hampir sama dengan cadangan.

Referensi umum

Memiliki repositori utama dengan cabang master memungkinkan untuk mengetahui versi yang memiliki kata terakhir. Ini memecahkan "Anda telah menguji perubahan Anda terhadap versi Franck, tetapi apakah Anda juga memiliki versi John? Dan bagaimana Anda menggabungkannya?".

Memberikan lebih nyaman

Pelanggan menginginkan versi alpha hari ini? Nah, Anda dapat menguji apakah master cukup stabil dan mengirimkannya. Jika tidak dan Anda tidak punya waktu untuk memperbaikinya, kembali saja dan dapatkan versi yang lebih lama tetapi lebih stabil. Anda tidak dapat melakukannya jika hanya memiliki versi terbaru.

Kembali ke masa lalu dan perbaiki kesalahan Anda

Penggabungan manual Anda memiliki masalah yang hanya Anda lihat setelah beberapa hari, tetapi Anda telah menimpa konten folder bersama Anda? Tanpa VSC Anda tidak memiliki riwayat sehingga Anda tidak dapat dengan mudah kembali ke titik di mana Anda dapat memeriksa kesalahan yang Anda buat dan memperbaikinya. Kode tidak seperti gambar, itu seperti film: kode itu berkembang seiring waktu. Anda dapat mengekstrak gambar dari film. Anda tidak dapat mengekstrak film dari gambar.

Temukan bug lebih mudah

Bug muncul tetapi Anda tidak benar-benar memperhatikannya saat diperkenalkan, jadi Anda tidak dapat memperbaikinya saat kode "panas". Sekarang Anda tidak benar-benar tahu perubahan mana yang memperkenalkannya, sehingga bisa berasal dari beberapa lokasi berbeda dalam kode. Butuh berjam-jam hanya untuk menemukan di mana mencarinya. Dengan git, Anda bisa saja mengembangkan tes untuk mengatakan jika bug terjadi pada versi tertentu, dan gunakan git bissectuntuk menemukan komit yang tepat yang memperkenalkan bug. Alih-alih mencari ribuan baris kode, Anda sekarang tahu itu terletak di 10 baris yang berubah, dan Anda dapat menyimpan tes di suite pengujian untuk memastikan bug tidak diperkenalkan lagi.

Setiap pengembang bertanggung jawab atas pekerjaannya sendiri

Jika Anda adalah pemimpin tim, dan tidak memiliki VCS, kemungkinan besar Anda harus melakukan pekerjaan kotor, penggabungan. Jika Anda melakukannya sendiri, Anda mungkin tidak tahu segalanya tentang semua perubahan dan dapat menyebabkan kesalahan. Sebaliknya, jika Anda selalu bertanya kepada orang-orang yang menulis kode untuk mengumpulkan dengan Anda setiap kali ada kode untuk digabungkan, maka saat itulah mereka tidak akan menggunakan untuk menghasilkan kode baru.

Dengan VCS, dalam alur kerja sederhana, pengembang hanya perlu mengurus pekerjaannya, dan satu sumber perubahan eksternal: cabang master. Mungkin ada 1 atau 100 orang yang melakukan di cabang utama, itu sama. Untuk dapat mendorong perubahannya, ia harus menyesuaikannya dengan perubahan terbaru yang dilakukan oleh orang lain. Mungkin tampaknya perlu waktu lebih lama untuk mendorong kode, tetapi itu karena Anda juga melakukan penggabungan yang akan memakan waktu.

Perbedaannya adalah bahwa penggabungan dilakukan oleh orang yang melakukan perubahan, siapa yang tahu kode itu paling baik karena dia telah menulisnya.

Siapa yang menulis kode itu?

Ada bug di sini, tetapi siapa yang telah menulis baris kode tertentu? Sulit untuk diingat, terutama jika proyek itu berlangsung beberapa bulan. git blameakan memberi tahu Anda siapa dan kapan kalimat itu ditulis, sehingga Anda dapat bertanya kepada orang yang tepat, dan tidak ada "Saya tidak ingat menulis itu".

Proyek ini semakin besar

Pelanggan menginginkan lebih banyak fitur dan Anda tim yang terlalu kecil, Anda memerlukan pengembang lain. Bagaimana Anda mengelola peningkatan kompleksitas gabungan tanpa VSC?

Perubahan mendesak

Pelanggan menelepon dan meminta perbaikan bug penting untuk produksi, tetapi Anda saat ini sedang mengerjakan fitur baru. Hanya git stashuntuk mengesampingkan perubahan Anda, atau mengkomitnya di cabang baru dan mendorong perubahan dan Anda siap untuk mulai bekerja pada perbaikan yang mendesak, tanpa takut kehilangan pekerjaan Anda yang tertunda.

Itu bekerja 10 menit yang lalu

Anda melakukan beberapa perubahan secara lokal dan sesuatu yang berhasil 10 menit yang lalu berhenti berfungsi. Tanpa VCS Anda akan menatap kode atau paling baik, melakukan salinan dari versi referensi, dan berbeda untuk melihat apa yang Anda ubah. Oh, tunggu, referensi berubah sejak saya mulai bekerja, jadi saya tidak bisa lagi berbeda. Dan saya tidak berpikir untuk menyimpan salinan asli dari kode tempat saya mendasarkan perubahan saya.

Dengan VCS, Anda langsung melakukan sesuatu seperti git diffitu, dan mengubah Anda dibandingkan dengan versi yang tepat dari kode yang Anda gunakan.

Saya harus menyimpan log debug saya

Jadi Anda orang jahat dan tidak menggunakan logging? Anda harus memercikkan printfsemua basis kode Anda sampai Anda menemukan semua bagian dari bug jahat itu? Sekarang Anda menemukan satu, perbaiki, tetapi ingin tetap menjaga kode debug Anda untuk memperbaiki masalah yang tersisa.

Tanpa VCS, Anda harus menyalin file, membentangkan kode debug (yang dapat menambah beberapa kesalahan pengeditan), mendorongnya, dan mengembalikan file yang dicadangkan. Oh, tapi sepertinya beberapa kode debug masuk.

Dengan git, Anda hanya git add --patchdan memilih beberapa baris kode yang ingin Anda masukkan dalam komit Anda, dan hanya dapat melakukan itu. Kemudian Anda melanjutkan pekerjaan Anda dan masih memiliki kode debug Anda. Anda tidak harus menyentuh kode, jadi tidak ada kesalahan salin / tempel.

Bola besar lumpur

Tanpa VCS, orang-orang bekerja di pihak mereka, dan memberi Anda banyak perubahan, kadang-kadang tidak berhubungan. Ketika ada terlalu banyak kode untuk diperiksa, sulit untuk menemukan bug.

VCS memungkinkan Anda melakukan perubahan kecil dan bertahap, dan memberi Anda changelog. Changelog sangat penting: orang harus memberi tahu di sana mengapa mereka melakukan perubahan, bukan apa perubahan itu ( pertanyaan apa yang sudah dijawab oleh perubahan kode itu sendiri). Ini berarti ketika Anda memeriksa beberapa kode fitur baru misalnya, Anda tidak harus membaca banyak perubahan campuran yang tidak terkait seperti perbaikan bug yang tidak terkait. Ini membantu memfokuskan pada kode yang Anda pedulikan.

Jika saya memberi Anda 100 kentang 1 demi 1, dan satu busuk, Anda akan segera menemukannya. Sekarang jika saya membuang 100 kentang di depan Anda dan meminta Anda untuk menemukan yang busuk, itu bukan tugas yang sama.

Lekukan

Semoga Anda memiliki kebijakan gaya pengkodean yang baik, jika tidak lekukan perubahan akan membuat Anda gila jika Anda bergabung dengan tangan. Tentu, Anda dapat mengabaikan spasi putih dalam perubahan (tetapi tidak dalam bahasa saat lekukan diperhitungkan, seperti Python). Tetapi kemudian Anda akan mendapatkan kode yang tampak aneh sulit dibaca.

Anda adalah pemimpin proyek

Jika Anda pemimpin, ini berarti Anda akan disalahkan jika semuanya tidak berhasil. Jika Anda tidak bisa merasa nyaman dengan situasi ini karena atasan Anda masih tidak dapat memahami bahwa menggunakan alat yang tepat untuk pekerjaan yang tepat sepadan, maka paling tidak, saya akan menolak untuk menjadi pemimpin dari kegagalan yang dapat diprediksi.

Gunakan dropbox, ini memiliki riwayat versi otomatis. Anda dapat membagikan folder-dropbox antara banyak pengguna.

Edit

Anda juga dapat mengunduh klien TortoiseSVN, dan membuat "repositori lokal" pada drive jaringan. Kemudian orang dapat memeriksa kode sumber berdasarkan lokasi folder jaringan.