Kapan saya harus membuat komit pertama ke kontrol sumber?


118

Saya tidak pernah yakin kapan suatu proyek cukup jauh untuk pertama-tama berkomitmen pada kontrol sumber. Saya cenderung menunda komitmen sampai proyek selesai 'kerangka kerja,' dan saya terutama melakukan fitur sejak saat itu. (Saya belum melakukan proyek pribadi yang cukup besar untuk memiliki kerangka kerja inti yang terlalu besar untuk ini.) Saya merasa ini bukan praktik terbaik, meskipun saya tidak yakin apa yang salah.

Katakanlah, misalnya, saya memiliki proyek yang terdiri dari satu file kode. Diperlukan sekitar 10 baris kode boilerplate, dan 100 baris untuk membuat proyek bekerja dengan fungsionalitas yang sangat mendasar (1 atau 2 fitur). Haruskah saya check-in lebih dulu:

  1. File kosong?
  2. Kode boilerplate?
  3. Fitur pertama?
  4. Di beberapa titik lain?

Juga, apa alasan untuk check-in pada titik tertentu?


10
sebelum Anda pulang, Anda berkomitmen untuk cabang kerja Anda sendiri.
Reactgular

59
Komit pertama harus selalu dilakukan setelah membuat proyek Sourceforge, membuat situs web, mengkonfigurasi milis, dan membuat blog tentang proyek selama beberapa tahun. :)
Kaz

15
Apa kerugiannya melakukan terlalu dini atau sering?
Isaac Rabinovitch

13
mkdir myproj; cd myproj; git init; mulai bekerja.
Eddie B

10
Saya belajar cara mengelola kemajuan penyimpanan dari tombol simpan cepat di video game. Aturannya kira-kira seperti: Will I mind having to redo that part ? Save : SaveAnyway;Saya mengambil pendekatan yang sama untuk kontrol sumber, saya tidak menunggu sesuatu untuk bekerja atau hampir selesai, saya hanya menunggu sampai saya menemukan sesuatu atau membuat cukup perubahan yang tidak saya inginkan harus mencoba mencari tahu itu lagi atau membuat perubahan itu lagi, maka saya check in. Itulah sebabnya orang menyarankan penghematan setelah pembuatan proyek; Membuat proyek itu menyebalkan, masuklah sehingga Anda benar-benar tidak perlu melakukannya lagi.
Jimmy Hoffa

Jawaban:


103

Anda harus melakukan komitmen segera setelah Anda memiliki "unit" yang masuk akal.

Apa itu unit? Itu tergantung pada apa yang Anda lakukan; jika Anda membuat proyek Visual Studio, misalnya, lakukan solusi tepat setelah penciptaannya, bahkan jika tidak ada apa pun di dalamnya.

Dari sana, tetap komit sesering mungkin, tetapi masih komit hanya "unit" yang selesai (misalnya kelas, konfigurasi, dll); melakukan hal itu akan membuat hidup Anda lebih mudah jika terjadi kesalahan (Anda dapat mengembalikan sejumlah kecil perubahan) dan akan mengurangi kemungkinan konflik.


27
Saya berkomitmen dekat dengan cabang kerja, dan saya menggabungkan cabang itu ke jalur utama dalam satuan. Ini memberikan yang terbaik dari kedua dunia karena garis utama dibuat dari unit dengan set kecil perubahan untuk dikembalikan, tetapi cabang topik dapat membiarkan saya mundur sedikit demi sedikit.
Jeff Ferland

16
Komit tidak pernah terlalu kecil! Jangan menahan diri dari melakukan perubahan Anda!
Leonardo Herrera

1
Saya akan mengatakan +1 kepada banyak komit kecil dan sering, tergantung pada alur kerja Anda dan berapa banyak orang yang tertarik pada repo Anda untuk menyelesaikan pekerjaan mereka. Kemampuan Git untuk menulis ulang sejarah sedikit sehingga 15 komitmen itu FooSerializerdapat menjadi satu hal sebelum Anda mendorongnya.
Pos Tim

1
@loldop: Itu tergantung pada perangkat lunak kontrol versi yang Anda gunakan. Katakanlah Anda menggunakan Git: Anda dapat menyembunyikan apa yang telah Anda lakukan, lakukan perbaikan, komit, aplikasikan kembali perubahan yang disembunyikan dan mulai kembali bekerja pada mereka. Di Subversion, Anda dapat melakukan checkout lagi dari repositori di folder lain, memperbaiki bug dan komit ke repositori di sana tanpa memengaruhi refactoring Anda. Atau buat file tambalan, kembalikan hasil edit, perbaiki bug, komit, pasang kembali tambalan. Ada banyak cara untuk melakukannya.
Albireo

1
Mungkin itu adalah jawaban yang baik untuk komit ke-2, ke-3, dll. Tetapi yang pertama harusnya kosong saja.
Felipe

143

Sejauh yang saya ketahui, repo kontrol sumber Anda adalah bagian dari pengaturan proyek dasar, jadi saya berkomitmen tepat setelah saya menghasilkan proyek kosong saya.


29
Berkomitmen awal, komit sering.
Leonardo Herrera

11
Saya setuju dengan ini lebih dari jawaban yang diterima. Saya juga melihat kontrol sumber (maksud saya DVCS) sebagai tombol undo besar jika saya secara brutal mengacaukan segalanya. Saya juga sangat merekomendasikan menggunakan semver (via tag) dan mulai dengan versi 0
Antony Scott

2
Terima kasih @AntonyScott Saya setuju 100% dengan jawaban yang diterima, tetapi ketika saya menulis ini, saya memiliki visi memperkeruh perairan dengan esai 1500 kata tentang bagaimana saya mengelola kontrol sumber dan mengapa. Jadi saya memutuskan untuk tetap sederhana dan to the point.
John MacIntyre

2
Ya +1. Jika Anda merasa tidak enak dengan komit kosong, mulailah dengan .gitignore (atau yang setara) seperti yang ditulis Xion dalam jawaban lain [ programmers.stackexchange.com/a/176845/5405] . Itu komit pertama yang sangat alami.
Hanno Fietz

Saya perhatikan bendera "jawaban panjang" pada pertanyaan itu, dan saya pikir itu merujuk pada jawaban ini. AFAIC saya menjawab 'mengapa?' pertanyaan dengan "repo kontrol sumber adalah bagian dari pengaturan proyek dasar" bagian dari jawabannya. Seperti yang saya katakan, saya bisa menulis esai tentang filosofi lengkap saya tentang bagaimana saya menggunakan kontrol sumber, tetapi itu hanya akan mengurangi jawaban ini. Jika ada orang yang memiliki pertanyaan spesifik tentang jawaban saya, saya akan dengan senang hati menjawabnya, tetapi jika tidak saya tidak ingin mengacaukan jawaban ini demi verbage. Jika Anda ingin menghapusnya, silakan.
John MacIntyre

77

Kemarin

... sebagai alternatif, jika Anda tidak dapat melakukan perjalanan waktu ...
(mungkin mobil Anda tidak dapat mencapai 88mph, atau kapasitor fluks Anda baru saja patah)

Sekarang

Proyek-proyek baru harus dilakukan di tempat berdarah, itu gila untuk tidak melakukannya, dan sistem DVCS kontemporer hanya menghapus setiap alasan yang mungkin untuk menghindari komitmen : git init . ; git add * ; git commit -m initial-commitsekarang, sebelum terlambat, seperti yang mungkin sudah terjadi.

Satu pertanyaan yang lebih masuk akal, dapat diperdebatkan, bisa saja: "Kapan saya harus menggabungkan komitmen saya ke kontrol sumber bersama pada repositori yang dikelola tim pada proyek yang sudah mapan ?" (catat kata sifat, kata sifat itu penting) Dan saya merasa sebagian besar jawaban lain sebenarnya mencoba menjawabnya.

Cabang pribadi Anda harus berkomitmen seperti orang gila , setidaknya sekali sehari , sebelum tidur. Anda mungkin baru saja bangun keesokan paginya, dan tidak tahu apa yang Anda lakukan, malam sebelumnya. VCS harus melindungi Anda dari hal itu, dan memiliki kesempatan untuk mengembalikan ke sub-versi-dari-a-versi yang sangat baru yang mengkompilasi dengan baik, berjalan dengan lancar, dan / atau lulus tes mungkin merupakan pilihan terbaik Anda.


3
Saya tidak keberatan melakukan perubahan yang tidak dikompilasi, terutama di akhir hari. Hari berikutnya Anda memiliki sesuatu yang tidak dikompilasi tetapi Anda masih memiliki riwayat komit Anda - jika Anda tidak ingin riwayat Anda "kotor" ada opsi untuk kembalikan di setiap DVCS yang baik (saya pikir kita semua setuju DVCS adalah satu - satunya cara untuk pergi.)
Leonardo Herrera

@LeonardoHerrera Saya memahami POV Anda, meskipun dalam proyek bahasa yang ditafsirkan dengan beberapa titik masuk, Anda akhirnya melakukan beberapa cabang yang tidak dapat dikompilasi dengan alasan yang sah (seperti berbagi perbaikan bug pada titik masuk yang berbeda) tentu saja dapat dilakukan dengan cara yang lebih baik dan lebih baik. , tapi kemudian itu menjadi masalah selera ... dan de gustibus non est disputandum .
ZJR

20

Saya akan mengatakan komit sesegera mungkin. Tujuan utama dari kontrol sumber adalah memungkinkan Anda untuk kembali jika terjadi kesalahan, dan ini beresonansi dengan latihan "komit awal dan sering".

Secara pribadi, komit pertama saya biasanya hanya berisi file .gitignore (atau yang setara) dengan beberapa filter yang saya tahu akan diperlukan, seperti * .py [co] untuk kode Python. Setup proyek dasar dan / atau prototipe sederhana pertama adalah apa yang biasanya terjadi.


Saya melakukan hal serupa. Karena saya menggunakan GitHub, saya juga selalu memiliki file README dasar, bahkan hanya berisi nama proyek. Saya menemukan memiliki file di sana sejak awal membuat jauh lebih mungkin bahwa saya akan memperbaruinya di masa depan :).
Tikhon Jelvis

16

Komit pertama dapat berupa file README dengan hanya satu ringkasan baris proyek, atau informasi yang cukup tentang tonggak pertama proyek. Topik luas juga dapat mencakup:

  • pengantar
  • Deskripsi Proyek
  • Struktur proyek
  • Konvensi pengkodean
  • Petunjuk tentang cara:
    • membangun
    • uji
    • menyebarkan
  • Masalah dan solusi yang diketahui
  • daftar todo
  • Syarat Penggunaan

Praktik memperbarui README sebelum membuat perubahan pada sebuah proyek juga disebut sebagai Readme Driven Development dan memungkinkan Anda untuk memikirkan perubahan sebelum menginvestasikan waktu dalam membuat perubahan tersebut.

Siapa pun yang ingin berkontribusi atau menggunakan perangkat lunak ini kemudian akan mulai dengan README.


12

Jika Anda telah melakukan pekerjaan yang tidak ingin Anda hilangkan, itu harus ada dalam sistem kontrol sumber Anda.

Ini tentu berlaku untuk sistem terdistribusi seperti Git. Jika Anda menggunakan sistem terpusat, dan satu-satunya cara untuk memeriksa sesuatu adalah membuatnya terlihat oleh semua orang , Anda mungkin ingin menunda - atau Anda mungkin mempertimbangkan untuk menyiapkan repositori git lokal Anda sendiri, dan mengirimkan ke pusat sistem ketika Anda siap.


3
Aturan saya adalah ini, dengan tambahan bahwa saya juga ingin menjadi "titik waktu di mana kode dikompilasi". Komit apa yang tidak dikompilasi dan dibagi dua akan jauh lebih menyebalkan, jika Anda harus menemukan ketika Anda memecahkan sesuatu.
Warren P

Bukankah cabang sementara akan mengatasinya, setidaknya untuk git? Saya belum git bisectbanyak menggunakan .
Keith Thompson

Saya menggunakan lincah tanpa rebase jadi saya memperlakukan semua komit sebagai permanen
Warren P

7

Aturan praktis saya adalah untuk memeriksa setelah file solusi saya (atau potongan skrip build lainnya) selesai, bahkan jika itu berisi beberapa file yang kosong. Ini praktik yang baik ketika lebih dari satu orang mengerjakan proyek. File itu cenderung memiliki masalah penggabungan terburuk pada awalnya karena orang menambahkan hal-hal pada proyek sehingga perlu dilakukan lebih awal dan sering.

Bahkan jika Anda adalah satu-satunya yang mengerjakan proyek dan hanya punya satu file, saya merasa lebih mudah untuk mengikuti alur kerja yang sama dan menyimpan pemikiran untuk masalah yang ada.


6

Tidak yakin apakah itu disebutkan.

Tetapi pastikan bahwa apa yang Anda komit menjalankan / kompilasi! Jadi tidak ada kesalahan sintaks, dll.

Tidak ada yang lebih membuat frustrasi daripada kode checkout yang rusak.


memang, masuk akal!
Aquarius_Girl

Saya tidak setuju. Jika kode saya tidak dikompilasi ketika saya ingin komit, saya menulis WIP di suatu tempat di pesan komit. Maka saya bisa mengabaikan komit itu ketika saya membutuhkan versi terbaru yang dikompilasi.
Minthos

5

Pandangan lain yang lebih terkait dengan pengujian perangkat lunak (pendekatan TDD) akan dilakukan segera setelah Anda memiliki kasus pengujian baru berwarna hijau. Ini berarti Anda telah menyelesaikan "unit" kode.


Untuk membahas suatu metode, Anda mungkin (sebagian besar) memerlukan beberapa unit test untuk itu. Tidak sepenuhnya benar untuk mengatakan jika Anda membuat tes lulus, maka itu berarti Anda menyelesaikan satu unit kerja. Bahkan tidak benar untuk mengatakan bahwa menyelesaikan metode adalah unit kerja.
Behnam Rasooli

5

Tepat sebelum Anda melakukan sesuatu yang konyol.

Bagi kita yang tidak memiliki kekuatan magis, itu berarti sedikit dan sering.

Jika Anda bekerja sendiri, lakukan setiap kali Anda minum, atau apa pun.

Jika Anda bekerja dalam tim, Anda mungkin perlu memastikan bahwa hal itu dikompilasi, sehingga jika orang lain mendapatkan yang terbaru, mereka tidak akan mendapatkan sekumpulan kesalahan. Tapi selain itu, sebisa mungkin.


4

Sekitar 2 ~ 3 jam ke dalam proyek.

Hanya bercanda. Tidak ada satu jawaban yang cocok untuk semua situasi. Pertama-tama, jika Anda memiliki sistem kontrol versi terdistribusi (seperti git atau Mercurial) maka komit ke repo lokal Anda tidak akan melindungi data Anda jika terjadi kegagalan yang dahsyat. Tetapi repo jarak jauh pribadi mungkin dikenakan biaya uang, misalnya pada github. Anda akan menyimpan histori komit, tetapi dalam pengalaman saya Anda tidak akan membutuhkan itu sampai proyek Anda sedikit maju.

Anda juga mungkin tidak ingin terlalu banyak churn di awal, terutama jika Anda memindahkan file. Melakukan perubahan akan menjadi beban jika hanya perubahan kecil. Anda bahkan dapat memutuskan untuk membuang benda itu. Tetapi jika Anda kehilangan perubahan yang tidak mudah untuk direplikasi maka Anda akan kehilangan telah membuat salinan cadangan, dan sistem kontrol versi membuat sistem cadangan yang sangat berharga.

Beberapa orang saat ini menggunakan DropBox atau sejenisnya untuk menyimpan kode mereka. Ini mungkin merupakan kompromi yang baik di awal proyek karena tidak ada upaya untuk menyiapkannya. Namun kebiasaan biadab dalam pengembangan perangkat lunak yang serius, terutama jika beberapa orang menyentuh kode pada saat yang sama.

Jadi, saya cenderung mengatur kontrol versi setiap kali saya memiliki sesuatu yang berharga, yaitu tidak sepele untuk ditiru. Nilai bersifat subjektif (dan tergantung pada kapasitas seseorang) sehingga Anda harus membuat penilaian sendiri. Pada saat itu saya menyimpan repo kedua pada disk eksternal, atau pada github jika itu adalah proyek publik atau akun pembayaran saya akan menahannya.


3

Banyak orang sudah menjawab "Segera", dan saya 100% setuju. Saya juga suka saran Xion untuk memulai dengan pola abaikan VCS (yaitu .gitignoreatau setara).

Saya kira sudah cukup banyak disepakati bahwa tidak ada kerugian untuk komitmen awal. Saya ingin menambahkan keuntungan:

  • Anda cenderung melakukan hal-hal yang Anda pilih untuk dibuang tetapi itu masih ada. Ketika saya memulai pengembangan baru, saya akan mengkodekan dan menghapus hal-hal dengan cepat, dan ketika saya melakukan nanti, ketika sudah ada banyak file, saya secara tidak sengaja melakukan hal-hal hanya untuk menghapusnya di komit berikutnya. Ini, sebagai lawan dari komit kecil, atau bahkan kosong, adalah kebisingan sejati dalam sejarah.
  • Jika Anda adalah tipe yang sistematis dan memiliki langkah-langkah pertama yang khas dalam proyek Anda, menjadikannya sebagai titik komit dapat menjadi petunjuk bagi Anda atau orang lain, dan bahkan mungkin memberikan kesempatan untuk bercabang pada titik tertentu dan membuat rintisan proyek yang dapat digunakan kembali. Saya telah bekerja pada proyek berbasis Maven di mana ini berguna (karena dalam mendirikan proyek Maven, beberapa langkah kecil pertama sudah dapat mendefinisikan basis yang cukup besar, dan sementara langkah-langkah itu tidak banyak dilakukan , mereka mungkin memerlukan pemikiran yang cukup untuk menjamin dapat digunakan kembali).

2

Ini mungkin tergantung VCS mana yang Anda gunakan.

Dengan Git, saya melakukan direktori kosong (atau dengan file README hampir kosong). Intinya adalah bahwa saya dapat kembali dan mereset cabang saya ke keadaan kosong jika saya ingin memulai dari awal sementara saya masih awal dalam proses pengembangan (sebelum mendorong hulu). Saya kemudian akan melakukan file "dihasilkan" saya (misalnya solusi visual studio). Kemudian ketika saya benar-benar coding saya akan mulai melakukan setiap unit seperti biasa.

Dengan SVN, Anda mendorong hulu dengan setiap komit sehingga Anda benar-benar tidak mendapatkan kemewahan memulai kembali seperti yang Anda lakukan dengan Git. Dalam hal ini, mungkin tidak bermanfaat untuk melakukan komitmen lebih awal jika Anda pikir Anda akan melakukan pembenahan besar di awal proses. Itu akan tergantung pada orang yang mengkode.


2

Ketika saya memulai proyek baru saya biasanya memulai dengan melakukan itu sebelum kode apa pun telah ditambahkan. Aturan umum yang selalu saya ikuti adalah: jika PC Anda crash dan menghapus semua data Anda kode apa yang Anda inginkan untuk tidak harus menulis dari memori. Sepuluh tahun yang lalu sebelum TDD dan praktik pemrograman yang lebih baik, saya cukup optimis tentang apa yang dapat saya ingat. Sekarang, saya cenderung lebih berhati-hati. Seperti banyak poster lainnya katakan komit lebih awal dan komit sering. Anda tidak kehilangan apa pun dengan melakukannya.

Saya bekerja sendiri untuk sebagian besar waktu sehingga saya harus mengakui bahwa saya menjadi malas tetapi saya umumnya berkomitmen sebelum saya pulang. Dengan begitu jika saya tidak berhasil besok, maka rekan-rekan saya dapat mengambil di mana saya tinggalkan.

Saat ini saya menggunakan Tortoise / SVN di tempat kerja.


2

Segera lakukan proyek kosong. Teruslah berkomitmen beberapa kali per jam yang Anda habiskan untuk mengerjakan proyek. Berkomitmen bahkan jika kode tidak dikompilasi. Saya menandai komit tersebut dengan "WIP" di pijit komit untuk melacak mereka.

Saya juga memiliki skrip yang secara otomatis melakukan semua proyek saya setiap 10 menit ke repo cadangan, kalau-kalau saya lupa melakukan secara manual. Sebut saja buffer undo yang didukung cloud saya.

Lapor masuk (alias. Push ) proyek ke repo tim saat Anda membutuhkan tim Anda untuk melihat kode Anda. Yang mungkin sebelum kode Anda siap dilihat oleh tim Anda, jika Anda seperti saya.

Jika Anda ingin bersikap baik kepada tim Anda, hancurkan komitmen Anda sebelum mendorongnya ke repo tim.


1

Saya telah membaca semua artikel dan saya pikir kami sudah mendapatkan banyak solusi bagus tetapi saya ingin membagikan metodologi saya dengan Anda.

Saat bekerja pada pembuatan kerangka kerja (langsung dari awal) banyak perubahan akan terjadi untuk setiap modul sampai modul selesai atau diselesaikan. Jadi saya selalu memiliki 2 lokasi satu dinamai DINAMIS dan lainnya adalah STATIC. Ketika perubahan sedang terjadi dan kerangka kerja belum difinalisasi, itu sudah dilakukan di lokasi DYANMIC dan setelah selesai dan diselesaikan saya memindahkannya ke lokasi STATIC. Jadi saya punya Kontrol Sumber yang lengkap.

Terima kasih


0

Dengan aplikasi apa pun, Anda akan menghabiskan waktu merancang komponen. Anda harus tahu, secara kasar atau terperinci, ruang nama Anda, proyek, referensi eksternal, perpustakaan pihak ketiga dll.

Jika Anda berada di sebuah tim, saya akan menyarankan pemimpin Anda, atau siapa pun yang dipilih, untuk membuat proyek dasar, mengatur dependensi, dan memeriksa kerangka itu (fondasi tempat proyek Anda akan dibangun).

Anda juga ingin memastikan Anda memiliki tugas, rilis, trunk, dll. Cabang yang ditentukan sebelum check-in sehingga proses Anda solid.

Jika Anda sedang mengerjakan "tugas" baru untuk proyek yang sudah berjalan dan Anda berada di cabang tugas Anda sendiri, lakukan lapor masuk malam hari sehingga Anda dapat mempertahankan pekerjaan Anda.


0

Biasanya saya check-in setiap kali saya menambahkan sesuatu yang baru, tetapi mencoba untuk memisahkan hal-hal dalam komit diskrit.

Itu berarti, jika saya menambahkan ketergantungan baru, saya membuat perubahan sampai mereka mengkompilasi, atau mereka cukup besar sehingga akan kehilangan waktu untuk melakukannya lagi, dari awal. Jika saya memiliki tugas yang lebih besar, saya mencoba melakukan beberapa kali, ketika itu masuk akal (sekali per fungsi, setiap kali saya membuatnya kompilasi dan berjalan dengan sukses, dll).

Saya juga berkomitmen ketika saya ingin titik cadangan (yaitu "jika apa yang saya coba sekarang tidak akan berfungsi atau menjadi terlalu rumit, saya ingin kembali ke kode seperti sekarang", atau ketika seseorang meminta saya untuk meninggalkan saya apa adanya melakukan dan memperbaiki beberapa masalah mendesak).

Jika Anda menggunakan sistem kontrol sumber terpusat, Anda tidak dapat melakukan komit untuk poin cadangan, karena komit yang tidak dikompilasi / bekerja memengaruhi semua orang di tim Anda.

Biasanya ketika saya mulai menambahkan kode boilerplate (mis. Tambahkan webapp baru di situs web Django), saya melakukan setiap operasi yang saya lakukan.

Jika saya mengikuti tutorial untuk membuat / menulis kode, saya menggunakan nama langkah dalam tutorial untuk pesan komit. Dengan cara ini, saya dapat melakukan revisi dan melihat apa yang dilakukan langkah tutorial, kapan saja.

Katakanlah, misalnya, saya memiliki proyek yang terdiri dari satu file kode. Diperlukan sekitar 10 baris kode boilerplate, dan 100 baris untuk membuat proyek bekerja dengan fungsionalitas yang sangat mendasar (1 atau 2 fitur).

Itu akan tergantung pada seberapa sulit menambahkan barang itu:

  • jika sepele untuk menambahkan kode pelat ketel, saya akan menambahkannya dan melakukan komit sebelum memulai pada kode lainnya (dengan cara ini, jika saya membuat kesalahan atau memperkenalkan bug aneh nanti, saya dapat dengan mudah kembali ke kode boilerplate dan mulai lagi).

  • Jika kodenya non-sepele, saya akan melakukan setiap kali saya menambahkan sesuatu yang baru (di mana saja antara setiap dua baris kode berubah, menjadi sekitar seratus atau lebih).

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.