Kapan kontrol versi komit terlalu besar? [Tutup]


65

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 mengalami 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 khusus

Bot
-Baru field msgue yang tidak lebih dari SingleThreadExecutor
-mengirim blok hingga pesan dikirim, dan menambahkan menunggu antara saat pesan diterima
dikirim
Panggilan -adminExist diperbarui (lihat pengontrol)
Panggilan -Removed ke sendMessage

Pengendali
-Bidang baru msgWait menunjukkan waktu untuk menunggu antar pesan
-Mulai plugin layanan dipindahkan ke reloadPlugins
-adminExists pindah dari Server karena admin Global. Cek di saluran,
server, dan tingkat global

Admin
Metode baru getServer dan getChannel yang mendapatkan objek Admin yang sesuai
Milik

BotEvent
-toString () juga menunjukkan ekstra dan ekstra1

Saluran
Bidang -lannel diubah namanya menjadi nama
Kesalahan ketik di saluran (int)

Server
Admin -Pindah ke Pengontrol

PluginExecutor
-Minor pengujian ditambahkan, akan dihapus nanti

Plugin JS
-Dibarui untuk perubahan kerangka kerja
-Replaced InstanceTracker.getController () dengan Controller.instance
Bicara -VLC sekarang di file sendiri

Berbagai pembaruan dan perubahan proyek NB

---

File yang terpengaruh
Ubah /trunk/Quackbot-Core/dist/Quackbot-Core.jar
Ubah /trunk/Quackbot-Core/dist/README.TXT
Ubah /trunk/Quackbot-Core/nbproject/private/private.properties
Ubah /trunk/Quackbot-Core/nbproject/private/private.xml
Ubah /trunk/Quackbot-Core/src/Quackbot/Bot.java
Ubah /trunk/Quackbot-Core/src/Quackbot/Controller.java
Ubah /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.java
Ubah /trunk/Quackbot-Core/src/Quackbot/info/Admin.java
Ubah /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.java
Ubah /trunk/Quackbot-Core/src/Quackbot/info/Channel.java
Ubah /trunk/Quackbot-Core/src/Quackbot/info/Server.java
Ubah /trunk/Quackbot-GUI/dist/Quackbot-GUI.jar
Ubah /trunk/Quackbot-GUI/dist/README.TXT
Ubah /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jar
Ubah /trunk/Quackbot-GUI/nbproject/private/private.properties
Ubah /trunk/Quackbot-GUI/nbproject/private/private.xml
Ubah /trunk/Quackbot-GUI/src/Quackbot/GUI.java
Ubah /trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.java
Hapus /trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.java
Ubah /trunk/Quackbot-Impl/dist/Quackbot-Impl.jar
Ubah /trunk/Quackbot-Impl/dist/README.TXT
Ubah /trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jar
Ubah /trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jar
Ubah /trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jar
Ubah /trunk/Quackbot-Impl/lib/javarebel.stats
Tambahkan /trunk/Quackbot-Impl/lib/jrebel.info
Ubah /trunk/Quackbot-Impl/nbproject/private/private.properties
Ubah /trunk/Quackbot-Impl/nbproject/private/private.xml
Ubah /trunk/Quackbot-Impl/nbproject/project.properties
Ubah /trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.js
Tambahkan / trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBan
Ubah /trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.js
Ubah /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.js
Ubah /trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.js
Ubah /trunk/Quackbot-Impl/plugins/listeners / onJoin.js
Ubah /trunk/Quackbot-Impl/plugins/listeners / onQuit.js
Ubah /trunk/Quackbot-Impl/plugins/testCase.js
Tambahkan /trunk/Quackbot-Impl/plugins/utils/whatsPlaying.js
Ubah /trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.java
Tambahkan / trunk / Quackbot-Impl / vlc_http
Tambahkan /trunk/Quackbot-Impl/vlc_http/current.html
Ubah /trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jar
Ubah /trunk/Quackbot-Plugins/dist/README.TXT
Ubah /trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jar
Ubah /trunk/Quackbot-Plugins/nbproject/private/private.properties
Ubah /trunk/Quackbot-Plugins/nbproject/private/private.xml
Ubah /trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.java
Tambahkan / 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?

lists.madduck.net/pipermail/vcs-home/2010-September/000276.html menjelaskan kasus di mana file data itu sendiri terlalu besar untuk disimpan secara efektif dalam repositori. (Tapi saya yakin bukan itu yang Anda bicarakan di sini.)
Ken Bloom

Tidak konstruktif ????? Saya baru belajar satu ton di sini! Mod, tolong hentikan penutupan pertanyaan kejam Anda!
richard

Apa yang Anda tidak pernah melihat satu komit dengan ratusan file, yang dipotong tidak akan dikompilasi?
Joshua

Jawaban:


67

Bagi saya, saya mengalami 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 belajar 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; mis. jika Anda harus mengubah API utama. Tapi itu tidak biasanya terjadi. Dan jika Anda menemukan diri Anda dalam situasi ini, mungkin ide yang baik 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.)


7
+1, pasti belajar cara memecahnya menjadi potongan yang lebih kecil. Saat mencari bug, komitmen yang lebih kecil lebih mudah dikelola. Setelah beberapa kali pertama memandangi komit besar, Anda akan mendapatkan kebiasaan: P
dr Hannibal Lecter

2
Jika diperlukan di akhir rangkaian komit kecil, Anda dapat menambahkan label / tag yang menyertakan deskripsi ringkasan panjang. Ini secara efektif menerapkan baseline pada titik di mana pekerjaan besar Anda selesai, sebelum Anda mengintegrasikan kembali atau memulai beberapa bentuk pengujian yang lebih formal (jika itu menjadi bagian dari bagaimana Anda / bisnis Anda bekerja). SAYA AKAN MENAMBAH: Membuat perubahan skala besar (seperti yang Anda sarankan) di cabang pengembangan adalah ide yang sangat bagus. Ini mencegah polusi aliran utama Anda dengan tumpukan besar dan membuat paket layanan perbaikan cepat, dll lebih mudah dibuat jika diperlukan.
cepat,

1
Juga, komit yang lebih kecil = perbedaan yang lebih kecil untuk orang-orang yang meninjau PR dengan komitmen
peter

40

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 harus 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 keduanya memberi Anda alat untuk mengatasinya - git add -p atau chunk selection dan Mercurial Queue di TortoiseHg .


2
ini adalah prinsip yang baik; namun dalam praktiknya, saya masih akan menerima komitmen yang melakukan banyak hal (terutama jika terkait) dan jika ukuran komit cukup kecil; Untuk mengimbanginya, saya sarankan menjadi ahli rebase interaktif untuk menulis ulang sejarah yang tidak didorong hingga bagus & jelas.
Rivenfall

26

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.


Setuju sepenuhnya dengan "1 baris / 10 file". Ada terlalu banyak variabel untuk menjawab pertanyaan ini dengan seperangkat hukum standar
Pulak Agrawal

7
Satu-satunya hal yang saya tambahkan adalah bahwa kadang-kadang masuk akal untuk pergi lebih kecil dari "satu permintaan, satu perubahan". Permintaan yang lebih besar harus dipecah menjadi perubahan yang lebih kecil dan inkremental. (Seperti yang disebutkan dalam jawaban lain, pengembangan pada cabang mungkin memfasilitasi ini) Pada akhirnya, saya mungkin mengadaptasi mantra tersebut seperti: "Satu permintaan, satu (atau lebih!) Perubahan set".
rinogo

10

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 ke "Perubahan Anda" melakukan 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.


7

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

Contoh ini menunjukkan komit yang terlalu besar.

Sebagai pedoman praktis, jelaskan perubahan dalam satu kalimat atau satu baris teks. (Berdasarkan aturan ini, komit harus dipecah 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.


Repositori kernel Linux memiliki banyak contoh bagus untuk melanggar aturan ini - mereka sering memiliki banyak penjelasan tentang penyebab bug atau alasan untuk memperbaiki di tubuh pesan commit. Versi wajar dari aturan Anda adalah "Anda harus selalu dapat menjelaskan poin utama komit dalam 1 kalimat."
Ken Bloom

@ Ken: tujuan saya di sini adalah untuk membantu orang yang mengajukan pertanyaan, bukan untuk membuat aturan yang mencakup semua repositori kode sumber yang sudah ada sebelumnya di dunia.
azheglov

6

Di bidang saya (pemodelan fisika), saya menemukan bug di output hari ini yang tidak ada di repositori pada 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 itu 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).


Berbulan-bulan di antara komitmen terdengar persis seperti komitmen besar di sebagian besar metodologi modern ...
Rig

5

Bukan ukuran komit yang benar-benar penting, melainkan cakupan perubahan yang harus menentukan bagaimana komitmen Anda diorganisasikan.

Anda mungkin, misalnya mengubah setiap instance __macro1ke __macro2dalam 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 libfoomenjadi 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 mengembalikannya 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.

Walaupun 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 mengacaukan alat-alat seperti pembelahan jalan nanti, 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.


4

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

Ini bukan pertanyaan tentang "jangan membuat komitmen besar" seperti halnya membuat komitmen kecil - ideal untuk melakukan perubahan kecil yang terkandung.

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 Anda buat saat ini 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 terpisah 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

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 opsi untuk mengambil keuntungan dari VCS untuk menghilangkan jalan buntu yang Anda coba atau kode debugging khusus yang Anda tambahkan untuk melacak masalah. (misalnya dengan git reset --hardatau rm -rf *; svn update)


2

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

Ada adalah Namun pedoman yang komit lebih kecil lebih baik, dalam alasan (yaitu melakukan setiap baris adalah probaby berlebihan).

Saya mengingat pedoman semacam ini dalam pikiran:

  • Komit tunggal 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 - inilah yang saya ingat - YMMV. Pengembang yang berbeda menyukai tingkat granularitas yang berbeda.


1

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

Idealnya komit harus berupa 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

0

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

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 (terlebih lagi sekarang kita telah beralih ke git) Saya telah melakukan sebagian, karena memungkinkan untuk menangkap "mengapa" hal-hal dilakukan dengan cara ini.


Tampaknya sedikit, ekstrem. Komit harus mengatakan apa yang Anda perbaiki dan apa yang berubah. Dengan cara ini Anda dapat menemukan komit perilaku buruk jika sesuatu rusak, dan membuktikan bahwa Anda memperbaiki sesuatu.
TheLQ

@TheLQ: Sekali lagi, saya memberikan contoh banyak dari commit di kernel Linux, di mana pesan komit yang panjang berfungsi untuk mengkomunikasikan alasan untuk perubahan tertentu ke pengembang lain.
Ken Bloom

@TheLQ, begitulah cara kami bekerja. Ingat, Anda perlu memiliki "mengapa" di suatu tempat ...

0

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 citoolbisa sangat membantu untuk memecah pekerjaan Anda menjadi potongan-potongan kecil yang menyenangkan 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 file (atau baris spesifik mana) untuk komit dalam komit tertentu, sehingga Anda dapat memecah (tidak tumpang tindih) perubahan yang dibuat untuk file yang sama menjadi beberapa komit.

(Tampaknya 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.)


Ya itu adalah salah satu hal yang saya lewatkan tentang git: Kemampuan untuk melakukan hanya sebagian file. Saya pikir meskipun pada akhirnya akan berantakan karena saya akan melakukan 1 metode tetapi tidak yang baru itu tergantung pada, melanggar sesuatu.
TheLQ

@TheLQ: yah, itu yang harus Anda lakukan jika Anda ingin mengatur komit Anda menjadi potongan-potongan logis: menjadi sangat disiplin dalam melakukan lebih awal dan sering melakukan (dan jangan takut git rebaseuntuk bergabung dengan komitmen yang benar-benar merupakan bagian dari hal yang sama) revisi) ATAU belajar untuk secara akurat menjalani git citooldengan sisir bergigi halus untuk membagi hal-hal menjadi bagian logis ketika Anda siap untuk berkomitmen pada akhir hari.
Ken Bloom

0

Semakin besar komit, semakin besar kemungkinan Anda akan merusak bangunan 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

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 komitmen, tetapi memungkinkan Anda untuk mengembalikan tepat 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 kapan pun 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

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 commit 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.


-1

Perusahaan tempat saya bekerja meminta ulasan kode rekan untuk setiap komit. Karena itu, setiap komitmen yang menyulitkan rekan untuk mengetahui apa yang sedang terjadi dan meninjau dalam jumlah waktu yang masuk akal, terlalu besar.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.