Ігнорувати .classpath та .project з Git


77

Я продовжую говорити собі та іншим, щоб не створювали файли .classpath та .project і не використовували Maven.

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

Тепер із myside я хотів би щось спробувати / зробити. Коли я клоную репо, я отримую файли .classpath та .project, і, звичайно, вони змінюються в моїй системі.

Але я хочу, щоб вони не були зафіксовані і їх слід завжди ігнорувати під час синхронізації з Git. Щоб мої зміни в локальній системі не зіпсувалися з Git, а зміни Git цих файлів не зіпсували мої локальні файли.

Як мені цього досягти? У будь-якому випадку позначити ці файли таким чином, щоб їх ігнорували?


Я є повноцінним Java n00b, але згідно з документацією Eclipse ці файли слід зберігати в контролі версій. wiki.eclipse.org/…
Даніель Шиллінг,

Відповіді:


119

Якщо .projectі .classpathвже скоєно, їх потрібно видалити з індексу (але не диска)

git rm --cached .project
git rm --cached .classpath

Тоді .gitignoreфайл буде працювати (і цей файл можна додати та поділитися через клони).
Наприклад, цей gitignore.io/api/eclipseфайл тоді працюватиме, що включає:

# Eclipse Core      
.project

# JDT-specific (Eclipse Java Development Tools)     
.classpath

Зверніть увагу, що під час клонування ви можете використовувати « Каталог шаблонів » (переконайтеся, що у ваших користувачів змінна середовища $GIT_TEMPLATE_DIRвстановлена ​​у спільну папку, доступну всім).
Ця папка шаблону може містити info/excludeфайл із правилами ігнорування, які потрібно застосувати для всіх репозиторіїв, включаючи нові ( git init), які використовував би будь-який користувач.


Як відзначили по Абдолла

Коли ви змінюєте індекс, вам потрібно зафіксувати зміну та натиснути її.
Потім файл видаляється зі сховища. Тож новачки не можуть перевірити файли .classpathта .projectз репо.


Коли ви змінюєте індекс, вам потрібно зафіксувати зміну та натиснути її. Потім файл видаляється зі сховища. Тож новачки не можуть перевірити файли .classpath та .project з репо.
Абдолла

1
@Abdollah Гарна думка. Я включив ваш коментар у відповідь для більшої наочності.
VonC

@Abdollah Чому? Після того, як видалення буде здійснено та натиснуто (як і .gitignore), ви не зможете легко додати назад ці файли.
VonC

Організація замовлення хоче, щоб .classpath та .project все ще залишались у репо. Можливо, використання SKIP-WORKTREE для такого сценарію є кращим варіантом. Я пояснив це тут . @VonC На жаль, я видалив свій попередній коментар, сказавши "в git немає рішення для такого сценарію" через кілька хвилин після його написання, і я не побачив вашої відповіді при його видаленні.
Абдолла

11

Додайте наведені нижче рядки в .gitignore і розмістіть файл у папці ur project

/target/
/.classpath
/*.project
/.settings
/*.springBeans

Будь ласка, поясніть, що ви робили, редагуючи свою відповідь, уникайте лише коду aswer
GGO 02.03.18

1
Я не бачив, щоб хтось відповідав на це запитання, вони просто дали посилання для посилання.
Viyaan Jhiingade 03.03.18

2
Я думаю, що ця відповідь надзвичайно солідна. Я знав усі концепції, але просто хотів, щоб точний код був поміщений у файл .gitignore. Дякую @ViyaanJhiingade І ласкаво просимо до StackOverflow.
Saurabh Patil

5

Рішенням git для таких сценаріїв є встановлення SKIP-WORKTREE BIT . Виконайте лише таку команду:

git update-index --skip-worktree .classpath .gitignore

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

Запуск git rm --cachedне працює для сценарію, згаданого у питанні. Якщо я спрощу запитання, там сказано:

Як мати .classpathі .projectна репо, тоді як кожен може змінити його локально, а git ігнорує цю зміну?

Як я прокоментував під прийнятою відповіддю, недоліком git rm --cachedє те, що це спричиняє зміну індексу, тому вам потрібно зафіксувати зміну, а потім перенести її у віддалене сховище. В результаті .classpathі.project НЕ буде доступний на репо , а PO хоче , щоб вони там так , що хто - клони Репо в перший раз, вони можуть використовувати його.

Що таке SKIP-WORKTREE BIT?

На основі документації git:

Біт skip-worktree можна визначити одним (довгим) реченням: При читанні запису, якщо вона позначена як skip-worktree, тоді Git робить вигляд, що її версія робочого каталогу актуальна, і замість неї читає версію індексу. Незважаючи на те, що цей біт схожий на припустимо незмінний біт , його мета відрізняється від припустимо незмінного біта. Skip-worktree також має перевагу над припустимо незмінним бітом, коли встановлено обидва.

Детальніше тут .


1
На самом деле, я вже писав про це тут: stackoverflow.com/a/23806990/6309
VonC

Чудове порівняння.
Абдолла

2
Це має бути новою прийнятою відповіддю, оскільки це єдиний спосіб зберегти файли, записані в git, і ігнорувати їх для нових комітів.
IVleafclover

1

Використовуйте файл .gitignore. Це дозволяє ігнорувати певні файли. http://git-scm.com/docs/gitignore

Ось приклад Eclipse, який обробляє шлях до вашого класу та файли проекту: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore


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

2
Вам потрібно подати свої дані .gitignoreв репо, щоб усі користувались ними. Таким чином, ніхто не повинен подавати ці файли. .classpath та .project ніколи не повинні бути в репо.
олан

1
а як щодо існуючих файлів / репо, що містить ці файли?
Редді

1
Ви можете швидко підтвердити мої сумніви щодо .ignore. ^ Над коментарем
Редді

1
Я не бачу ні файлу .classpath, ні .project у цьому файлі? Мені чогось не вистачає? (Мої файли .project не зникнуть, хоча у мене є рядок для цього у моєму gitignore)
Matthew Wise
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.