it-swarm-id.com

Kapan kontrol versi komit terlalu besar?

Saya pernah mendengar di beberapa tempat "Jangan membuat komitmen besar" tetapi saya tidak pernah benar-benar mengerti apa yang dimaksud dengan komitmen "besar". Apakah ini besar jika Anda bekerja pada banyak file meskipun ada yang terkait? Berapa banyak bagian proyek yang harus Anda kerjakan sekaligus?

Bagi saya, saya kesulitan mencoba membuat "komitmen kecil" karena saya lupa atau membuat sesuatu yang menciptakan sesuatu yang lain yang menciptakan sesuatu yang lain. Anda kemudian berakhir dengan hal-hal seperti ini:

 Membuat antrian keluar kustom 
 
 Bot 
 -. Field msgQueue yang tidak lebih dari SingleThreadExecutor 
 menambahkan menunggu antara ketika pesan 
 terkirim 
 - panggilan adminExist diperbarui (lihat pengontrol) 
 - Panggilan yang dihapus ke sendMessage 
 
 Pengontrol 
 -Baru field msgWait menunjukkan waktu untuk menunggu antar pesan 
 - Mulai dari plugin layanan dipindahkan ke reloadPlugins 
 - adminExists pindah dari Server karena Global admin. Cek di saluran, 
 Server, dan tingkat global 
 
 Admin 
 - Metode baru getServer dan getChannel yang mendapatkan objek yang tepat yang dimiliki Admin 
 Milik 
 
 BotEvent 
 - toString () juga menunjukkan ekstra dan ekstra1 
 Saluran. 
 - bidang saluran diganti nama menjadi 
 - Memperbaiki kesalahan ketik dalam saluran (int) 
 
 Server 
 - Admin telah dipindahkanAda ke Controller 
 
 PluginExecutor 
 - Pengujian kecil ditambahkan, akan dihapus nanti 
 
 JS Plugins 
 - Diperbarui pada perubahan kerangka kerja 
 - Diganti InstanceTracker.getController () dengan Controller.instance 
 - VLC berbicara sekarang dalam file sendiri 
 
 Berbagai NB pembaruan dan perubahan proyek 
 
 --- 
 
 File yang terpengaruh 
 Ubah /trunk/Quackbot-Core/dist/Quackbot-Core.jar[.____.[Modify /trunk/Quackbot-Core/dist/README.TXT[.____.[Modify /trunk/Quackbot-Core/nbproject/private/private.properties[.____.[Modifikasi/trunk/Quackbot-Core/nbproject/p rivate/private.xml 
 Ubah /trunk/Quackbot-Core/src/Quackbot/Bot.Java[.____.[Modify /trunk/Quackbot-Core/src/Quackbot/Controller.Java
 Ubah /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.Java[.____.[Modify /trunk/Quackbot-Core/src/Quackbot/info/Admin.Java[.____.[Modify/trunk/Quackbot-Core/src/Quackbot/info/BotEvent.Java 
 Ubah /trunk/Quackbot-Core/src/Quackbot/info/Channel.Java[.____.[Modify/trunk/Quackbot-Core/src/Quackbot/info/Server.Java 
 Ubah /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar[.____.[Modify /trunk/Quackbot-GUI/dist/README.TXT[.____.[Modify/trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar 
 Modifikasi /trunk/Quackbot-GUI/nbproject/private/private.properties[.____.[Modifikasi/trunk/Quackbot-GUI/nbproject/private/private.xml 
 Ubah /trunk/Quackbot-GUI/src/Quackbot/GUI.Java[.____.[Modify /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.Java
 Hapus /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.Java[.____.[Modifikasi/t runk/Quackbot-Impl/dist/Quackbot-Impl.jar 
 Ubah /trunk/Quackbot-Impl/dist/README.TXT[.____.[Modifikasi/trunk/Quackbot-Impl/dist/lib/Quackbot- Core.jar 
 Ubah /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar[.____.[Modifikasi /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
 Ubah /trunk/Quackbot-Impl/lib/javarebel.stats[.____.[Tambahkan /trunk/Quackbot-Impl/lib/jrebel.info[.____.[Modify/trunk/Quackbot-Impl/nbproject/private/private.properties 
 Ubah /trunk/Quackbot-Impl/nbproject/private/private.xml[.____.[Modify /trunk/Quackbot-Impl/nbproject/project.properties[.____.[Modifikasi/trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js 
 Tambahkan /trunk/Quackbot-Impl/plugins/CMDs/Operator/hostBan[.____.[Modify/trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js 
 Ubah /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js[.____.[Modify /trunk/Quackbot-Impl/plugins/CMDs /lyokofreak/lfautomode.js 
 Ubah /trunk/Quackbot-Impl/plugins/listeners/onJoin.js[._ ___.] Ubah /trunk/Quackbot-Impl/plugins/listeners/onQuit.js[.____.[Modify /trunk/Quackbot-Impl/plugins/testCase.js[.____.[Add/trunk/Quackbot-Impl/plugins /utils/whatsPlaying.js[.____.[Modify /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.Java[.____.[Add /trunk/Quackbot-Impl/vlc_http[.____._textAdd/trunk /Quackbot-Impl/vlc_http/current.html[.____.[Modify /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar[.____.[Modify /trunk/Quackbot-Plug/dist/README.TX 
 Modifikasi /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar[.____.[Modify /trunk/Quackbot-Plugins/nbproject/private/private.proproperties[.____.[Modifikasi/trunk/Quackbot -Plugins/nbproject/private/private.xml 
 Ubah /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.Java[.____.[Add /trunk/Quackbot-Plugins/vlc_http. ] Tambahkan /trunk/global-lib/jrebel.jar

Ya....

Jadi untuk pertanyaan:

  • Apa beberapa faktor ketika komit menjadi terlalu besar (hal-hal yang tidak jelas)?
  • Bagaimana Anda bisa mencegah komitmen semacam itu? Tolong berikan spesifik
  • Bagaimana dengan saat Anda dalam tahap pengembangan semi-awal ketika segala sesuatunya bergerak dengan cepat? Apakah komitmen besar masih baik-baik saja?
67
TheLQ

Bagi saya, saya kesulitan mencoba membuat "komitmen kecil" karena saya lupa atau membuat sesuatu yang menciptakan sesuatu yang lain yang menciptakan sesuatu yang lain.

Itu masalah. Sepertinya Anda perlu pelajari untuk memecah pekerjaan Anda menjadi potongan yang lebih kecil dan lebih mudah dikelola.

Masalah dengan komit besar adalah:

  • Dalam proyek multi-orang, peluang lebih besar bahwa komit Anda akan menyebabkan konflik bagi pengembang lain untuk diselesaikan.
  • Lebih sulit untuk secara akurat menggambarkan apa yang telah dilakukan dalam pesan log.
  • Lebih sulit untuk melacak urutan perubahan yang dibuat, dan karenanya untuk memahami penyebab masalah.
  • Ini meningkatkan kemungkinan kehilangan banyak pekerjaan yang tidak berkomitmen.

Kadang-kadang komitmen besar tidak dapat dihindari; misalnya jika Anda harus mengubah API utama. Tapi itu tidak biasanya terjadi. Dan jika Anda menemukan diri Anda dalam situasi ini, mungkin ide yang bagus untuk membuat cabang dan melakukan pekerjaan Anda di sana ... dengan banyak komitmen kecil ... dan bergabung kembali ketika Anda selesai.

(Kasus lain adalah ketika Anda melakukan impor awal, tapi itu BUKAN bermasalah dari perspektif masalah yang tercantum di atas.)

68
Stephen C

Prinsip Tanggung Jawab Tunggal.

Setiap komit kontrol sumber harus melayani hanya satu tujuan. Jika Anda harus memasukkan kata "dan" atau "juga" dalam ringkasan Anda, Anda perlu membaginya.

Sangat umum untuk berakhir dengan banyak perubahan terpisah yang tidak terkait atau semi terkait dalam copy pekerjaan Anda. Ini disebut "masalah copy pekerjaan kusut," dan sebenarnya sangat sulit untuk dihindari bahkan untuk pengembang yang disiplin. Namun, Git dan Mercurial memberi Anda alat untuk menyelesaikannya - git add -p atau pilihan chunk dan Mercurial Queue di TortoiseHg masing-masing.

40
jammycakes

Bayangkan bahwa klien meminta untuk membuat perubahan tertentu - misalnya untuk menambahkan aturan bahwa sesuatu atau yang lain tidak dapat dilakukan dalam waktu dua hari dari tanggal "apa pun". Kemudian, setelah Anda membuat perubahan, mereka berubah pikiran. Anda ingin mengembalikan komit Anda. Jika semuanya dibumbui dengan beberapa hal tentang mengubah urutan laporan yang tidak terkait, hidup Anda adalah kesengsaraan.

Satu item pekerjaan, satu changeet. Satu permintaan dari klien, satu perubahan ditetapkan. Satu hal yang mungkin Anda berubah pikiran, satu perubahan. Terkadang itu berarti hanya satu baris kode. Terkadang ada sepuluh file berbeda termasuk skema database. Tidak apa-apa.

26
Kate Gregory

Komitmen besar adalah saat Anda memiliki banyak perubahan yang tidak semua benar-benar masuk dalam ember yang sama. Jika saya mengubah logika controller, maka model koneksi database, maka beberapa misc. skrip, saya seharusnya tidak menggabungkan semuanya dalam satu komit.

Pencegahan membuat komitmen sesuai dengan apa yang Anda selesaikan. Dalam contoh di atas saya akan komit setelah logika controller, setelah database bekerja, dan setelah skrip. Jangan menunda komitmen hanya karena Anda tahu apa yang berubah. Orang lain akan melihat kembali pada Anda "Barang yang diubah" komit pesan log dan bertanya-tanya apa yang Anda merokok.

Impor awal mungkin merupakan komitmen terbesar yang harus Anda miliki. Menyiapkan sistem dari awal? Tentu punya beberapa komitmen besar. Setelah Anda meratakannya, sekarang saatnya untuk mengatur segalanya.

10
Josh K

Jika Anda tahu Anda akan mengerjakan sebagian besar kode sebelumnya, saya sarankan membuat cabang untuk fitur spesifik Anda sambil menarik kode turun dari garis utama secara berkala untuk memastikan kode Anda tetap tidak sinkron. Setelah selesai bekerja di cabang, gabungkan semua perubahan Anda kembali ke jalur utama. Dengan cara ini anggota tim lain tidak akan terkejut dan/atau kesal ketika mereka melihat komit besar. Juga, ada sedikit peluang untuk memecahkan banyak hal. Teruslah berlatih untuk memecah hal-hal menjadi komitmen yang lebih kecil. Seiring waktu, itu akan menjadi kebiasaan.

7
ysolik

Contoh ini menunjukkan komit yang terlalu besar.

Sebagai pedoman praktis, jelaskan perubahan dalam satu kalimat atau satu baris teks. (Berdasarkan aturan ini, komit harus dibagi menjadi 10-15 yang lebih kecil.) Jika Anda tidak dapat berkomentar komit dalam satu baris, maka komit sudah terlalu besar.

Untuk melatih komit yang lebih kecil, catat di notepad Anda (atau di Notepad) apa yang sudah Anda ubah atau tambahkan. Komit sebelum menjadi daftar panjang atau sebelum Anda membuat perubahan kode yang tidak terkait dengan apa yang sudah Anda miliki di notepad.

7
azheglov

Di bidang saya (pemodelan fisika), saya menemukan bug di output hari ini yang tidak ada di repositori 6 bulan yang lalu. Ketika ini terjadi, saya akan melakukan pencarian biner pada revisi:

  1. Jalankan model mulai 3 bulan lalu
  2. Jika bug masih dalam output, jalankan model dari 4,5 bulan yang lalu
  3. ... ulangi sampai saya menemukan komit yang menghasilkan output yang buruk

Ketika bug diperkenalkan di komit mengerikan, saya harus duduk dengan sisir bergigi untuk menemukan sumber masalahnya. Jika komit menyentuh sejumlah kecil file, itu tidak terlalu menyakitkan untuk melacak baris kode yang menyebabkan masalah.

Saya akan merekomendasikan memecah masalah Anda menjadi serangkaian tugas yang lebih kecil (idealnya menempatkan setiap tugas dalam pelacak bug). Buat komit saat Anda menyelesaikan setiap tugas (dan tutup bug/fitur itu di pelacak bug Anda).

6
Pete

Bukan ukuran komit yang benar-benar penting, melainkan ruang lingkup dari perubahan yang harus menentukan bagaimana komitmen Anda disusun.

Anda mungkin, misalnya mengubah setiap instance dari __macro1 hingga __macro2 dalam basis kode besar, yang mengubah 200 file. 200 komitmen tidak akan waras dalam kasus itu.

Apa yang ingin Anda selesaikan adalah mampu menarik repositori pada revisi tunggal dan membuat build berfungsi. Apakah Anda berubah dari libfoo ke libbar? Saya harap perubahan itu termasuk memperbarui skrip bangunan dan Makefile Anda juga (atau apa pun yang berlaku).

Terkadang, Anda mungkin perlu melakukan serangkaian perubahan eksperimental yang mencapai satu hal, dalam hal ini, Anda harus menentukan ruang lingkup apa yang lebih penting bagi Anda jika Anda perlu kembali nanti. Apakah yang satu bergantung pada yang lain? Komit semuanya sekaligus dalam satu revisi. Kalau tidak, dalam hal itu, saya sarankan satu komit per perubahan. Anda harus melakukan sesuatu seperti itu di cabang lain, atau di repo lain pula.

Sementara ya, Anda memang memiliki kekuatan untuk mengembalikan satu file ke revisi sebelumnya (dengan demikian mendukung satu file dari komitmen yang lebih besar), dengan melakukan hal itu benar-benar merusak alat-alat seperti pembelahan nanti di jalan, dan mencemari sejarah.

Jika Anda berhenti dan berpikir, "Oke, tes lulus, saya pikir ini berhasil .. tetapi jika itu memburuk, bisakah saya dengan mudah mendukungnya?" .. Anda akhirnya akan membuat komitmen yang masuk akal.

5
Tim Post

Hal yang perlu dipahami di sini adalah bahwa "Besar" dalam konteks ini adalah tentang perubahan jumlah yang berbeda bukan ukuran fisik dari komit (meskipun umumnya keduanya akan berjalan seiring).

Ini bukan pertanyaan tentang "jangan membuat komitmen besar" seperti lakukan buat komitmen kecil - yang ideal adalah untuk melakukan perubahan kecil mandiri.

Jelas dari changelog bahwa Anda punya serangkaian hal yang bisa dilakukan secara terpisah (dan aman) dan karena itu cukup jelas bahwa itu terlalu besar.

Alasan bahwa ini bisa menjadi masalah adalah bahwa komit terakhir Anda adalah titik referensi Anda untuk perubahan yang sedang Anda buat dan jika, misalnya, Anda mendapatkan bit pertama dengan benar dan kemudian mendapatkan bit berikutnya yang salah Anda tidak memiliki cara yang mudah untuk mengembalikan pekerjaan Anda ke titik di mana Anda mulai membuat kesalahan (BTDTGTTS).

Tentu saja kadang-kadang perubahan hanya besar - skala besar refactoring - dan seperti yang disarankan oleh orang lain ini adalah di mana Anda perlu bercabang, dengan cara itu meskipun individu Anda berkomitmen mungkin merusak hal-hal mereka dipisahkan dari batang pengembangan utama sehingga bukan masalah dan Anda bisa terus berkomitmen awal dan sering.

Satu hal lagi - jika ada sesuatu di tengah-tengah pekerjaan Anda yang membutuhkan perhatian lebih segera Anda perlu mengubahnya secara terpisah (idealnya dalam satu set folder yang sama sekali berbeda) dan komit secara terpisah.

Tantangan sebenarnya dalam semua ini bukanlah mekanika, melainkan pola pikirnya - bahwa komit bukan hanya salinan cadangan yang Anda buat setiap sekarang dan kemudian tetapi setiap komit adalah kerikil inci di sepanjang jalan dan tidak ada yang salah dengan banyak dari komit kecil dan yang munging hal-hal yang berbeda bersama-sama dalam komit massa sama buruknya dengan munging samar-samar terkait sedikit fungsionalitas bersama dalam segumpal kode.

4
Murph

Paling tidak, latih diri Anda untuk berkomitmen kapan pun Anda berpikir kepada diri sendiri, "Saya sangat menyukai kemajuan saya sejauh ini, dan saya tidak ingin kehilangan itu jika perubahan yang akan saya buat adalah bencana." Kemudian Anda memiliki pilihan untuk mengambil keuntungan dari VCS untuk menghilangkan jalan buntu yang Anda coba atau kode debugging khusus yang Anda tambahkan untuk melacak masalah. (mis. dengan git reset --hard atau rm -rf *; svn update)

4
Ken Bloom

Tidak ada aturan yang keras dan cepat, tidak ada garis pemisah yang komit Anda terlalu besar.

There is namun pedoman bahwa komit yang lebih kecil lebih baik, sesuai alasan (yaitu komit setiap baris adalah probaby berlebihan).

Saya mengingat pedoman semacam ini dalam pikiran:

  • Satu komit harus menyertakan perubahan hanya untuk satu perbaikan bug
  • Satu komit tidak boleh mencakup lebih dari setengah hari kerja
  • Komit tunggal tidak boleh merusak build

Tentu saja - ini yang saya ingat - YMMV. Pengembang yang berbeda menyukai tingkat granularitas yang berbeda.

2
Bevan

Semakin kecil komit, semakin mudah untuk menemukan secara tepat dari mana potensi regresi berasal.

Idealnya komit harus atom, dalam arti perubahan koheren terkecil ke basis kode (terkait dengan bug, fitur, dll).

Adapun tips khusus untuk menjaga ukuran komit kecil, itu sangat tergantung pada VCS Anda dan bagaimana pengaturannya: Anda harus dapat mengkomit secara lokal atau bekerja di cabang Anda sendiri di server.

Kuncinya adalah berkomitmen untuk cabang "pribadi" Anda setiap kali Anda melakukan perubahan atom, dan kemudian Anda dapat menggabungkan cabang Anda secara teratur, misalnya setiap minggu.

Menggunakan DVD, alur kerja Anda bisa terlihat seperti itu:

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git Push         // Push your previous commits to the team server

Menggunakan vcs terpusat:

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch
1
Xavier T.

Dalam kasus saya, saya mencoba mengkomit file server ke sistem repositori (SVN). Ini adalah komit awal dan tidak ingin mengunduhnya karena ini adalah proyek yang sangat besar (beberapa GB) dan saya ingin melakukan komit awal dari server klien.

Masalahnya adalah bahwa klien berada di server bersama, klien svn terbunuh (atau perangkat lunak lain) jika berjalan lebih dari satu menit.

Salah satu alternatifnya adalah mengunduh proyek di komputer saya dan melakukan komit awal dari sana, tetapi saya tertarik untuk mengetahui apakah ada opsi di SVN untuk memecah komit besar menjadi lebih banyak, sesuatu yang mirip dengan metode transaksi.

Pengembang sebelum saya tidak pernah menggunakan sistem kontrol versi.

0
CGeorges

Untuk menjawab pertanyaan Anda:

1) Bagi saya komit standar dianggap besar jika melakukan lebih dari satu hal. Maksud saya memperbaiki bug atau menambahkan fitur.

2) Cegah komitmen tersebut dengan menjadikannya kebiasaan dan aturan untuk melakukan setiap kali Anda menyelesaikan sesuatu.

3) Pada tahap semi-awal pengembangan, saya mengizinkan komit untuk menyertakan pembuatan pertama file yang akan digunakan nanti.

Saya ingin mencatat bahwa dengan selesai saya maksudkan bahwa semua bug yang dapat Anda identifikasi telah diperbaiki dan Anda tidak akan merusak build dengan melakukan.

Ya, ini menghasilkan sejumlah besar komit, tetapi memungkinkan Anda mengembalikan apa yang memecahkan masalah alih-alih harus mengembalikan serangkaian besar perubahan yang dilakukan pada saat yang sama di mana hanya satu dari perubahan yang menyebabkan masalah.

Saya juga ingin menunjukkan bahwa aturannya sedikit berubah untuk sistem kontrol versi terdistribusi (DVCS) seperti Mercurial dan Git. Jika Anda menggunakan salah satu dari itu, Anda berkomitmen setiap kali Anda membuat perubahan, tetapi belum mengujinya dan kemudian Anda mendorong ke repositori pusat saat itu berfungsi. Ini lebih disukai karena memungkinkan Anda merevisi lebih banyak perubahan pada kode Anda tanpa khawatir akan merusak build.

0
indyK1ng

Anda mungkin pernah mendengar pepatah bahwa kesempurnaan adalah ketika Anda tidak bisa mengambil apa pun lagi. Itu juga harus menggambarkan standar Anda untuk ukuran komit.

Itu tergantung pada proyek Anda di mana ukuran "sempurna" itu. Jika Anda mengirim ke pelanggan eksternal, ukuran yang baik mungkin merupakan kenaikan terkecil sehingga Anda akan merasa nyaman untuk pengiriman jika Anda tidak menyelesaikan yang berikutnya tepat waktu. Jika Anda sedang membangun aplikasi internal yang sering digunakan, ukuran terbaik mungkin adalah kenaikan terkecil yang tidak merusak apa pun (dan membuat Anda lebih dekat ke tempat yang Anda inginkan).

Sistem kontrol versi modern membantu Anda membuat komitmen yang baik dengan percabangan yang mudah, rebasing interaktif, area pementasan, dll.

0
Peter Eisentraut

Pesan komit harus hanya satu baris (dan untuk git maks 60 karakter). Jumlah kode yang dikomit harus cukup kecil agar pesan deskriptif tetap dalam batas itu.

Saya cenderung melakukan setiap kali (bahkan lebih lagi sekarang kita telah beralih ke git) Saya telah melakukan sebagian, karena memungkinkan untuk menangkap "mengapa" hal-hal dilakukan dengan cara ini.

0
user1249

Kadang-kadang Anda telah bekerja sepanjang hari pada beberapa chagnes yang berbeda secara logis berbeda, dan Anda lupa melakukan kode Anda di antaranya. Menggunakan git citool bisa sangat membantu untuk memecah pekerjaan Anda menjadi potongan-potongan berukuran gigitan yang bagus di akhir hari, bahkan jika Anda tidak begitu berhati-hati di siang hari saat Anda sedang bekerja.

git citool dapat membiarkan Anda memilih bakhil tertentu dari suatu file (atau baris tertentu mana) untuk komit dalam komit tertentu, sehingga Anda dapat memecah (tidak tumpang tindih) perubahan yang dibuat untuk file yang sama menjadi beberapa komit.

(Sepertinya Anda menggunakan Subversion. Saya tidak tahu alat yang melakukan ini untuk Subversion, tetapi Anda bisa melihat ke dalam menggunakan git-svn, adaptor Subversion untuk git, yang akan mengubah hidup Anda.)

0
Ken Bloom

Semakin besar komit, semakin besar kemungkinan Anda akan merusak build dan dibayar oleh anggota tim Anda yang lain. Saya mencoba melakukan perubahan dua kali sehari. Tepat sebelum makan siang dan sebelum aku pulang. Jadi jam 12 siang dan 4:30 sore saya mencoba membuat semuanya berfungsi dan siap untuk berkomitmen. Saya menemukan latihan ini bekerja untuk saya.

0
Nickz