Преобразование CVS многопроектной иерархии деревьев в Git?

Question

Я использую CVS и у меня есть эта иерархия:

/ROOT 
    /JAVA 
     /JavaProject1 
     /JavaProject2 
     .project 
    /PHP 
     /PHPProject1 
     /PHPProject2 
     .project 

В Eclipse>CVS Repository Exploring, я могу видеть эту иерархию, и я могу Check Out только проект, который я хочу.

Также я могу проверить (импорт) JAVA и PHP папки (я создал их как проект Eclipse General для импорта) в Eclipse Package Explorer и может синхронизировать и совершать все вместе.

Когда я хочу использовать Git, он поддерживает только один проект.

Я не хочу плоскую иерархию (вблизи всех JAVA и PHP проекта вместе), я хочу использовать иерархию дерева, и я хочу проверить только проект, который я хочу, как с CVS.

Возможно ли использование моей иерархии CVS в Git или какой метод я должен использовать?

Answer 1

Я думаю, что вы смешиваете то, что хотите делать локально, с тем, как вы хотите , чтобы устроить вещи удаленно. Все команды git получают доступ только к локальному репозиторию . Команды «push» и «fetch» ​​имеют доступ к удаленному репозиторию , но фактически они эффективно запускают друг друга на удаленной машине , работающей с локальным репозиторием на этом компьютере. Таким образом, задачи , которые вы можете делать удаленно, очень ограничены. В частности, копирование «ветки» и ссылки «тег» и истории фиксации, на которые указывают эти ссылки.

Это означает, что для простого случая существует ТОЛЬКО локальный репозиторий, он существует в каталоге .git в рабочем каталоге.

Вы можете разместить рабочие каталоги с их каталогами .git, однако вы хотите на своем локальном компьютере. Аналогично, вы можете организовать удаленные репозитории любым способом, разрешенным службой удаленного хостинга. Макеты не должны совпадать. Если пульт - это ваш собственный Linux-сервер, вы можете сделать макет так же, как ваш локальный. Если пульт дистанционного управления (например) Github, вы более ограничены.

Вам необходимо создать резервную копию каталога .git для резервного копирования в репозитории; остальная часть рабочего каталога, вероятно, не имеет значения. Вы можете использовать git push для выполнения этой резервной копии, если вы никогда не используете «-force».

Git на самом деле не очень увлекается тем, что у вас есть несколько рабочих каталогов для одного хранилища. Однако, возможно, в простом случае у них будут иметь свою собственную копию репозитория, и вам нужно будет нажимать/вытаскивать обновления отдельно либо в «центральный» репозиторий , либо более «случайно». Ни один из этих репозиториев не должен быть физически «удаленный».

Git много предпочитает вам переключаться между ветвями в одном рабочем каталоге и использовать make install процессы процесса отправки.

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