Sakit kepala menggunakan kontrol versi terdistribusi untuk tim tradisional?

Walaupun saya menggunakan dan menyukai DVCS untuk proyek pribadi saya, dan dapat benar-benar melihat bagaimana hal itu membuat mengelola kontribusi untuk proyek Anda dari orang lain lebih mudah (misalnya skenario Github khas Anda), sepertinya untuk tim "tradisional" mungkin ada beberapa masalah selama pendekatan terpusat yang digunakan oleh solusi seperti TFS, Perforce, dll. (Dengan "tradisional", saya maksudkan tim pengembang di kantor yang mengerjakan satu proyek yang tidak dimiliki oleh satu orang, dengan orang yang berpotensi menyentuh kode yang sama.)

Beberapa masalah ini sudah saya perkirakan sendiri, tapi tolong bimbang dengan pertimbangan lain.

Dalam sistem tradisional, ketika Anda mencoba memeriksa perubahan Anda di server, jika orang lain sebelumnya telah memeriksa perubahan yang bertentangan maka Anda dipaksa untuk menggabungkan sebelum Anda dapat memeriksa Anda masuk. Dalam model DVCS, setiap pengembang memeriksa di mereka perubahan secara lokal dan pada titik tertentu mendorong ke beberapa repo lainnya. Repo itu kemudian memiliki cabang file yang diubah 2 orang. Tampaknya sekarang seseorang harus ditugaskan menangani situasi itu. Orang yang ditunjuk dalam tim mungkin tidak memiliki pengetahuan yang cukup tentang seluruh basis kode untuk dapat menangani penggabungan semua konflik. Jadi sekarang langkah tambahan telah ditambahkan di mana seseorang harus mendekati salah satu pengembang itu, katakan padanya untuk menarik dan melakukan penggabungan lalu mendorong lagi (atau Anda harus membangun infrastruktur yang mengotomatiskan tugas itu).

Lebih jauh lagi, karena DVCS cenderung membuat bekerja secara lokal begitu mudah, ada kemungkinan bahwa pengembang dapat mengakumulasikan beberapa perubahan dalam repo lokal mereka sebelum mendorong, membuat konflik seperti itu lebih umum dan lebih rumit.

Jelas jika semua orang di tim hanya bekerja pada area kode yang berbeda, ini bukan masalah. Tapi saya ingin tahu tentang kasus di mana semua orang bekerja pada kode yang sama. Sepertinya model terpusat memaksa konflik untuk ditangani dengan cepat dan sering, meminimalkan kebutuhan untuk melakukan penggabungan yang besar dan menyakitkan atau meminta siapa pun "menjadi polisi" sebagai repo utama.

Jadi bagi Anda yang menggunakan DVCS dengan tim Anda di kantor Anda, bagaimana Anda menangani kasus-kasus seperti itu? Apakah Anda menemukan alur kerja harian Anda (atau lebih mungkin, mingguan) terpengaruh secara negatif? Apakah ada pertimbangan lain yang harus saya ketahui sebelum merekomendasikan DVCS di tempat kerja saya?

Kami telah menggunakan Mercurial selama sekitar satu tahun. Sementara sakit kepala yang Anda sebutkan ada, sejauh ini, tantangan terbesar untuk adopsi penuh bagi kami adalah masuk ke pola pikir DVCS dari repositori lokal (= sering melakukan.) Pola pikir lama "Berkomitmen setelah kode polesan" sulit untuk pergi.

Kamu berkata:

Dalam model DVCS, setiap pengembang mengecek perubahannya secara lokal dan pada satu titik mendorong ke beberapa repo lainnya. Repo itu kemudian memiliki cabang file yang diubah 2 orang. Tampaknya sekarang seseorang harus ditugaskan menangani situasi itu.

Instalasi default Mercurial memblokir perilaku ini. Itu tidak akan memungkinkan dorongan jika lebih dari satu kepala akan dibuat dalam repo jarak jauh, tanpa konfirmasi tambahan. Untuk kegiatan sehari-hari, kami menghindarinya. (Git telah menamai kepala dan masing-masing hanya dapat diperbarui jika sepenuhnya menggabungkan versi sebelumnya, tanpa konfirmasi tambahan, jadi sekali lagi situasinya tidak dapat muncul. DVCS lain juga memiliki perlindungan serupa.)

Jadi pada akhir setiap hari kerja, beberapa waktu perlu disisihkan untuk komitmen, yang sebenarnya adalah kegiatan ini:

1. Komit perubahan lokal.
2. Tarik dari repo pusat.
3. Gabungkan (& lakukan penggabungan.)
4. Dorong ke repo pusat.

Ini membuat aktivitas penggabungan pada seseorang yang baru-baru ini mengerjakan kode ini, dan harus dapat mengintegrasikan perubahan mereka secepat orang lain.

Seperti yang ditunjukkan dalam pertanyaan, ini hanya menambah upaya ketika dua orang bekerja pada area kode yang sama. Jika demikian, maka ada lebih banyak manfaat menggunakan DVCS, jadi imbalannya sudah jelas bagi para pengembang tersebut. (Manfaat tambahan termasuk setiap pengembang dapat secara terpisah melakukan kode dan bermain dengan repo mereka sendiri tanpa ada pengembang lain yang menghalangi.)

Masalah lain yang Anda sebutkan:

Lebih jauh lagi, karena DVCS cenderung membuat bekerja secara lokal begitu mudah, ada kemungkinan bahwa pengembang dapat mengakumulasikan beberapa perubahan dalam repo lokal mereka sebelum mendorong, membuat konflik seperti itu lebih umum dan lebih rumit.

Ini tidak membuat masalah penggabungan untuk kami, tetapi dapat membuat masalah yang berbeda:

Fleksibilitas DVCS berarti bahwa banyak alur kerja yang berbeda dimungkinkan, tetapi beberapa di antaranya tidak bertanggung jawab. Dengan DVCS, kebutuhan akan proses atau prosedur yang jelas meningkat. Aktivitas menjaga perubahan lokal mungkin sesuai atau tidak sesuai, tergantung banyak hal.

Misalnya: dapatkah pengembang bekerja pada fitur hewan peliharaan di waktu luang selama beberapa minggu? Di beberapa lingkungan ini dianjurkan, dalam beberapa hal ini tidak pantas dan semua perubahan harus segera tersentralisasi. Tetapi jika seorang dev melakukan perubahan secara lokal, maka mereka pasti ingin melakukan perubahan terkait untuk memastikan pekerjaan mereka akan terus bermain dengan baik dengan putaran umum terbaru.

Ketika karet memenuhi jalan, rilis perangkat lunak atau penyebaran biasanya berasal dari repo pusat, sehingga pengembang perlu mendapatkan perubahan mereka di sana untuk pengujian dan penyebaran.

Itu cerita saya, dan saya berpegang teguh pada itu, setidaknya selama beberapa menit ...

Premis pertanyaan Anda tampaknya ada di sekitar "Penggabungan sulit dan harus dihindari". Sistem DVCS menghilangkan penghalang ini, pada kenyataannya mereka melakukan lebih banyak, merangkul gagasan penggabungan - Anda seharusnya tidak takut pada penggabungan dan menggabungkan konflik sebagai hasilnya, karena tidak seperti alat yang terpusat, alat DVCS mendukungnya dengan desain.

Sebagai jawaban yang sangat baik oleh Jamie F menyatakan - Alur kerja dari Komit-Tarik-Gabung-Dorong dilakukan secara teratur (setiap hari) berarti bahwa jika Anda berjalan di atas beberapa pekerjaan lain, Anda melihatnya lebih awal - selama itu terlihat, itu dapat dikelola .

Masalah yang Anda gambarkan adalah lebih banyak tentang bagaimana Anda memilih untuk menggunakan alat.

Kami beralih dari SVN ke GIT 6 bulan lalu, setelah menggunakan SVN dan GIT secara lokal selama beberapa tahun. Tidak ada yang akan kembali, dan konflik gabungan yang menyakitkan adalah sesuatu dari masa lalu. Mantra "Komit kecil dan sering" adalah kuncinya.

Ketika saya bekerja di sebuah tim yang menggunakan git, aturan praktisnya adalah ini: bekerja di cabang pribadi, lalu, ketika Anda siap untuk membuat pekerjaan Anda tersedia untuk anggota tim lainnya, rebase cabang Anda menjadi master sebelum Anda mendorong. (Kemudian validasi cabang Anda.)

Strategi ini berarti bahwa master adalah serangkaian komitmen linier, dan bahwa semua masalah integrasi diperbaiki di cabang sebelum publik.

Alat seperti SVN sangat mendorong cara kerja yang terintegrasi secara ketat.

Yakni sering melakukan ke cabang bersama (baik cabang atau cabang dev).

Ini A-OK untuk sebagian besar lingkungan pengembangan perusahaan yang telah saya alami, dan difasilitasi dan didorong lebih jauh melalui penggunaan Integrasi Berkelanjutan yang didukung oleh tes integrasi yang luas, tes regresi dan tes unit (Membantu pengembang individu mendapatkan kepercayaan bahwa mereka tidak rusak apa pun dengan perubahan mereka).

DVCS memberi Anda kebebasan untuk bekerja lebih mandiri, yang memang Anda butuhkan dalam beberapa situasi, dan dukungan yang ditingkatkan (banyak digembar-gemborkan) untuk penggabungan tidak dapat membahayakan apa pun.

Kekhawatiran yang selalu ada di benak saya adalah ini: Dengan kebebasan besar datanglah godaan untuk menggunakan kebebasan itu.

Tentu saja, dalam pengalaman saya (terbatas), saya menghabiskan lebih banyak waktu bekerja secara mandiri di tim saya saat ini (menggunakan Mercurial) daripada yang saya lakukan di peran sebelumnya (Di mana kami menggunakan SVN, CVS & P4).

Ini hanya sebagian disebabkan oleh alat, tetapi saya pikir itu adalah pengamatan yang masuk akal untuk membuat, jika tidak ada alasan kuat untuk mengeluarkan upaya komunikasi dan koordinasi, orang akan cenderung bekerja terpisah dan terisolasi.

Ini tidak selalu merupakan hal yang buruk, tetapi saya percaya bahwa itu adalah sesuatu yang perlu dipertimbangkan.

Masalahnya dengan kontrol versi tipe git / mercurial, adalah sering melakukan, dan mendorong ke server terpusat ketika kodenya bagus. Satu kelebihan besar dengan ini adalah bahwa ia menciptakan tambalan kecil, yang mudah diterapkan dalam kasus konflik. Alur kerja Anda juga harus sesuai dengan:

1. Banyak komit lokal
2. Tarik dari server
3. Dorong ke server

Tarik ini dari server mungkin membuat konflik, tetapi untuk menyelesaikan ini, semua yang dibutuhkan berkali-kali adalah rebase sederhana, bukan gabungan. Saya rasa ini akan menjaga sejarah arus utama tetap bersih, dan menghapus cukup banyak konflik.

Ini juga terjadi ketika Anda menarik dari repo lokal rekan kerja, karena dua hal mungkin terjadi. Entah ia mendorong ke server terlebih dahulu, yang baik-baik saja karena Anda sudah memiliki tambalannya, dan tidak ada konflik yang harus terjadi, atau Anda dorong dulu, yang berarti ia hanya akan mendapatkan tambalan Anda ketika ia menarik.

Tentu saja, terkadang penggabungan adalah solusi yang lebih baik, sebagai contoh jika Anda bekerja pada cabang fitur yang harus digabungkan menjadi master.

Dalam alur kerja Anda, Anda berbicara tentang orang-orang yang harus secara eksplisit pergi ke pengembang lain dan mengatakan kepadanya untuk memperbaiki konflik, tetapi itu tidak perlu. Server pusat adalah "bos", dan apa yang terutama harus Anda hadapi. Jika perubahan Anda berlaku untuk repo pusat, maka Anda ok. Jika tidak, itu tugas ANDA untuk memperbaiki konflik, yang mungkin mengharuskan pengembang yang Anda konflik untuk membantu memahami perubahannya. Ini adalah sesuatu yang Anda lihat ketika Anda mencoba menarik / rebase dari server. Jadi senang melakukan, dan berurusan dengan konflik ketika Anda harus menarik dari server.

Prinsip bekerja dengan repositori terpusat adalah sama ketika bekerja dengan sistem terpusat atau terdistribusi yang tidak terkunci:

• Dalam sistem terpusat Anda:
  1. Dapatkan versi terbaru dari arus utama ("trunk" di subversi, "master" di git, ...)
  2. Ubah file
  3. Gabungkan modifikasi dengan versi terbaru dari arus utama menggunakan perintah "perbarui"
  4. Berkomitmen pada jalur utama
• Dalam sistem terdistribusi Anda:
  1. Dapatkan versi terbaru dari arus utama
  2. Ubah file
  3. Berkomitmen secara lokal
  4. Gabungkan modifikasi dengan versi terbaru dari arus utama dan komit hasilnya secara lokal
  5. Dorong ke arus utama.

Tidak ada versi terdistribusi yang memungkinkan Anda untuk mendorong revisi yang tidak sepenuhnya menggabungkan revisi kepala sebelumnya (tanpa penggantian khusus; kadang-kadang berguna), jadi itu tidak akan berjalan tanpa melakukan langkah penggabungan (sehingga tidak akan ada dua versi seseorang harus berkonsolidasi sesuai keinginan Anda).

Sekarang perhatikan bahwa empat langkah adalah sama kecuali untuk terminologi, tetapi sistem terdistribusi menambahkan langkah ekstra "3. Berkomitmen secara lokal". Keuntungan besar dari langkah ini adalah bahwa ketika pembaruan / tarik menciptakan konflik dan Anda tidak yakin bagaimana menyelesaikannya atau membuat kesalahan menyelesaikannya, Anda dapat kembali, meninjau apa yang Anda lakukan dan mengulangi penggabungan. Subversion tidak akan mengingat semua itu, jadi jika Anda membuat kesalahan dengan memperbarui pembaruan, Anda kacau.

Adapun akumulasi akumulasi, orang cenderung melakukan itu dengan sistem terpusat juga. Terutama jika Anda harus sering beralih di antara fitur-fitur (seperti menginterupsi pekerjaan yang lebih lama untuk memperbaiki bug atau melakukan tweak yang sangat dibutuhkan pelanggan), orang-orang akan sering perlu melakukan perubahan secara lokal hanya karena mereka belum selesai. Jadi lebih baik jika sistem setidaknya mendukungnya.

Dalam kedua kasus ini masalah-masalah ini perlu ditangani oleh pedoman dan komunikasi yang tepat dalam tim dan bukan alat. Dengan alat yang lebih fleksibel, pedoman lebih penting, tetapi alat yang lebih fleksibel memungkinkan penanganan berbagai kasus sudut dengan lebih baik.