Apa yang harus saya sertakan dalam repositori saya dari proyek IDE

10

Saya ingin menambahkan proyek yang dalam hal ini dibuat di Netbeans tetapi pertanyaan ini umum untuk sebagian besar IDE. Sederhana saja, apa yang harus saya sertakan dalam repositori saya. Misalnya Netbeans membuat folder nbproject, gerhana membuat folder .settings dll. Harus saya sertakan ini dalam repositori saya, apa keuntungan / kerugian termasuk atau tidak termasuk pengaturan spesifik proyek.

Dalam hal ini adalah proyek pribadi jadi saya tidak membayangkan bahwa orang lain akan mulai mengerjakannya, tetapi akan menyenangkan untuk menambahkan minimum pengaturan proyek sehingga proyek itu sendiri akan mudah untuk mulai bekerja pada mesin yang berbeda.

— Daniel Figueroa
sumber

Pertimbangkan alat-alat seperti pakar dengan plugin gerhana (atau ide lain) untuk mengatur lingkungan yang tepat daripada memasukkan milik Anda.

@MichaelT Saya sangat menyesal tapi saya tidak benar-benar mengikuti, maukah Anda memperluas itu?

— Daniel Figueroa

Menggunakan alat bangun, dan memiliki alat bangun mengatur lingkungan untuk ide memungkinkan Anda diyakinkan bahwa setup adalah sama tidak peduli apa platform (atau ide). Bahkan pengembang solo memiliki beberapa lingkungan (ide vs build). Ini menyederhanakan pertanyaan menjadi salah satu yang dijawab "jangan centang apa pun yang khusus untuk lingkungan Anda karena mereka dihasilkan kode." - Rasional yang sama yang tidak Anda periksa di kelas .java yang dihasilkan oleh jaxb, melainkan instruksi (build.xml atau .pom file) tentang cara membangunnya.

Jika itu "asli" adalah harus didukung. Jika itu berubah dan mereka perlu pelacakan dan asli, itu harus dikendalikan revisi. Tangkapan - bagaimana menyusun repo Anda sehingga sumber Anda tetap sumber Anda, sementara konfigurasi rantai alat Anda tidak mencemari repo sumber. Hal yang sama berlaku untuk sumber daya seperti gambar, suara dan video ....

— mattnz

4

Itu benar-benar tergantung pada data apa itu dan harus diputuskan berdasarkan kasus per kasus, bahkan mungkin untuk file individual. Lihatlah isi dari file-file itu. Lebih sering Anda tidak tahu apa artinya. Hal-hal seperti posisi dan ukuran windows IDE adalah sesuatu yang tidak Anda inginkan dalam kontrol sumber.

Tetapi beberapa file proyek IDE adalah metadata proyek vital. Saya tidak mengenal Netbeans dengan baik, tetapi untuk eclipse, file .project memberitahu IDE apa nama proyek itu, bahwa itu adalah proyek web Java, dll. Dan file .classpath berisi informasi tentang folder sumber dan perpustakaan. Beberapa file dalam direktori .settings dapat sama pentingnya, misalnya org.eclipse.core.resources.prefs berisi informasi tentang pengkodean apa yang harus digunakan untuk file mana.

Sebagai metadata proyek, hal ini sangat layak untuk diversi dalam kontrol sumber.

Beberapa IDE dapat mengimpor metadata proyek dari IDE lain. Akan lebih baik untuk memilikinya dalam bentuk yang tidak terikat pada IDE tertentu.

Untuk Jawa, ada yang namanya: Maven . Itu memaksakan konvensi yang kuat pada struktur proyek dan memungkinkan Anda untuk menentukan metadata proyek (seperti dependensi perpustakaan) di satu titik (file bernama pom.xml yang ada di direktori utama proyek dan, tentu saja, dalam kontrol sumber). Ada plugin yang kemudian membuat file proyek IDE dari konfigurasi Maven, dan lainnya yang dapat mengotomatiskan proses pembangunan proyek, atau melakukan apa saja. Terkadang rasanya seperti membuat hal-hal yang tidak perlu menjadi rumit dan butuh waktu untuk belajar, tetapi manfaatnya pada umumnya sepadan.

— Michael Borgwardt
sumber

1

jika saya tidak salah, Maven adalah IDE independen. Jika demikian, maka, karena ini berisi pengaturan proyek / metadata karena itu pasti harus dimasukkan dalam repo, tetapi bukan "file proyek IDE" yang tampaknya OP secara spesifik merujuk.

— Bleeding Fingers

@ hus787: maksud saya adalah metadata ini sangat penting untuk di repo, dan walaupun sangat bagus ketika Anda memilikinya dalam bentuk IDE-independen, ketika itu bukan masalahnya, masih lebih baik untuk memilikinya daripada tidak memilikinya.

— Michael Borgwardt

2

Ini sangat tergantung pada jenis informasi apa yang ingin Anda miliki di repositori. Jika Anda ingin semuanya sampai ke file mana yang telah Anda buka dan sedang mengedit pada saat komit, dan Anda satu-satunya yang menggunakan repositori, silakan dan komit semuanya, tetapi ketahuilah bahwa itu mungkin tidak bekerja di komputer lain .

Jika Anda ingin dapat membagikan kode Anda dengan orang lain yang mungkin tidak menggunakan IDE yang sama, maka cukup komit kode itu sendiri tanpa implementasi spesifik proyek.

Jika Anda tahu bahwa semua orang menggunakan IDE yang sama, maka Anda mungkin dapat memasukkan apa pun yang tidak spesifik komputer, yaitu pengaturan file / folder hanya untuk IDE itu sendiri, dengan cara itu mereka sudah dapat memiliki kemampuan untuk mengimpor proyek sebagai IDE mengharapkannya.

— Ampt
sumber

2

Artefak yang membantu pengembangan Anda dan tidak berguna untuk membangun / melepaskan atau proyek itu sendiri tidak boleh dimasukkan. Repo harus bersih dan rapi dan hanya memiliki hal-hal yang relevan dengan proyek, bukan lingkungan Anda . Repo harus mengetahui kebiasaan Anda. Dan kedua itu akan mengganggu Anda saat melakukan sesuatu yang mirip git status... tapi hei saya tidak pernah melakukan perubahan ... ahh abaikan itu.

Biarkan saya memberikan contoh yang lebih praktis (saya akan gunakan di gitsini sebagai alat):

Anda tidak akan pernah menginginkan submodul (rekursif) di dalam repo utama Anda untuk memiliki hal-hal spesifik IDE (mungkin juga mengganggu lingkungan proyek utama) karena semua yang Anda pedulikan adalah kode yang ditulis oleh orang lain (atau Anda) dan penggunaan di dalam proyek saat ini. Bukan lingkungan di mana ia dikembangkan. Anda mungkin juga tidak ingin melakukan itu pada orang lain.

Untuk dapat menggunakan pengaturan Anda pada mesin yang berbeda, saya sarankan menggali di dalam IDE Anda dan melihat apa dukungan yang diberikannya untuk hal-hal seperti itu. Emacs memiliki initdan server Emacs juga. Atau Anda dapat membuat makro atau skrip kustom ( .sh) yang melakukan pengaturan secara otomatis.

— Jari-jari yang berdarah
sumber

-1: tidak setuju sepenuhnya. Ini bisa menjadi informasi yang sangat penting dan berguna, dan repo Anda pasti harus memasukkan informasi tersebut.

— Michael Borgwardt

@MichaelBorgwardt bagaimana jika OP kemudian berencana untuk beralih ke beberapa IDE lainnya. Bagaimana pengaturan proyek IDE spesifik itu akan dipahami dalam yang lain? Contoh akan sangat dihargai.

— Bleeding Fingers

Beberapa IDE dapat mengimpor metadata proyek dari IDE lain. Sekalipun mereka tidak bisa, file-file ini biasanya terbaca oleh manusia dan memilikinya lebih baik daripada tidak memilikinya.

— Michael Borgwardt

Dan apa yang terjadi jika Anda benar-benar memperhalus ruang kerja Anda (terjadi pada saya baru-baru ini) dan tidak dapat membalikkan perubahan melalui pengaturan secara manual kembali seperti yang Anda pikirkan sebelumnya? Saya mungkin menghemat waktu berjam-jam karena ruang kerja sudah diperiksa. Belum lagi di beberapa IDE ruang kerja akan mencakup hal-hal seperti templat kode yang akan sangat menyebalkan harus diatur secara manual setiap kali.

— Amy Blankenship

@AmyBlankenship itu maksud saya ini adalah ruang kerja Anda, bagaimana Anda bisa yakin itu tidak mengganggu milik orang lain (mereka menarik dan tiba-tiba ruang kerja mereka digantikan oleh milik Anda), lebih baik menyimpannya di cabang lokal yang terpisah atau Anda dapat menggunakan mercurial untuk VC ruang kerja spesifik proyek pribadi Anda dan git untuk VC proyek. Tentang templat kode, saya pikir IDE Anda belum cukup matang (atau belum dieksplorasi dengan benar) dan jika Anda mengatakan templat tersebut spesifik untuk proyek, maka saya rasa Anda harus mencari pola dalam kode Anda.

— Bleeding Fingers

1

Jika ini adalah proyek pribadi, saya katakan menyimpan pengaturan dalam kontrol sumber. Secara pribadi, tidak ada yang membunuh motivasi saya lebih dari sebuah proyek daripada mendirikan lingkungan pengembangan lagi.

Ketika lebih banyak orang terlibat, saya tidak menempatkan hal-hal ini dalam kendali sumber. Di tim saya, kami memiliki campuran IntelliJ, Sublime Text, dan Eclipse yang digunakan. File IDE hanya menambahkan kekacauan, dan menghasilkan menarik komitmen ke file-file dari orang lain untuk IDE yang tidak Anda gunakan.

Selain itu, proyek Anda seharusnya tidak tergantung pada IDE. Server build tidak akan mem-boot Eclipse untuk mengkompilasi produk Anda, jadi itu seharusnya sudah bebas IDE. Poin yang lebih kecil: menghilangkan organisasi pribadi dalam proyek. Sebagai contoh, di IntelliJ saya suka menggunakan banyak modul dalam proyek kami. Tidak ada orang lain yang menggunakan IntelliJ khawatir tentang ini karena kami tidak menyimpan file .iml (modul).

Jika tim Anda menggunakan IDE yang sama maka itu lebih baik, tetapi kemudian seseorang melakukan entri .classpath yang buruk karena mereka menggunakan jalur absolut. Sekarang semua orang yang menggunakan IDE khawatir tentang hal itu.

Tentu, downside adalah bahwa ada lebih banyak pengaturan ketika seseorang memeriksa proyek. Saya pikir itu sepadan. Kami menggunakan Ivy untuk manajemen dependensi dan memiliki informasi tentang pengaturan, dependensi, dll. Meskipun ini biaya di muka, saya pikir itu layak untuk menjaga pengaturan IDE di luar kendali sumber.

— Kriptik
sumber