Seberapa sering melakukan perubahan pada kontrol sumber? [Tutup]

Seberapa sering saya harus melakukan perubahan pada kontrol sumber? Setelah setiap fitur kecil, atau hanya untuk fitur besar?

Saya sedang mengerjakan sebuah proyek dan memiliki fitur jangka panjang untuk diimplementasikan. Saat ini, saya berkomitmen setelah setiap bagian dari pekerjaan, yaitu setiap sub-fitur diimplementasikan dan bug diperbaiki. Saya bahkan melakukan setelah saya menambahkan sejumlah tes untuk beberapa fitur setelah menemukan bug.

Namun, saya khawatir dengan pola ini. Di hari kerja yang produktif saya mungkin membuat 10 komitmen. Mengingat saya menggunakan Subversion, komit ini memengaruhi seluruh repositori, jadi saya ingin tahu apakah memang praktik yang baik untuk membuat begitu banyak?

Setiap kali saya menyelesaikan "pikiran penuh" kode yang mengkompilasi dan menjalankan saya check-in. Ini biasanya berakhir di mana saja antara 15-60 menit. Kadang-kadang bisa lebih lama, tetapi saya selalu mencoba checkin jika saya memiliki banyak perubahan kode yang saya tidak ingin menulis ulang jika terjadi kegagalan. Saya juga biasanya memastikan kode saya mengkompilasi dan saya check-in di akhir hari kerja sebelum saya pulang.

Saya tidak akan khawatir membuat "terlalu banyak" melakukan / check-in. Ini benar-benar menyebalkan ketika Anda harus menulis ulang sesuatu, dan senang bisa mengembalikannya sedikit demi sedikit.

Ketika Anda mengatakan bahwa Anda khawatir bahwa "komit Anda memengaruhi seluruh repositori" --- apakah Anda merujuk pada fakta bahwa jumlah revisi seluruh repositori meningkat? Saya tidak tahu berapa banyak bit yang digunakan Subversion untuk menyimpannya, tapi saya cukup yakin Anda tidak akan kehabisan angka revisi! Banyak komitmen tidak menjadi masalah. Anda dapat melakukan sepuluh kali lebih sering daripada pria di sebelahnya dan Anda tidak akan meningkatkan jejak karbon sama sekali.

Satu fungsi atau metode harus dinamai sesuai dengan fungsinya, dan jika namanya terlalu panjang, ia melakukan terlalu banyak. Saya mencoba menerapkan aturan yang sama untuk check-in: komentar check-in harus menjelaskan dengan tepat apa yang dicapai perubahan, dan jika komentar terlalu panjang, saya mungkin mengubah terlalu banyak sekaligus.

Saya suka artikel kecil ini dari Jeff Atwood: Check-In Awal, Check-In Sering

Saya pribadi mengkomit setiap grup kode logis yang selesai / stabil / kompilasi dan mencoba untuk tidak meninggalkan hari tanpa melakukan apa yang saya lakukan hari itu.

Jika Anda membuat perubahan besar dan khawatir tentang mempengaruhi orang lain yang bekerja pada kode, Anda bisa membuat cabang baru, dan kemudian bergabung kembali ke bagasi setelah perubahan Anda selesai.

Saya melakukan setiap kali saya selesai dengan tugas. Itu biasanya memakan waktu 30 menit hingga 1 jam.

Jika komentar kontrol versi Anda lebih panjang dari satu atau dua kalimat, Anda mungkin tidak cukup sering melakukan.

Saya mengikuti mantra open-source (diparafrasakan) - melakukan awal, melakukan sering.

Pada dasarnya, setiap kali saya pikir saya telah menambahkan fungsionalitas yang berguna (betapapun kecilnya) tanpa menimbulkan masalah bagi anggota tim lainnya.

Strategi komit-sering ini sangat berguna dalam lingkungan integrasi berkelanjutan karena memungkinkan pengujian integrasi terhadap upaya pengembangan lainnya, memberikan deteksi dini masalah.

Jangan komit kode yang tidak benar-benar berfungsi. Jangan gunakan repositori Anda sebagai solusi cadangan.

Sebagai gantinya, buat cadangan kode Anda yang tidak lengkap secara lokal dengan cara otomatis. Time Machine merawat saya, dan ada banyak program gratis untuk platform lain.

Aturan praktis yang saya gunakan adalah check-in ketika grup file yang check-in dapat dicakup oleh satu komentar check-in.

Ini umumnya untuk memastikan bahwa lapor-masuk bersifat atomik dan komentar dapat dengan mudah dicerna oleh pengembang lain.

Terutama benar ketika perubahan Anda mempengaruhi file konfigurasi (seperti file konteks musim semi atau file konfigurasi struts) yang memiliki cakupan luas aplikasi. Jika Anda membuat beberapa 'grup' perubahan sebelum check-in, dampaknya tumpang tindih dalam file konfigurasi, menyebabkan 2 grup menjadi bergabung satu sama lain.

Saya pikir Anda tidak perlu terlalu khawatir tentang seberapa sering. Yang penting di sini adalah apa, kapan, dan mengapa. Mengatakan bahwa Anda harus berkomitmen setiap 3 jam atau setiap 24 jam benar-benar tidak masuk akal. Berkomitmen ketika Anda memiliki sesuatu untuk dikomit, jangan jika Anda tidak.

Berikut ini kutipan dari praktik terbaik saya yang direkomendasikan untuk kontrol versi :

[...] Jika Anda melakukan banyak perubahan pada suatu proyek pada saat yang bersamaan, bagi mereka menjadi beberapa bagian logis dan lakukan dalam beberapa sesi. Ini membuatnya lebih mudah untuk melacak riwayat perubahan individu, yang akan menghemat banyak waktu Anda ketika mencoba menemukan dan memperbaiki bug di kemudian hari. Misalnya, jika Anda menerapkan fitur A, B dan C dan memperbaiki bug 1, 2 dan 3, itu akan menghasilkan total setidaknya enam komit, satu untuk setiap fitur dan satu untuk setiap bug. Jika Anda mengerjakan fitur besar atau melakukan refactoring yang luas, pertimbangkan untuk membagi pekerjaan Anda menjadi bagian yang lebih kecil, dan buat komit setelah setiap bagian selesai. Juga, ketika menerapkan perubahan independen ke beberapa modul logis, lakukan perubahan pada setiap modul secara terpisah, bahkan jika itu adalah bagian dari perubahan yang lebih besar.

Idealnya, Anda tidak boleh meninggalkan kantor Anda dengan perubahan tanpa komitmen pada hard drive Anda. Jika Anda sedang mengerjakan proyek di mana perubahan akan memengaruhi orang lain, pertimbangkan untuk menggunakan cabang untuk menerapkan perubahan Anda dan menggabungkannya kembali ke bagasi saat Anda selesai. Ketika melakukan perubahan pada perpustakaan atau proyek yang bergantung pada proyek lain — dan dengan demikian, orang lain — pastikan Anda tidak merusak bangunan mereka dengan melakukan kode yang tidak dapat dikompilasi. Namun, memiliki kode yang tidak dikompilasi bukan alasan untuk menghindari melakukan. Gunakan cabang sebagai gantinya. [...]

Pola Anda saat ini masuk akal. Ingatlah bagaimana Anda menggunakan kontrol sumber ini: bagaimana jika Anda harus mengembalikan, atau jika Anda ingin melakukan diff? Potongan yang Anda jelaskan tampak seperti perbedaan yang tepat dalam kasus-kasus tersebut: diff akan menunjukkan kepada Anda apa yang berubah dalam mengimplementasikan bug # (ditentukan dalam checkin log), atau persis seperti apa kode baru untuk mengimplementasikan fitur. Kembalikan, sama, hanya akan menyentuh satu hal pada suatu waktu.

Saya juga suka berkomitmen setelah saya menyelesaikan sepotong pekerjaan, yang sering beberapa kali sehari. Saya pikir lebih mudah untuk melihat apa yang terjadi dalam komit kecil daripada yang besar. Jika Anda khawatir tentang terlalu banyak komit, Anda dapat mempertimbangkan untuk membuat cabang dan menggabungkannya kembali ke bagasi ketika seluruh fitur selesai.

Berikut ini adalah posting blog terkait: Coding Horror: Check-In Awal, Check-In Sering

Seperti yang telah dinyatakan orang lain, cobalah untuk melakukan satu potongan logis yang "cukup" cukup sehingga tidak menghalangi pengembang lain (misalnya, itu membangun dan melewati tes otomatis).

Setiap tim pengembang / perusahaan harus mendefinisikan apa yang "cukup lengkap" untuk setiap cabang. Misalnya, Anda mungkin memiliki cabang fitur yang hanya memerlukan kode untuk dibuat, Batang yang juga membutuhkan kode untuk lulus pengujian otomatis, dan label yang menunjukkan sesuatu telah lulus pengujian QA ... atau sesuatu seperti itu.

Saya tidak mengatakan bahwa ini adalah pola yang baik untuk diikuti; Saya hanya menunjukkan bahwa bagaimana dilakukan "dilakukan" tergantung pada kebijakan tim / perusahaan Anda.

Saat Anda memikirkannya.

(selama apa yang Anda laporkan aman)

Tergantung pada sistem kode sumber Anda dan apa lagi yang Anda miliki. Jika Anda menggunakan Git, maka komit setiap kali Anda menyelesaikan langkah. Saya menggunakan SVN dan saya ingin komit ketika saya menyelesaikan seluruh fitur, jadi, setiap satu hingga lima jam. Jika saya menggunakan CVS saya akan melakukan hal yang sama.

Saya setuju dengan beberapa tanggapan: jangan centang kode yang tidak akan dikompilasi; gunakan cabang atau repositori pribadi jika kekhawatiran Anda memiliki "cadangan" kode atau perubahannya; check in ketika unit logis selesai.

Satu hal lain yang akan saya tambahkan adalah bahwa tergantung pada lingkungan Anda, tingkat check-in dapat bervariasi sesuai waktu. Misalnya, pada awal proyek yang memeriksa setelah setiap bagian fungsional dari suatu komponen selesai, masuk akal untuk keselamatan dan memiliki sejarah revisi (saya berpikir tentang kasus-kasus di mana bit-bit sebelumnya mendapatkan refactored ketika yang kemudian sedang dikembangkan). Kemudian dalam proyek, di sisi lain, fungsi yang sepenuhnya lengkap menjadi lebih penting, terutama selama pengembangan / pengujian integrasi. Setengah integrasi atau setengah memperbaiki tidak membantu siapa pun.

Adapun memeriksa setelah setiap perbaikan bug: kecuali perbaikannya sepele, tentu saja! Tidak ada yang lebih menyusahkan daripada menemukan bahwa satu check-in berisi tiga perbaikan dan salah satunya harus dibatalkan. Lebih sering daripada tidak tampaknya bahwa dalam situasi itu pengembang memperbaiki tiga bug di satu area dan melepaskan perubahan mana yang pergi ke mana perbaikan bug adalah mimpi buruk.

Saya juga suka check in secara teratur. Itulah setiap kali saya menyelesaikan langkah menuju tujuan saya.

Ini biasanya setiap beberapa jam .

Kesulitan saya adalah menemukan seseorang yang bersedia dan mampu melakukan begitu banyak ulasan kode .

Kebijakan perusahaan kami adalah bahwa kami perlu melakukan tinjauan kode sebelum kami dapat memeriksa apa pun yang masuk akal, tetapi tidak selalu ada seseorang di departemen yang memiliki waktu untuk segera melakukan tinjauan kode. Solusi yang memungkinkan:

1. Lebih banyak pekerjaan per check-in; less checkins == less reviews
2. Ubah kebijakan checkin perusahaan. Jika saya baru saja melakukan beberapa refactoring dan unit test semuanya menjadi hijau, mungkin saya bisa mengendurkan aturan?
3. Tunda perubahan sampai seseorang dapat melakukan tinjauan dan terus bekerja. Ini bisa bermasalah jika pengulas tidak suka kode Anda dan Anda harus mendesain ulang. Menyulap berbagai tahapan tugas dengan 'mengesampingkan' perubahan bisa menjadi berantakan.

Saya suka melakukan perubahan setiap 30-60 menit, asalkan dikompilasi dengan bersih dan tidak ada regresi dalam tes unit.

Nah, Anda bisa memiliki cabang sendiri yang dapat Anda komit sesering mungkin, dan ketika Anda selesai dengan fitur Anda, Anda bisa menggabungkannya ke trunk utama.

Pada frekuensi Komit, saya memikirkannya seperti ini, berapa banyak rasa sakit bagi saya jika hard disk saya jatuh dan saya tidak melakukan sesuatu - kuantum dari sesuatu ini bagi saya adalah sekitar 2 jam kerja.

Tentu saja, saya tidak pernah melakukan sesuatu yang tidak dapat dikompilasi.

Setidaknya satu kali sehari.

Saya tidak memiliki batas waktu spesifik per komit, saya cenderung melakukan setelah tes lulus dan saya senang dengan kode. Saya tidak akan melakukan kode yang tidak mengkompilasi atau sebaliknya dalam keadaan yang saya tidak akan merasa baik tentang kembali jika terjadi kegagalan

Anda harus menyeimbangkan kompromi antara keselamatan dan pemulihan di satu sisi dan kemudahan manajemen perubahan untuk seluruh proyek di sisi lain.

Skema terbaik yang saya gunakan memiliki dua jawaban untuk pertanyaan itu.

Kami menggunakan 2 repositori yang sepenuhnya terpisah: satu adalah repositori lebar proyek dan yang lain adalah repositori pribadi kami sendiri (kami menggunakan rcs pada saat itu).

Kami akan memeriksa repositori pribadi kami dengan sangat teratur, hampir setiap kali Anda menyimpan file terbuka Anda. Dengan demikian, repositori pribadi pada dasarnya adalah penyangga yang besar, berjangkauan panjang, dan dibatalkan.

Setelah kami memiliki sejumlah kode yang akan dikompilasi, diuji ok dan diterima sebagai siap untuk penggunaan umum itu diperiksa ke repositori proyek.

Sayangnya sistem ini bergantung pada penggunaan berbagai teknologi VCS agar dapat dikerjakan. Saya belum menemukan metode yang memuaskan untuk mencapai hasil yang sama saat menggunakan dua VCS dari jenis yang sama (mis. Dua repositori subversi)

Namun, saya mendapatkan hasil yang dapat diterima dengan membuat cabang pengembangan "pribadi" dalam repositori subversi - memeriksa cabang secara teratur dan kemudian bergabung ke dalam bagasi setelah selesai.

Jika Anda bekerja pada cabang yang tidak akan dirilis, komit selalu aman.

Namun, jika Anda membaginya dengan pengembang lain, melakukan kode yang tidak berfungsi mungkin akan sedikit mengganggu (terutama jika itu di tempat yang penting). Biasanya saya hanya melakukan kode yang secara efektif "berfungsi" - bukan karena sudah sepenuhnya diuji, tetapi saya sudah memastikan bahwa itu benar-benar mengkompilasi dan tidak langsung gagal.

Jika Anda menggunakan pelacak bug terintegrasi, mungkin perlu dilakukan komit terpisah jika Anda telah memperbaiki dua bug, sehingga log komit dapat bertentangan dengan bug yang tepat. Tetapi sekali lagi, kadang-kadang satu perubahan kode memperbaiki dua bug, jadi Anda hanya harus memilih yang mana yang akan dilawan (kecuali sistem Anda mengizinkan satu komit untuk dikaitkan dengan banyak bug)

Saya masih percaya pada frasa 'komit sering, komit awal'. Saya lebih suka VCS terdesentralisasi seperti Mercurial dan tidak ada masalah untuk melakukan beberapa hal dan mendorongnya ke atas nanti.

Ini benar-benar pertanyaan umum, tetapi pertanyaan sebenarnya adalah: Dapatkah Anda melakukan kode yang belum selesai?

Setiap kali Anda menyelesaikan beberapa kode yang berfungsi dan tidak akan mengacaukan orang lain jika mereka mendapatkannya dalam pembaruan.

Dan pastikan Anda berkomentar dengan benar.