Dalam kontrol versi terpusat, apakah selalu baik untuk memperbarui sering?

9

Berasumsi bahwa:

Tim Anda menggunakan kontrol versi terpusat.
Anda sedang mengerjakan fitur yang lebih besar yang akan selesai beberapa hari, dan Anda tidak akan bisa melakukan sebelum itu karena itu akan merusak build.
Anggota tim Anda melakukan sesuatu setiap hari yang dapat mengubah beberapa file yang sedang Anda kerjakan.

Karena ini adalah kontrol versi terpusat, Anda harus memperbarui checkout lokal di beberapa titik: setidaknya satu kali tepat sebelum melakukan fitur baru.

Jika Anda memperbarui hanya sekali sebelum komit Anda, maka mungkin ada banyak konflik karena banyak perubahan lainnya oleh rekan setim Anda, yang bisa menjadi dunia kesedihan untuk diselesaikan sekaligus.

Atau, Anda dapat memperbarui sering, dan bahkan jika ada beberapa konflik untuk diselesaikan hari demi hari, itu harus lebih mudah dilakukan, sedikit demi sedikit.

Akankah Anda tinggal itu selalu merupakan ide yang baik untuk memperbarui sering?

svn version-control cvcs

— janos
sumber

16

Jika Anda tidak bercabang, maka Anda tidak mengambil keuntungan dari salah satu manfaat terbesar dari sistem kontrol versi .

— gahooa

Apakah CVCS Anda memberikan pandangan yang nyaman tentang potensi konflik pembaruan tanpa mengubah file lokal Anda? TortoiseSVN memiliki fungsi seperti itu.

— rwong

dibahas sebelumnya: Seberapa sering saya / Anda harus membuat komitmen? dan git / VCS lainnya - seberapa sering melakukan?

— nyamuk

@gnat pertanyaannya adalah seberapa sering memperbarui, tidak melakukan

— janos

2

Pertanyaannya sangat spesifik tentang seberapa sering "diperbarui". Dan itu sudah menjadi bagian dari asumsi yang sering dilakukan oleh rekan setim Anda. Yang pasti merupakan hal yang baik, tetapi dalam hal apapun bukan subjek di sini

— janos

24

Secara pribadi, saya memperbarui versi lokal saya setiap hari.

Dalam skenario yang Anda jelaskan, saya akan berusaha lebih keras

Membuat cabang untuk fitur baru yang panjang.
Sering bergabung dari jalur utama ke cabang baru ini.

Cara ini,

Anda dapat check-in setiap hari untuk menjaga kode Anda di server
Anda tidak perlu khawatir tentang memecah bangunan dengan check-in.
Anda dapat menggunakan repositori untuk membatalkan beberapa pekerjaan atau perbedaan bila perlu dengan check-in sebelumnya.
Anda yakin akan mengerjakan basis kode terbaru dan mendeteksi kemungkinan perubahan kode yang bertentangan sejak awal.

Kelemahan seperti yang saya lihat adalah

Penggabungan dari main harus dilakukan secara manual (atau dituliskan)
Dibutuhkan lebih banyak "administrasi"

— Letnan Keersmaekers
sumber

2

Anda benar karena selalu merupakan hal yang baik untuk bekerja pada cabang fitur, bukan pada trunk. Masalahnya adalah sebagian besar CVCS melakukan pekerjaan yang buruk dalam penggabungan, sehingga sebagian besar programmer yang saya kenal di CVCS tetap berpegang pada satu cabang tunggal sebagian besar waktu. Pertanyaannya adalah, dapatkah Anda memberi tahu mereka bahwa secara umum selalu baik untuk sering memperbarui?

— janos

6

Berasal dari Sourcesafe (tempat kami tidak bergabung sama sekali) ke TFS, git, dan lincah (tempat kami sering melakukan penggabungan) , pengalaman pribadi saya adalah bahwa penggabungan sering kali menciptakan masalah yang jauh lebih sedikit daripada menunggu penggabungan big bang. Saya setuju bahwa itu memerlukan mindshift dari sesama programmer. Saya terdengar sebagai rekaman rusak di tempat kerja saya tetapi semua orang harus sering melakukan dan memperbarui sering.

— Lieven Keersmaekers

6

Ya, itu ide yang baik untuk memperbarui sering. Anda memperbarui sering untuk menghindari konflik penggabungan yang sulit dan ini adalah dasar-dasar pengetahuan Manajemen Konfigurasi Perangkat Lunak (SCM) dengan masalah perubahan yang berbeda.

Ini terlepas dari apakah itu terpusat atau didistribusikan; semakin lama Anda menyimpang dari sumber upstream (artinya jika itu adalah trunk, cabang, atau repositori lain dalam kasus DVCS), semakin tinggi kemungkinan untuk menggabungkan konflik. Ya, kejutan tidak menyenangkan dari tim Anda mungkin muncul saat memperbarui, tetapi menunda kejutan jahat itu bahkan lebih mengkhawatirkan (semakin lama Anda menunggu, semakin sedikit orang yang mengingat mengapa serangkaian perubahan dilakukan).

Untuk memperbarui agar berfungsi, ini juga berarti bahwa Anda dan programmer lain yang mengerjakan kode tidak boleh dengan sengaja melakukan atau mendorong kode hulu yang merusak build . Inilah sebabnya mengapa programer bercabang (atau menyimpang dari hulu dalam istilah SCM), untuk melindungi anggota tim Anda dan pemangku kepentingan lainnya dari memiliki kode yang rusak jika situasi seperti itu mau tidak mau harus muncul.

Mantra yang dapat Anda gunakan untuk diingat adalah ini: "perbarui, perbarui, perbarui, komit". Selalu pastikan perubahan Anda bekerja dengan orang lain sebelum melakukan. Ini juga untuk memastikan memeriksa kode untuk pertama kalinya juga berfungsi.

— Spoike
sumber

4

Poin ketiga dalam pertanyaan itu benar- benar salah :

Anda sedang mengerjakan fitur baru yang pasti akan membutuhkan waktu beberapa hari untuk selesai, dan Anda tidak akan dapat melakukan sebelum itu karena itu akan merusak build.

Jika Anda tahu Anda akan mengerjakan sesuatu yang tidak dapat Anda lakukan untuk beberapa waktu, itu adalah contoh buku teks untuk menggunakan cabang.

Jangan menempatkan diri Anda dalam situasi di mana Anda memiliki banyak perubahan yang tertunda. Jika Anda tahu bahwa Anda tidak akan dapat melakukan di cabang utama proyek Anda untuk beberapa waktu, kemudian bekerja di cabang lain. Dan di sana, sering-seringlah berkomitmen .

Jika Anda sudah dalam situasi yang dijelaskan dalam pertanyaan, maka beralihlah ke cabang sekarang , komit perubahan Anda dan terus bekerja di cabang itu.

Biasanya di CVCS adalah ide yang baik untuk memperbarui sering. Tetapi jika Anda bekerja pada cabang maka pertanyaan "perbarui sering atau tidak" menjadi "sering bergabung atau tidak". Dan jawabannya adalah ya. Pastikan untuk melakukan semua perubahan yang tertunda (di cabang) sebelum bergabung dari cabang lain, ke opsi Anda untuk memutar kembali penggabungan dengan aman jika Anda harus.

— janos
sumber

2

Saya pikir Anda harus melakukan lebih sering. Jika Anda akan bekerja untuk waktu yang lama seperti beberapa hari, Anda harus melakukan percabangan kode Anda dan bekerja di cabang Anda daripada bekerja langsung di bagasi. Saya tahu itu nyaman untuk mulai bekerja tanpa cabang, tetapi itu tidak benar-benar fleksibel karena Anda tidak dapat memastikan bahwa pembaruan / komit Anda akan merusak kode Anda atau tidak, yang berakhir pada situasi di mana Anda akan menahan pembaruan / komit Anda sampai Anda telah melakukan pekerjaanmu. "Fitur percabangan" lebih baik karena Anda selalu dapat melakukan kode Anda, dan hanya menggabungkan kembali nanti ketika Anda selesai.

Dalam strategi percabangan, pembaruan diganti dengan penggabungan dari trunk. Dari pengalaman saya, Anda tidak perlu sering bergabung dari trunk, karena kode dalam rentang waktu lima hari tidak akan banyak berubah dan lebih mudah untuk menyelesaikan konflik hanya sekali setelah Anda selesai.

— tia
sumber

1

Saya sebenarnya merasa lebih nyaman menggunakan kontrol versi terdistribusi secara lokal. Yaitu, saya menggunakan git sebagai klien subversi. Ini memiliki kelebihan yaitu:

Perubahan lokal disimpan sebelum memperbarui, jadi jika saya membuat kesalahan dalam penggabungan, saya selalu bisa kembali dan melakukannya lagi.
Saat melakukan perubahan yang lebih besar, saya dapat menyimpan bagian yang selesai. Itu membuatnya lebih mudah untuk meninjau perubahan yang tersisa dalam proses.
Ketika saya memperbaiki bug selama beberapa pekerjaan yang lebih besar, saya bisa melakukan perbaikan itu saja, sementara melakukan sisanya dan "mengubah" perbaikan untuk subversi sambil menjaga pekerjaan lain dalam proses lokal

— Jan Hudec
sumber

0

Jika Anda menambahkan fitur baru, dapatkah Anda membuat file sumber tunggal baru (dan file header antarmuka eksternal yang cocok)?

Saya khawatir bahwa "fitur baru" memiliki implikasi luas? Orientasi objek mungkin tidak lagi menjadi kata kunci seperti dulu, tetapi ada manfaat dalam paradigma itu.

Dengan begitu Anda bisa membuat kerangka kerja (antarmuka eksternal, ditambah fungsi rintisan) dan komit bahwa maka harus ada efek pihak ketiga minimal, sementara Anda menyelesaikan sisa pengembangan Anda?

Dalam situasi yang Anda jelaskan, saya merasa lebih baik memiliki file sumber yang lebih kecil daripada lebih sedikit, file lebih besar.

— Andrew
sumber

0

Bagaimana perbedaan untuk kontrol versi terpusat daripada kontrol versi terdistribusi?

Dalam kedua kasus Anda harus check-in di tempat yang kontennya akan dipindahkan dibandingkan dengan apa yang Anda mulai. Saya tidak melihat perbedaan dalam frekuensi penggabungan dari repositori pusat ke tempat Anda bekerja (dan cabang proyek Anda adalah tempat kerja Anda).

Saya cenderung untuk penggabungan sering dengan cara (setidaknya sekali sehari, saya juga dapat menggabungkan pada waktu yang tepat bagi saya, atau ketika saya tahu seseorang telah memeriksa sesuatu yang mempengaruhi apa yang saya kerjakan). Jauh lebih mudah untuk menyerap perubahan kecil dan jika Anda memiliki masalah, orang-orang akan lebih membantu ketika Anda bertanya kepada mereka tentang apa yang baru saja mereka periksa daripada tentang apa yang telah mereka periksa satu minggu yang lalu.

BTW, saya tidak tahu apa yang Anda sebut "break the build". Saya cenderung bekerja dalam kenaikan yang relatif kecil, sehingga saya menjaga kondisi yang dapat dikompilasi, bahkan jika itu merusak beberapa fitur. Dan saya menjalankan tes sehingga saya tahu bahwa gabungan tidak merusak sesuatu yang seharusnya berfungsi. Sekali lagi, lebih mudah untuk memperbaiki masalah ketika terdeteksi dini.

— Pemrogram
sumber

2

Dalam versi terdistribusi, Anda dapat melakukan perubahan yang tertunda secara lokal. Dengan begitu jika penggabungan menghasilkan terlalu banyak konflik dan Anda memilih untuk menunda dan memutar balik, Anda bisa. Dalam kontrol versi terpusat Anda tidak dapat melakukan secara lokal, dan jika Anda ingin memutar kembali pembaruan, Anda tidak bisa. Jadi nuansa versi terpusat itu penting, karena operasi pembaruan lebih berisiko daripada gabungan.

— janos

3

@janos, Dalam pengalaman saya, semakin sulit penggabungan, semakin Anda ingin melakukannya sekarang karena menunggu tidak akan pernah membuatnya lebih mudah. Saya biasanya membaca diff sebelum menerapkannya dan saya kadang membuat manual cadangan jika tampaknya rumit. Apa yang saya juga lakukan adalah menggunakan repositori lincah untuk mengontrol versi perubahan saya tidak bisa check in di sistem resmi. Saya tidak menemukan manfaat yang menjamin biaya dalam situasi saya, tetapi mungkin berbeda untuk Anda.

— Pemrogram

operasi pembaruan di CVCS kurang aman karena Anda tidak dapat mengembalikannya dengan cara Anda dapat mengembalikan gabungan di DVCS. Inilah sebabnya mengapa bagian CVCS penting, dan pertanyaannya tidak masuk akal dalam DVCS.

— janos

Menunggu tidak dapat mengurangi kesulitan maupun risikonya, jadi Anda berdebat untuk pembaruan yang lebih sering.

— Pemrogram

Ya, saya selalu berpikir ada baiknya memperbarui sering. Saya ingin memvalidasi bahwa dengan mencari hal-hal buruk saya mungkin tidak memikirkan diri saya sendiri. Misalnya, jika Anda memiliki refactor besar yang tertunda, maka mungkin Anda tidak ingin konflik kecil meledak di wajah Anda. Saya tidak tahu Saya hanya ingin memastikan bahwa saya dapat terus mengatakan "sering perbarui" tanpa membuat kesalahan sendiri.

— janos

0

Itu tergantung pada seberapa baik Anda berada di "unupdating" ketika orang lain merusak build. Di satu sisi, Anda ingin memperbarui dalam potongan sekecil mungkin. Secara pribadi, saya memperbarui hampir setiap kali saya melihat pembaruan tersedia. Di sisi lain, jika build rusak dan butuh satu hari bagi orang lain untuk memperbaikinya, Anda masih ingin dapat bekerja pada fitur baru Anda dalam waktu yang bersamaan.

Saya telah bekerja dengan sistem kontrol versi yang sangat sulit untuk dicadangkan begitu pembaruan dilakukan. Pada itu, saya cenderung memperbarui tepat sebelum saya perlu check-in. Dengan sistem kontrol versi yang lebih baik, ada sedikit alasan untuk tidak memperbarui beberapa kali per hari.

— Karl Bielefeldt
sumber