Kontrol sumber apa yang saya perlukan untuk proyek besar di perusahaan biasa? [Tutup]

Saya tahu Git bagus untuk proyek sumber terbuka. Tapi saya bertanya-tanya: untuk perusahaan dengan 20 programmer yang bekerja pada proyek 1 tahun, sistem kontrol sumber mana yang diinginkan? Dari apa yang saya dengar, Git menggunakan tarikan; bukankah itu kurang diinginkan untuk perlu melalui orang lain untuk mendapatkan perubahan Anda di bagasi utama? Apalagi ketika semua orang bekerja pada saat yang sama?

Itu hanya contoh yang saya pikirkan. Saya tahu cara menggunakan SVN tetapi bahkan pada pekerjaan terakhir saya, kami tidak menggunakannya pada proyek kami, karena semuanya dilakukan dalam PHP dan itu biasanya proyek mandiri 1 minggu. Saya hanya punya SVN untuk kode lokal saya dan tidak perlu menggunakannya dengan orang lain.

Jadi apa kontrol sumber yang baik, dan khususnya mengapa itu baik untuk ini?

Gunakan apa pun yang nyaman dengan tim Anda. Semua sistem Kontrol Versi melakukan kira-kira hal yang sama dengan cara yang serupa; tidak ada alasan untuk menemukan kembali roda karena "itu mungkin bekerja lebih baik". Jika tim Anda tidak nyaman dengan apa pun, maka pilih opsi yang memiliki integrasi paling mudah dengan IDE standar tim Anda.

Mercurial luar biasa, terdistribusi, dan gratis.

Saya pikir itu tergantung pada tingkat dukungan yang Anda butuhkan.

Saya menggunakan git di rumah untuk proyek-proyek saya yang menyenangkan ketika memiliki masalah menghabiskan waktu, tetapi saya dapat menghabiskan waktu mempelajari apa yang saya butuhkan untuk memperbaikinya.

Di tempat kerja kami menggunakan Perforce karena memiliki dukungan teknis 24/7 sangat penting. Kami memiliki orang yang mengerjakan kode di New York, Jerman, Irlandia, dan Jepang sepanjang waktu. Jika ada masalah kita harus mendapatkan jawaban ASAP. Dalam pengalaman saya, orang-orang di Perforce benar-benar tahu apa yang mereka lakukan dan menerima saran.

Sementara saya berpikir bahwa pertanyaan ini luas dan harus alamat berdasarkan per-perusahaan, berdasarkan kerangka kerja TI Anda dan struktur jaringan / pengembangan, saya pikir bahwa aspek yang paling penting dari memilih kontrol sumber / versi bukanlah aplikasi yang Anda gunakan, tetapi apakah itu digunakan secara praktis terstruktur dan ditegakkan.

Struktur dan penegakan penggunaan adalah aspek terpenting dari kontrol versi.

Rencanakan ke depan dan buat semua orang ikut bergabung. Berlaku penggunaan. Tidak hanya dengan programmer, tetapi dengan segala sesuatu yang berkaitan dengan proyek (dokumen, gambar, dll.).

SVN adalah aplikasi yang bagus, dan dapat diintegrasikan dengan banyak add-on (termasuk pelacakan bug / tugas), tidak memerlukan server terpisah dan gratis!

Ada aplikasi kontrol sumber lain yang bagus juga, seperti yang dikatakan @EricBoersma:

Gunakan apa pun yang nyaman dengan tim Anda.

Hanya memiliki proses dan praktik terbaik di tempat, dan membeli dari mereka yang dapat menegakkannya.

Anda memiliki beberapa kesalahpahaman besar tentang cara kerja git. Mengirim permintaan tarik ke penjaga gerbang hanya satu cara untuk melakukannya. Ada banyak cara lain untuk mengaturnya, termasuk persis seperti svn, yang merupakan berapa banyak orang yang memulai sebelum mereka merasa cukup nyaman untuk menyesuaikan. Dengan DVCS seperti git, Anda memiliki cukup opsi untuk menyusun kontrol sumber Anda di sekitar alur kerja Anda, daripada sebaliknya.

Saya dulu memiliki pandangan bahwa kontrol sumber hanyalah alat, dan bahwa setiap produk melakukan hal yang kurang lebih sama. Dan kemudian titik dari sistem kontrol versi terdistribusi ini diklik dengan saya.

Kontrol versi terdistribusi memungkinkan Anda untuk memiliki lebih dari satu repositori pusat. Bayangkan perubahan kode bermigrasi dari repositori pengembang lokal, ke repositori fitur, ke repositori produk, ke repositori QA dan akhirnya ke repositori yang dirilis.

Secara pribadi saya menggunakan produk komersial yang disebut Kiln, yang didasarkan pada Hg, tetapi fitur utamanya adalah kontrol versi terdistribusi . Ini merevolusi aliran kode baru dari pengembang menjadi produk yang dirilis.

Anda tahu cara menggunakan SVN, lalu gunakan SVN - hanya bermigrasi ke DVCS jika ada sesuatu di dalamnya yang Anda butuhkan.

Yang benar-benar penting adalah Anda menggunakan sesuatu yang akan Anda sukai, yang mudah digunakan. Martin Fowler melakukan survei cepat dan sederhana tentang VCS, hasilnya sangat menarik.

Saya mengatur git di pekerjaan terakhir saya di mana kami bekerja pada proyek berukuran sama (15 pengembang, proyek 18 bulan) dan itu bekerja dengan baik.

Cara kami mengaturnya adalah:

Kami memiliki server git yang merupakan server git otoritatif terpusat kami. Anggota tim tidak disarankan untuk saling menarik secara langsung sehingga semua perubahan masuk ke server pusat.

Kami menggunakan cabang master sebagai cabang produksi utama, dengan tag untuk setiap rilis. Setiap modul dalam proyek ini adalah submission git. Setiap submodule memiliki cabang untuk setiap anggota tim. Seorang pengelola (biasanya penulis asli) ditugaskan untuk setiap submodule, dan mereka bertanggung jawab untuk menangani permintaan tarik dari anggota tim lainnya, dan untuk mengeluarkan permintaan tarik kepada pemimpin tim yang akan memperbarui submodule di cabang utama ketika siap untuk diintegrasikan ke dalam cabang produksi. Kami menggunakan tag untuk mengidentifikasi komit yang melengkapi fitur tertentu, atau yang terkait dengan rilis.

Saya akan memberikan Team Foundation System (TFS) dari Microsoft setidaknya yang terlihat bagus. Saya mengambilnya dari komentar Anda bahwa Anda bukan toko Microsoft. Namun, pemahaman saya adalah, bahwa ada plug Eclipse yang cukup kuat jika Anda menggunakan IDE untuk pengembangan.

Mekanisme penggabungan dan percabangan bekerja sebaik sistem kontrol sumber lainnya (lebih baik dari svn, dalam pengalaman saya, dan hampir sebagus perforce), tetapi yang benar-benar bersinar adalah pelacakan proyek dan aspek manajemen proyek dari produk, dan otomatisasi bawaan untuk bangunan dan penyebaran.

Jika Anda menulis aplikasi berbasis web, lihat kerangka kerja pengujian UI otomatis, dan kerangka kerja pengujian beban yang dapat Anda buat dan konfigurasi dalam waktu yang cukup singkat. Satu fitur ramping: mensimulasikan peramban seluler yang terintegrasi dengan pengujian beban.