Mengapa saya harus menggunakan kontrol versi? [Tutup]

Saya sedang membaca blog di mana penulisnya mengatakan ini

"Kode tidak ada kecuali dicek ke dalam sistem kontrol versi. Gunakan kontrol versi untuk semua yang Anda lakukan. Kontrol versi apa pun, SVN, Git, bahkan CVS, kuasai dan gunakan."

Saya tidak pernah menggunakan kontrol versi apa pun dan menurut saya tidak sebagus itu. Saya telah mencari di Google dan melihatnya sebelumnya, tetapi saya hanya perlu memasukkannya ke dalam istilah anak-anak jika Anda mau.

Seperti yang saya pahami sekarang, hal-hal seperti SVN adalah untuk menyimpan kode Anda secara online agar sekelompok pengguna atau pengembang lain memiliki akses ke kode yang sama. Setelah Anda memperbarui beberapa kode, Anda dapat mengirimkan versi baru dan SVN akan menyimpan salinan kode lama serta yang baru yang Anda perbarui.

Apakah ini ide dasarnya atau apakah saya benar-benar salah?

Jika saya benar, maka mungkin tidak banyak gunanya jika saya:

• Jangan biarkan orang lain mengerjakan kode.
• Jangan berencana membiarkan orang lain mengetahui kode tersebut.

Pernahkah kamu:

• Membuat perubahan pada kode, menyadari bahwa itu adalah kesalahan dan ingin mengembalikannya?
• Kehilangan kode atau memiliki cadangan yang terlalu lama?
• Harus mempertahankan beberapa versi produk?
• Ingin melihat perbedaan antara dua (atau lebih) versi kode Anda?
• Ingin membuktikan bahwa perubahan tertentu merusak atau memperbaiki bagian kode?
• Ingin meninjau sejarah beberapa kode?
• Ingin mengirimkan perubahan ke kode orang lain?
• Ingin membagikan kode Anda, atau mengizinkan orang lain mengerjakan kode Anda?
• Ingin melihat seberapa banyak pekerjaan yang dilakukan, dan di mana, kapan, dan oleh siapa?
• Ingin bereksperimen dengan fitur baru tanpa mengganggu kode yang berfungsi?

Dalam kasus ini, dan tidak diragukan lagi, sistem kontrol versi akan membuat hidup Anda lebih mudah.

Untuk salah mengutip teman: Alat beradab untuk zaman yang beradab.

Bahkan jika Anda bekerja sendiri, Anda bisa mendapatkan keuntungan dari kendali sumber. Antara lain karena alasan ini:

• Anda tidak akan kehilangan apapun. Saya tidak pernah lagi mengomentari kode. Saya hanya menghapusnya. Itu tidak mengacaukan layar saya, dan tidak hilang. Saya dapat memulihkannya dengan memeriksa komit lama.

• Anda bisa bereksperimen sesuka hati. Jika tidak menyelesaikan masalah, kembalikan.

• Anda dapat melihat versi kode sebelumnya untuk mengetahui kapan dan di mana bug diperkenalkan. git bisectbagus dalam hal itu.

• Lebih banyak fitur "lanjutan" seperti percabangan dan penggabungan memungkinkan Anda memiliki beberapa baris pengembangan yang paralel. Anda dapat bekerja dalam dua fitur secara bersamaan tanpa gangguan dan beralih tanpa banyak kesulitan.

• Anda dapat melihat "apa yang berubah". Ini mungkin terdengar mendasar, tetapi itu adalah sesuatu yang sering saya periksa. Saya sangat sering memulai alur kerja satu orang saya dengan: apa yang saya lakukan kemarin?

Silakan dan coba saja. Mulailah perlahan-lahan dengan fitur-fitur dasar dan pelajari yang lain sambil Anda pergi. Anda akan segera menemukan bahwa Anda tidak akan pernah ingin kembali ke "masa kegelapan" tanpa VCS.

Jika Anda menginginkan VCS lokal, Anda dapat mengatur server subversi Anda sendiri (seperti yang saya lakukan di masa lalu), tetapi hari ini saya akan merekomendasikan penggunaan git. Jauh lebih sederhana. Cukup cdke direktori kode Anda dan jalankan:

git init

Selamat Datang di klub.

Kontrol versi adalah alat langka yang menurut saya mutlak diperlukan, bahkan jika Anda hanya menggunakannya sebagai pengembang tunggal. Beberapa orang mengatakan bahwa itu adalah alat yang Anda jalani dan mati, saya setuju dengan pernyataan itu.

Anda mungkin menggunakan kontrol versi sekarang, meskipun Anda tidak mengetahuinya. Apakah Anda memiliki folder yang bertuliskan "XXX Php Code (Desember)" atau "XXX.php.bak.2"? Ini sudah merupakan bentuk kontrol versi. Sistem kontrol versi yang baik akan menangani ini untuk Anda secara otomatis. Anda akan dapat memutar kembali ke titik waktu mana pun (saat Anda memiliki data yang sudah diperiksa) dan dapat melihat salinan persis dari data itu.

Selanjutnya, jika Anda mengadopsi sistem seperti subversi, dan menggunakan repositori jarak jauh (seperti yang ada di server yang Anda miliki), Anda akan memiliki tempat untuk menyimpan semua kode Anda. Perlu salinan kode Anda di tempat lain? Tidak masalah, lihat saja. Hard drive crash di rumah? Bukan masalah (setidaknya dengan kode sumber Anda).

Bahkan jika Anda tidak menggunakan kontrol versi sekarang, kemungkinan besar Anda akan menggunakannya pada suatu saat nanti dalam karir Anda dan Anda bisa mendapatkan keuntungan dengan menjadi lebih nyaman dengan prinsip-prinsip tersebut sekarang.

Bahkan bekerja sendiri, pernahkah ini terjadi? Anda menjalankan aplikasi Anda, dan ada sesuatu yang tidak berfungsi dan Anda berkata "itu berhasil kemarin, dan saya bersumpah saya tidak menyentuh kelas / metode itu." Jika Anda memeriksa kode secara teratur, perbedaan versi cepat akan menunjukkan dengan tepat apa yang telah berubah pada hari terakhir.

Berikut adalah skenario yang mungkin menggambarkan kegunaan kontrol sumber bahkan jika Anda bekerja sendiri.

Klien Anda meminta Anda untuk menerapkan modifikasi ambisius pada situs web. Ini akan memakan waktu beberapa minggu, dan melibatkan pengeditan pada banyak halaman. Anda mulai bekerja.

Anda 50% selesai dengan tugas ini ketika klien menelepon dan memberitahu Anda untuk menghentikan apa yang Anda lakukan untuk membuat perubahan yang lebih kecil namun mendesak ke situs. Anda belum selesai dengan tugas yang lebih besar, jadi belum siap untuk ditayangkan, dan klien tidak sabar menunggu perubahan yang lebih kecil. Tapi dia juga ingin perubahan kecil digabungkan ke dalam pekerjaan Anda untuk perubahan yang lebih besar.

Mungkin Anda sedang mengerjakan tugas besar di folder terpisah yang berisi salinan situs web. Sekarang Anda harus mencari cara untuk melakukan perubahan kecil dengan cara yang dapat diterapkan dengan cepat. Anda bekerja keras dan menyelesaikannya. Klien menelepon kembali dengan permintaan perbaikan lebih lanjut. Anda melakukan ini juga dan menerapkannya. Semuanya baik-baik saja.

Sekarang Anda harus menggabungkannya ke dalam pekerjaan yang sedang berlangsung untuk perubahan besar. Apa yang Anda ubah untuk pekerjaan yang mendesak? Anda bekerja terlalu cepat untuk membuat catatan. Dan Anda tidak bisa begitu saja membedakan kedua direktori dengan mudah sekarang karena keduanya memiliki perubahan relatif terhadap baseline tempat Anda memulai.

Skenario di atas menunjukkan bahwa kendali sumber bisa menjadi alat yang hebat, bahkan jika Anda bekerja sendiri.

• Anda dapat menggunakan cabang untuk mengerjakan tugas jangka panjang lalu menggabungkan cabang kembali ke baris utama setelah selesai.
• Anda dapat membandingkan seluruh kumpulan file dengan cabang lain atau dengan revisi sebelumnya untuk melihat apa yang berbeda.
• Anda dapat melacak pekerjaan dari waktu ke waktu (yang bagus untuk pelaporan dan pembuatan faktur).
• Anda dapat memulihkan revisi file apa pun berdasarkan tanggal atau pencapaian yang Anda tentukan.

Untuk pekerjaan solo, Subversion atau Git direkomendasikan. Siapa pun bebas untuk memilih salah satu, tetapi keduanya jelas lebih baik daripada tidak menggunakan kontrol versi apa pun. Buku-buku bagus adalah " Kontrol Versi Pragmatis menggunakan Subversion, Edisi ke-2 " oleh Mike Mason atau " Kontrol Versi Pragmatis Menggunakan Git " oleh Travis Swicegood.

Penulis asli: Bill Karwin

Bahkan sebagai kontrol sumber pengembang tunggal menawarkan keuntungan besar. Ini memungkinkan Anda untuk menyimpan riwayat kode Anda dan kembali ke versi sebelumnya dari perangkat lunak Anda kapan saja. Hal ini memungkinkan Anda memiliki fleksibilitas yang tak kenal takut untuk bereksperimen karena Anda selalu dapat memulihkan ke versi lain dari kode sumber Anda yang berfungsi.

Ini seperti memiliki tombol "urungkan" besar di sepanjang baris kode pertama Anda.

Kontrol versi hampir tidak mungkin untuk hidup tanpanya setelah Anda mulai menggunakannya. Sangat diperlukan jika lebih dari satu pengembang bekerja pada basis kode yang sama ... tetapi juga sangat berguna untuk satu pengembang.

Ini melacak perubahan dalam kode Anda dan memungkinkan Anda untuk memutar kembali ke versi sebelumnya. Ini membebaskan Anda untuk bereksperimen dengan pengetahuan bahwa jika ada yang rusak, Anda dapat membatalkan perubahan Anda.

Anda mendapatkan keamanan (dalam arti memiliki cadangan kode Anda) dan versi kode Anda (dengan asumsi Anda terbiasa melakukan perubahan sering). Keduanya adalah hal yang sangat baik bahkan jika tidak ada orang lain yang akhirnya mengerjakan kode dengan Anda ...

Kontrol versi sangat bagus untuk memeriksa versi sebelumnya, meskipun Anda bekerja sendiri. Misalnya, jika Anda tidak sengaja menghapus kode atau file, Anda bisa mendapatkannya kembali; atau Anda dapat membandingkan versi sebelumnya untuk melihat mengapa bug baru masuk. Ini juga bagus jika Anda adalah satu orang yang bekerja di banyak lokasi.

Favorit pribadi saya adalah git.

Ada sejumlah alasan untuk menggunakan kontrol versi, meskipun Anda satu-satunya orang yang akan menyentuh kode tersebut.

• Cadangan - bagaimana jika hard-drive Anda rusak? Apakah Anda punya salinannya di mana saja?
• Riwayat revisi - Apakah Anda saat ini menyimpan salinan kode di folder yang berbeda? Kontrol versi memberi Anda kemampuan untuk melacak perubahan Anda dari waktu ke waktu dan dengan mudah membedakan berbagai revisi, menggabungkan, mengembalikan perubahan, dll. Menggunakan alat.
• Branches - kemampuan untuk menguji beberapa perubahan, tetap melacak apa yang Anda lakukan, dan kemudian memutuskan apakah Anda ingin menyimpannya atau bergabung ke dalam proyek utama atau membuangnya begitu saja.

Jika Anda menyimpan kode Anda di bawah kontrol versi, maka akan sangat mudah untuk melihat file mana yang telah Anda ubah (atau lupa untuk menambahkan ke baseline).

Sesuatu yang tampaknya tidak disebutkan secara eksplisit oleh orang lain adalah penandaan atau pelabelan rilis. Jika Anda memiliki klien yang menggunakan perangkat lunak versi 1 dan Anda sibuk mengerjakan versi 2, apa yang Anda lakukan ketika klien melaporkan bug dan Anda perlu membangun versi 1.1?

Sistem kendali sumber akan memungkinkan Anda memberi label pada setiap rilis yang Anda buat sehingga Anda dapat kembali lagi nanti, membuat perbaikan (dan menggabungkan perbaikan itu ke dalam kode versi 2 yang baru) dan membuat rilis baru tanpa khawatir bahwa Anda mungkin tidak sengaja mengirimkan sesuatu yang belum siap.

Kontrol sumber adalah bagian inti dari pengembangan perangkat lunak modern. Jika Anda tidak menggunakannya (bahkan untuk proyek pribadi karena semakin banyak pengalaman yang Anda miliki semakin baik) Anda melakukan sesuatu yang salah.

Biasanya salah satu pertanyaan pertama yang saya tanyakan saat diwawancarai untuk suatu pekerjaan adalah "Apa yang Anda gunakan untuk kontrol sumber?" Sejauh ini hanya satu tempat yang mengatakan "Tidak ada" tetapi mereka berencana untuk memperbaikinya "Segera sekarang ..."

Fakta bahwa pengembang lain berpartisipasi atau tidak sama sekali ortogonal dengan kebutuhan sistem kontrol versi.

Anda bisa menjadi satu-satunya pengembang tetapi masih akan mendapatkan keuntungan dari:

• jejak sejarah dari semua perubahan Anda
• kemampuan untuk mundur dan maju dalam sejarah itu
• kemampuan untuk bereksperimen dengan sumber dan saat masih memiliki versi yang berfungsi (bercabang)
• salinan cadangan (terutama jika Anda menggunakan mesin yang berbeda sebagai server kendali sumber, dan bahkan lebih jika mesin itu dicadangkan secara teratur)

Sekarang, jika Anda memiliki grup yang berkembang pada kontrol versi basis kode yang sama masih lebih diperlukan

• orang dapat mengedit file yang sama pada waktu yang sama (tergantung pada sistem tertentu, tetapi kebanyakan yang waras memungkinkan Anda untuk melakukan ini)
• Anda dapat mengetahui siapa yang melakukan apa pada kode tersebut kapan

Ketika ada lebih banyak orang yang terlibat, akan lebih relevan alat kontrol versi mana yang Anda pilih, bergantung pada gaya pengembangan.

Ini juga tentang membuat cadangan file lama yang mengapa itu disebut "Subversion". Jadi Anda dapat mengelola beberapa versi pekerjaan Anda di mana Anda dapat mengembalikan (mengembalikan) dan mengelola implementasi yang berbeda (percabangan).

Anda mungkin menemukan bahwa Anda memiliki versi yang berfungsi dari program Anda.

Anda memutuskan untuk menambahkan beberapa fitur baru selama periode waktu tertentu dan Anda merilisnya.

Anda mulai mendapatkan laporan bug yang memengaruhi beberapa kode yang Anda pikir tidak Anda sentuh.

Dengan menggunakan SVN, misalnya, Anda dapat kembali ke versi lama, dan memeriksa apakah ada bug baru. Setelah Anda menemukan versi yang memperkenalkan bug, akan lebih mudah untuk memperbaikinya karena Anda dapat membandingkan versi yang berfungsi dengan yang tidak berfungsi dan melihat apa yang berubah, maka pencarian akan dipersempit.

Kontrol sumber memiliki banyak kegunaan, bahkan jika Anda adalah satu-satunya pengembang.

Sepertinya Anda sedang mencari sesuatu yang lebih ringan. Lihat Mercurial ( buku referensi mengagumkan ). Saya menggunakannya untuk segala hal, dari kode sumber hingga korespondensi pribadi.

Beberapa manfaat:

• Tombol Undo raksasa, sehingga Anda dapat mengembalikan hari-hari tenang minggu lalu saat kode benar-benar berjalan
• Kode yang dibuang. Tidak yakin apakah ini cara terbaik untuk melakukan sesuatu? Buat cabang dan percobaan. Tidak seorang pun kecuali Anda yang perlu mengetahuinya jika Anda menggunakan DVCS seperti lincah.
• Pengembangan tersinkronisasi. Saya mengembangkan di 4 komputer yang berbeda. Saya mendorong dan menarik di antara mereka untuk menjaga saat ini, jadi tidak peduli di mana saya berada, saya punya versi terbaru.

Bahkan jika Anda belum berada dalam situasi di mana Anda membutuhkan versi lama dari program Anda, memiliki kontrol sumber memberi Anda kepercayaan diri yang lebih besar untuk membuat perubahan besar.

Saya mendapati diri saya melakukan pemfaktoran ulang yang lebih agresif setelah menggunakan kontrol sumber karena saya selalu tahu bahwa versi yang berfungsi dapat dengan mudah dipulihkan.

Saya juga baru saja mulai tertarik dengan kontrol versi. Dalam sistem kontrol versi, Anda memiliki konsep repositori untuk kode Anda. Banyak perintah shell baru dipelajari dengan sangat cepat sehingga Anda dapat berinteraksi dengan repositori ini.

Setelah Anda menyimpan kode Anda ke sebuah file, Anda kemudian dapat mengkomit ini ke repositori proyek Anda. Saat Anda mengembangkan kode dan melakukan perubahan, repositori mengembangkan serangkaian revisi . Anda dapat mengakses semua ini dengan check out revisi. Jika Anda bekerja sendiri, tidak mungkin Anda akan melakukan banyak pemeriksaan kecuali Anda kehilangan file kode atau ingin bekerja di komputer lain. Dalam kasus ini, Anda biasanya akan memeriksa revisi terbaru dari semua file.

Untuk bagian saya sendiri, saya tidak lagi menyimpan file atau folder bernama 'project_old' ketika saya memutuskan untuk melakukan refactor sesuatu. Setiap perubahan yang saya buat disimpan secara bertahap dan saya akan selalu dapat melangkah mundur ke proyek yang bekerja secara keseluruhan. Saya jarang menggunakan FTP untuk menerapkan sekarang karena saya baru saja memeriksa kode saya melalui ssh. Hanya file yang saya ubah yang diunduh dan jika saya perlu memuat ulang di server, terminal sudah ada di sana.

Saya menemukan pembicaraan di GIT ini sangat instruktif; http://www.youtube.com/watch?v=4XpnKHJAok8

Ini adalah pembicaraan Google di mana Linus Torvalds membuat argumen untuk menggunakan satu sistem kontrol versi di atas yang lain. Dalam melakukannya, dia menjelaskan cara kerjanya menggunakan konsep dan kemudian membandingkan berbagai cara penerapannya.

Anda mungkin menginginkan sesuatu seperti subversi meskipun Anda bekerja sendiri sehingga Anda memiliki riwayat semua perubahan Anda. Anda mungkin ingin melihat seperti apa potongan kode pada suatu waktu untuk mengingat mengapa Anda membuat perubahan.

Memiliki kendali sumber juga berguna saat Anda sering check-in. Jika Anda sering check-in, Anda akan selalu dalam kondisi untuk sering melakukan roll back juga. Sering kali Anda dapat mulai menempuh satu jalan untuk memecahkan masalah dan kemudian menyadari bahwa itu adalah jalan yang salah. Sering kali Anda bisa terus menggonggong di jalan yang salah dan akhirnya membangun solusi yang buruk - hanya karena Anda tidak ingin kehilangan semua pekerjaan Anda. Dengan sering check-in, poin terakhir dari "kebahagiaan" tidak jauh sehingga meskipun Anda salah jalan, Anda selalu dapat memutar kembali dan mencoba lagi dan membuat solusi yang lebih elegan dan sederhana. Itu selalu merupakan hal yang baik sehingga Anda dapat memahami dan mempertahankan apa yang Anda tulis di masa depan.

Itu tergantung pada ukuran proyek dan seberapa sering Anda berubah pikiran tentang bagian-bagiannya. Untuk proyek kecil di mana Anda baru saja menyelesaikan sesuatu secara linier, kontrol versi mungkin tidak akan banyak membantu (meskipun jika Anda tidak sengaja menghapus atau merusak file tanpa kontrol versi, Anda akan menangis).

Tetapi beberapa minggu yang lalu saya bertemu dengan seorang teman yang sedang menulis proyek hobi yang sangat besar sendiri. Dia memiliki sepuluh atau dua puluh salinan kodenya, dengan sufiks seperti "X1", "X2", "test", "lebih cepat" dan seterusnya.

Jika Anda telah membuat lebih dari dua salinan kode Anda , Anda memerlukan kontrol versi . Sistem kontrol versi yang baik memungkinkan Anda membatalkan perubahan yang Anda buat beberapa waktu lalu tanpa membatalkan hal-hal yang Anda lakukan setelah melakukan perubahan itu. Ini memungkinkan Anda melihat kapan perubahan tertentu dibuat. Ini memungkinkan Anda membagi kode Anda menjadi dua "jalur" (misalnya satu untuk menguji ide baru, yang lain untuk menyimpan kode "yang dicoba dan dipercaya" hingga Anda selesai menguji) dan kemudian menggabungkannya kembali.

Ini adalah tahun 2019. Saya menemui keberatan, pada tanggal yang relatif terlambat ini, untuk menggunakan Git; keberatan Saya melihat beberapa peningkatan di sini. Diskusi ini sangat memperjelas pentingnya menggunakan kontrol sumber daripada hanya membuat salinan cadangan bernama. Satu poin kuncinya adalah penggunaan kontrol sumber meskipun kami memiliki proyek pengembang tunggal. Tidak ada yang sempurna. Anda membuat kesalahan. Jika Anda luar biasa baik dan pintar, Anda akan mengembangkan aplikasi yang lebih kompleks; tetapi Anda masih akan membuat beberapa kesalahan dan ini menanganinya. Ya ampun, Pete! Saya tidak pernah menggunakan Linux tetapi saya pikir kita semua menghormati kecerdasan teknis yang hebat dari Linus Torvalds. Dia menyadari pentingnya kendali sumber dan dia memberikan kontribusi penting pada dimulainya Git. Itulah poin ringkasan untuk semua alasan yang diberikan di sini. Torvalds mengerti: kontrol sumber sangat penting: gunakan kontrol sumber. Terima kasih untuk semua yang telah mengomentari topik yang telah berjalan lama ini.