Вопрос по eclipse, git, egit – Лучше ли хранить Git-репозиторий внутри или вне рабочей области Eclipse?

38

Я типичный пользователь Eclipse / Subversion, начинающий переход на Git. Я исследовал основные концепции git и решил изначально придерживаться одного проекта для каждого хранилища, чтобы все было просто. У меня все еще проблемы, когда я решаю, где разместить репозиторий для каждого проекта.

Я потратил много времени на просмотр ответов наэтот вопросХотя я полагаю, что автор этого вопроса предполагал, что вы можете использовать Eclipse только для управления хранилищем, если хранилище находится в рабочей области Eclipse, что, конечно, неверно.

Что больше всего меня поразило в этом вопросе, так это тот факт, что все ответы, кроме одного (включая принятый ответ), предлагали сохранить хранилище в рабочем пространстве Eclipse, тогда как только один ответ указывал на то, чтоРуководство пользователя EGit рекомендует с точностью до наоборот.

Однако на практике может показаться, что Eclipse / EGit реализует ряд подходов, некоторые из которых, по-видимому, противоречат рекомендациям EGit.

Например, если вы используете мастер нового проекта для создания нового проекта PHP из Git, а хранилище удаленно, Eclipse / EGit с удовольствием создаст папку проекта в рабочей области Eclipse и поместит хранилище (.git) в папку проекта. Это конечный результат, который я на самом деле хочу, так как он сохраняет все инкапсулированным в рабочей области Eclipse.

Однако если вы используете Мастер создания нового проекта и выбираете локальный репозиторий Git, Eclipse / EGit не клонирует этот репозиторий, как это делается для удаленных репозиториев. Вместо этого он использует рабочую копию этого хранилища в качестве местоположения проекта, создает его .project и другие метаданные в этом месте, а также создает новую (на первый взгляд ненужную) папку в этой рабочей копии с тем же именем, что и ваш проект (так что вы заканчиваете например,~/git/blah/blah). Если вы удалите эту лишнюю папку, вы получите структуру, идентичную первому примеру, с той лишь разницей, что папка проекта не является подпапкой вашей папки рабочего пространства Eclipse, она находится где-то еще в вашей файловой системе (например, ,~/git/blah). Единственный положительный момент, который, похоже, имеет этот подход, заключается в том, что он придерживается рекомендаций, изложенных в Руководстве пользователя EGit, но с технической точки зрения трудно понять, насколько он действительно отличается от первого примера.

Учитывая эти удивительные наблюдения, мне интересно, какой опыт люди испытали, используя каждый из этих подходов, и какие могут быть подводные камни, если игнорировать рекомендации в Руководстве пользователя EGit.

@JamesG Какой подход вы используете, чтобы отразить изменения в рабочей области в вашем каталоге git? Есть ли лучшая альтернатива копированию с вставкой исходного кода? Sudip Bhandari
Я больше не использую Eclipse - я использую PHPStorm - поэтому я просто клонирую в папку проекта и затем начинаю там работать. Я не думаю, что PHPStorm даже предоставляет возможность сохранить репозиторий в другой папке проекта. Честно говоря, основываясь на том, что я слышал и читал после публикации этого вопроса четыре года назад, я не думаю, что многие люди будут хранить свои репозитории вне папок своих проектов. JamesG
возможный дубликатShould I store git repository in Home or Eclipse Workspace? mallardz

Ваш Ответ

3   ответа
3

что и оригинальный постер, и нашел другую ветку, где высказываются те же сомнения по рекомендации Egit:Должен ли я хранить git-репозиторий в Home или Eclipse Workspace?

@JamesG Так это ваш макет?

~/projectA/workspace/.metadata
~/projectA/workspace/subproj1/.project
~/projectA/workspace/subproj2/.project
~/projectA/subproj1/.git
~/projectA/subproj1/file1
~/projectA/subproj2/.git
~/projectA/subproj1/file2
Спасибо за ссылку на этот пост. Он сделал большое различие между несколькими проектами в одном git-репозитории и одним проектом на репозиторий. Если говорить о первом, то я согласен с тем, что помещать репо в рабочую область не имеет смысла, потому что тогда каталог .git находится на том же уровне, что и проекты, что просто кажется мне неправильным. В моем случае я могу позволить себе роскошь определить структуру репо, поэтому я выбрал одно репо на проект, поэтому каждый проект Eclipse является клоном репо. Этот подход работал хорошо для меня, даже для более крупных проектов (например, ZF2). JamesG
5

Я в порядке в случае большого проекта, который генерирует много файлов в папке .metadata. Даже если довольно просто поместить строку .metadata в .gitignore, чтобы улучшить производительность.

Но в моем случае (разработка Android) у меня есть около 35 разных проектов, содержащих только 50 файлов.

Все эти проекты находятся в разных пространствах, содержащих проект приложения и проекты библиотек для этого приложения. (Один репозиторий с подмодулями на приложение)

Must I only have one workspace with all my projects inside (spending time to scroll/close/open projects in the package explorer) ?

Must I manage 2 different base folders (Projects and Worskspaces) with the last one containing just the .metadatas folders of all my projects ?

Для меня это не имеет смысла.

Сообщение для команды EGit:

Почему меняется способ, которым разработчики обычно организуют свои папки проектов:

---- Worspace

---- Worspace / .metada

----- Worspace / .git

----- Worspace / Project1

----- Worspace / LibraryProject1

----- Worspace / LibraryProject2

Я понимаю причину производительности, но только для 5% разработчиков с очень большими проектами (генерирующими большие метаданные) вы просто не позволяете нам структурировать наши проекты, как Eclipse советует нам делать годами.

Не могли бы вы, даже если сообщение предупреждает нас о том, что это не рекомендуется, не блокируйте процесс клонирования в папке Worspace (& quot; C: \ Worspaces \ не является пустым каталогом & quot;)

EGit - отличный инструмент, но я действительно думаю об использовании Bash, потому что это
ограничение.

Спасибо за ваш ответ

PS: Есть много разных случаев разработки под Eclipse. Если это просто проблема производительности и если это не приводит к сбою EGit, пожалуйста, просто предупредите нас об этом, но не блокируйте нас в случае небольших проектов.

Согласен. Плагин EGit работает хорошо, но это большой архитектурный недостаток. Это нарушает мою автоматизацию рабочего пространства и, к сожалению, мешает мне перейти на использование git.
25

льзователя, которое вы связали. Я могу сказать вам, что часть

This can result in performance issues

к сожалению очень верно. Так что, если у вас есть каталог git с огромным количеством файлов в вашей рабочей области, многие операции git начнутся с & quot; подсчета объектов ... & quot; диалоговое окно, блокирующее вашу IDE, потому что оно сканирует все файлы в рабочей области. Для моих текущих 20000 файлов это означает ожидание от 10 до 20 секунд для каждого коммита, каждого переключателя, ...

В свободное время, где я, к счастью, могу использовать другую альтернативу (с рабочим каталогом git вне рабочей области), все выглядит намного быстрее, и объединять и переключать весело.

Так что, если вы работаете с большими проектами, рассмотрите каталог git вне рабочей области как первый выбор.

Я добавлю, что Eclipse и EGit сами настроили себя на использование своих репозиториев git за пределами своего рабочего пространства, и это работало нормально.
почему бы вам .metadata не в .gitignore?
@DanChase Просто клонируйте репозиторий, а затем используйте мастер импорта непосредственно из представления git-репозитория. Под капотом это создаст запись в метаданных рабочей области, но все файлы останутся в исходном месте. Вы можете проверить, открыв свойства для таких импортированных проектов и их файлов, они все еще находятся в репозитории git, а не в каталоге рабочей области.
@Bananeweizen Вы просто скопируете все в другой каталог, а затем скопируете его обратно в хранилище, прежде чем делать git add?
@Bananeweizen Вы упомянули, что вы экспериментировали с рабочим каталогом git вне рабочей области, и все было быстрее. Был ли один из тех экспериментов проведен с вашим большим (20 000 файлов) проектом или песочницей меньшего размера? То есть, можете ли вы однозначно сказать, что проект с 20000 файлов работал гораздо более гладко вне рабочей области? JamesG

Похожие вопросы