Що потрібно включити до мого сховища з проектів IDE

Я хочу додати проект, який у цьому випадку створений в Netbeans, але це питання є загальним для більшості IDE. Просто, що я повинен включити до свого сховища. Наприклад, Netbeans створює папку nbproject, eclipse створює папку .settings тощо. Якщо я повинен включити їх у свій сховище, які переваги / недоліки включають чи не включають конкретні параметри проекту.

У цьому випадку це особистий проект, тому я не уявляю, що інші люди почнуть працювати над ним, але було б непогано додати мінімальний мінімум налаштувань проекту, тому сам проект буде легко розпочати роботу на різних машинах.

Це дійсно залежить від того, які дані є, і їх слід вирішувати в кожному конкретному випадку, можливо, навіть для окремих файлів. Погляньте на вміст цих файлів. Найчастіше ви можете сказати, що вони означають. Такі речі, як розташування та розмір вікон IDE - це те, чого ви не бажаєте в керуванні джерелами.

Але деякі файли проектів IDE є життєво важливими метаданими проекту. Я не знаю добре Netbeans, але для затемнення файл .project повідомляє IDE, як називається проект, що це веб-проект Java тощо. Файл .classpath містить інформацію про папки джерела та бібліотеки. Деякі файли в каталозі .settings можуть бути однаково важливими, наприклад, org.eclipse.core.resources.prefs містить інформацію про те, яке кодування слід використовувати для яких файлів.

Як метадані проекту, цей матеріал дуже заслуговує на те, щоб бути використаним у контролі джерел.

Деякі IDE можуть імпортувати метадані проекту з інших IDE. Ще краще було б мати його у формі, не прив'язаній до конкретної IDE.

Для Java існує таке поняття: Maven . Це накладає чіткі умови на структуру проекту і дозволяє вказувати метадані проекту (наприклад, залежність від бібліотеки) в одній точці (файл під назвою pom.xml, який знаходиться в головному каталозі проекту і, звичайно, в керуванні джерелами). Існують плагіни, які потім створюють файли проектів IDE з конфігурації Maven та інші, які можуть автоматизувати процес збирання проекту або робити практично все, що завгодно. Іноді здається, що це робить речі не надто складними, і на це потрібно якийсь час, щоб навчитися, але переваги, як правило, того варті.

Це дійсно залежить від того, яку інформацію ви хотіли б мати у сховищі. Якщо ви хочете, щоб все було чітко до тих файлів, які ви відкрили та редагували під час здійснення фіксації, і ви єдиний, хто використовує сховище, продовжуйте виконувати все, але знайте, що він може не працювати на іншій машині .

Якщо ви хочете мати можливість ділитися своїм кодом з іншими людьми, які, можливо, не використовують той самий IDE, тоді просто скопіюйте сам код без будь-якої конкретної реалізації проекту.

Якщо ви знаєте, що всі використовують один і той же IDE, ви, ймовірно, можете включати все, що не є специфічним для комп'ютера, тобто будь-які налаштування файлів / папок лише для самого IDE, таким чином вони вже можуть мати можливість імпортувати проект як IDE очікує цього.

Артефакти, які допомагають вашому розвитку та не приносять користі для збирання / випуску чи самого проекту, не повинні включатись. РЕПО має бути чистим та охайним та мати лише ті речі, які стосуються проекту, а не вашого оточення . Репо має бути невідомим ваших звичок. А по-друге, це зайве клопоче вас, коли зробите щось подібне git status... але я ніколи не вносив жодних змін ... ах, ігноруйте це.

Дозвольте навести більш практичний приклад (я буду використовувати gitтут як інструмент):

Ви ніколи не хочете, щоб (рекурсивний) підмодуль у вашому головному репо містив специфічні для IDE речі (це також може впливати на основне середовище проекту), тому що все, що вам важливо, - це код, який написав хтось інший (або ви), і це використання всередині поточного проекту. Не середовище, в якому воно було розвинене. Напевно, ви теж не хочете цього робити комусь.

Щоб мати можливість використовувати ваші налаштування на різних машинах, я пропоную викопати всередині вашої IDE і подивитися, яку підтримку він надає для таких речей. У Emacs є initі сервер Emacs. Або ви можете зробити свій власний макрос або скрипт ( .sh), який здійснює налаштування автоматично.

Якщо це особистий проект, я кажу, що зберігайте налаштування у контролі джерел. Особисто ніщо не вбиває мою мотивацію до проекту, ніж знову створити середовище розвитку.

Коли задіяно більше людей, я не ставлю ці речі під контроль джерел. У моїй команді ми використовуємо суміш IntelliJ, Sublime Text та Eclipse. Файли IDE просто додають безладу, і це призводить до залучення файлів до цих файлів від інших людей для IDE, який ви не використовуєте.

Крім того, ваш проект все одно не повинен залежати від IDE. Сервер збірки не завантажуватиме Eclipse для компіляції вашого продукту, тому він уже повинен бути без IDE. Більш незначний момент: це виключає особисту організацію в рамках проекту. Наприклад, в IntelliJ мені подобається використовувати багато модулів в рамках нашого проекту. Ніхто більше, що використовує IntelliJ, не хвилюється з цього приводу, оскільки ми не зберігаємо .iml (модуль) файли.

Якщо ваша команда використовує той самий IDE, тоді це краще, але тоді хтось робить неправильний запис .classpath, оскільки він використовував абсолютний шлях. Тепер усі, хто використовує IDE, хвилюються з цього приводу.

Звичайно, недоліком є ​​те, що більше налаштувань, коли хтось перевіряє проект. Я думаю, це того варте. Ми використовуємо Ivy для управління залежностями та маємо інформацію про налаштування, залежності та ін. Незважаючи на це передня вартість, я думаю, що це варто, щоб утримати параметри IDE поза контролем джерела.