Похоже, что большинство (все?) ответов здесь опираются на некоторую форму git filter-branch --subdirectory-filter и ее ilk. Это может работать «в большинстве случаев», однако для некоторых случаев, например, когда вы переименовали папку, например:

 ABC/
    /move_this_dir # did some work here, then renamed it to

ABC/
    /move_this_dir_renamed

Если вы используете обычный стиль git-фильтра для извлечения «move_me_renamed», вы будете потерять историю изменений файла, которая произошла со спины, когда она была первоначально move_this_dir ( ref ).

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

1. Локализовать проект с несколькими модулями локально
2. Ветви - проверить, что там есть: git branch -a
3. Выполните проверку каждой ветви, которая будет включена в разделение для получения локальной копии на вашей рабочей станции: git checkout --track origin/branchABC
4. Сделайте копию в новом каталоге: cp -r oldmultimod simple
5. Перейдите в новую копию проекта: cd simple
6. Избавьтесь от других модулей, которые не нужны в этом проекте:
7. git rm otherModule1 other2 other3
8. Теперь только subdir целевого модуля остается
9. Избавиться от модуля subdir модуля, чтобы корень модуля стал новым корнем проекта
10. git mv moduleSubdir1/* .
11. Удалить реликвий subdir : rmdir moduleSubdir1
12. Проверьте изменения в любой точке: git status
13. Создайте новый репозиторий git и скопируйте его URL, чтобы указать на него этот проект:
14. git remote set-url origin http://mygithost:8080/git/our-splitted-module-repo
15. Убедитесь, что это хорошо: git remote -v
16. Нажмите изменения до удаленного репо: git push
17. Перейдите к удаленному репо и проверьте его там
18. Повторите его для любой другой ветки: git checkout branch2

Это следует за github doc «Разделение вложенной папки в новый репозиторий « шаги 6-11, чтобы подтолкнуть модуль к новому репо.

Это не сохранит ваше место в вашей папке .git, но оно сохранит всю историю изменений для этих файлов даже переименования. И это может не стоить того, если нет «большой» истории, потерянной и т. Д. Но по крайней мере вам гарантировано не потерять более старые коммиты!

Используйте эту команду фильтра, чтобы удалить подкаталог, сохраняя ваши теги и ветви:

git filter-branch --index-filter \
"git rm -r -f --cached --ignore-unmatch DIR" --prune-empty \
--tag-name-filter cat -- --all

Простой способ

1. установить git splits . Я создал его как расширение git, основанное на решении jkeating .
2. Разделите каталоги на локальную ветвь #change into your repo's directory cd /path/to/repo #checkout the branch git checkout XYZ
#split multiple directories into new branch XYZ git splits -b XYZ XY1 XY2
3. Создайте пустой репо где-нибудь. Предположим, мы создали пустое репо под названием xyz на GitHub, у которого есть путь: git@github.com:simpliwp/xyz.git
4. Нажмите на новое репо. #add a new remote origin for the empty repo so we can push to the empty repo on GitHub git remote add origin_xyz git@github.com:simpliwp/xyz.git #push the branch to the empty repo's master branch git push origin_xyz XYZ:master
5. Клонирование вновь созданного удаленного репо в новый локальный каталог #change current directory out of the old repo cd /path/to/where/you/want/the/new/local/repo #clone the remote repo you just pushed to git clone git@github.com:simpliwp/xyz.git

Поместите это в свой gitconfig:

reduce-to-subfolder = !sh -c 'git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter cookbooks/unicorn HEAD && git reset --hard && git for-each-ref refs/original/ | cut -f 2 | xargs -n 1 git update-ref -d && git reflog expire --expire=now --all && git gc --aggressive --prune=now && git remote rm origin'

Для чего это стоит, вот как использовать GitHub на машине Windows. Допустим, у вас есть клонированное репо, проживающее в C:\dir1. Структура каталогов выглядит так: C:\dir1\dir2\dir3. Каталог dir3 является тем, кем я хочу стать новым отдельным репо.

Github:

1. Создайте новый репозиторий: MyTeam/mynewrepo

Bash Prompt:

2. $ cd c:/Dir1
3. $ git filter-branch --prune-empty --subdirectory-filter dir2/dir3 HEAD Возврат: Ref 'refs/heads/master' was rewritten (fyi: dir2 / dir3 чувствителен к регистру.)
4. $ git remote add some_name git@github.com:MyTeam/mynewrepo.git git remote add origin etc. не работает, возвращается "remote origin already exists"
5. $ git push --progress some_name master

Это уже не так сложно, вы можете просто использовать команду git filter-branch на клоне вашего репо, чтобы отбросить подкаталоги, которые вам не нужны, а затем нажать на новый пульт.

git filter-branch --prune-empty --subdirectory-filter <YOUR_SUBDIR_TO_KEEP> master
git push <MY_NEW_REMOTE_URL> -f .

Я обнаружил, что для правильного удаления старой истории из нового репозитория вам нужно сделать немного больше работы после шага filter-branch.

1. Сделайте клон и фильтр:

   git clone --no-hardlinks foo bar; cd bar
   git filter-branch --subdirectory-filter subdir/you/want
   

2. Удалите все ссылки на старую историю. «Происхождение» отслеживало ваш клон, а «оригинал» - это то, где фильтр-ветвь сохраняет старые вещи:

   git remote rm origin
   git update-ref -d refs/original/refs/heads/master
   git reflog expire --expire=now --all
   

3. Даже сейчас ваша история может застрять в пакете, который fsck не будет трогают. Раздирайте его в клочья, создайте новый пакетный файл и удалите неиспользуемые объекты:

   git repack -ad
   

Существует объяснение этого в руководстве для фильтра ветвп .

Оригинальный вопрос хочет, чтобы XYZ / ABC / (* файлы) стали ABC / ABC / (* файлами). После выполнения принятого ответа для моего собственного кода я заметил, что он фактически изменяет XYZ / ABC / (* файлы) в ABC / (* файлы). Страница man filter-branch даже говорит:

Результат будет содержать этот каталог (и только это) в качестве его корня проекта . "

Другими словами, он продвигает папку верхнего уровня «вверх» на один уровень. Это важное различие, потому что, например, в моей истории я переименовал папку верхнего уровня. Продвигая папки «вверх» на один уровень , git теряет непрерывность в commit, где я сделал переименование.

[/g1]

Тогда мой ответ на вопрос состоит в том, чтобы сделать 2 копии репозитория и вручную удалите папку (ы), которую вы хотите сохранить в каждой странице. man-страница поддерживает меня следующим образом:

[...] избегать использования [этой команды], если достаточно простого синтаксиса для исправления вашей проблемы

Правильный способ теперь следующий:

git filter-branch --prune-empty --subdirectory-filter FOLDER_NAME [first_branch] [another_branch]

GitHub теперь даже имеет малую статью о таких случаях.

Но обязательно клонируйте свое первоначальное репо, чтобы сначала отделить каталог (так как он удалит все файлы и другие каталоги, и вам, вероятно, придется работать с ними). ​​

Итак, ваш алгоритм должен быть:

1. клонирует ваше удаленное репо в другой каталог
2. , используя git filter-branch только файлы слева под некоторым подкаталогом, нажмите на новый пульт
3. create commit, чтобы удалить этот подкаталог из ваше оригинальное дистанционное репо

Изменить: добавлен скрипт Bash.

Ответы, приведенные здесь, работали частично для меня; В кеше осталось много больших файлов. Что в конечном итоге сработало (после часа в #git на freenode):

git clone --no-hardlinks file:///SOURCE /tmp/blubb
cd blubb
git filter-branch --subdirectory-filter ./PATH_TO_EXTRACT  --prune-empty --tag-name-filter cat -- --all
git clone file:///tmp/blubb/ /tmp/blooh
cd /tmp/blooh
git reflog expire --expire=now --all
git repack -ad
git gc --prune=now

С предыдущими решениями размер хранилища составлял около 100 МБ. Это снизило его до 1,7 МБ. Возможно, это помогает кому-то:)

Следующий скрипт bash автоматизирует задачу:

!/bin/bash

if (( $# < 3 ))
then
    echo "Usage:   $0 </path/to/repo/> <directory/to/extract/> <newName>"
    echo
    echo "Example: $0 /Projects/42.git first/answer/ firstAnswer"
    exit 1
fi


clone=/tmp/${3}Clone
newN=/tmp/${3}

git clone --no-hardlinks file://$1 ${clone}
cd ${clone}

git filter-branch --subdirectory-filter $2  --prune-empty --tag-name-filter cat -- --all

git clone file://${clone} ${newN}
cd ${newN}

git reflog expire --expire=now --all
git repack -ad
git gc --prune=now

У меня была именно эта проблема, но все стандартные решения, основанные на git filter-branch, были очень медленными. Если у вас есть небольшой репозиторий, это может быть не проблема, это было для меня. Я написал еще одну программу фильтрации git на основе libgit2, которая в качестве первого шага создает ветви для каждой фильтрации первичного репозитория, а затем выталкивает их для очистки репозиториев в качестве следующего шага. В моем хранилище (500 Мб 100000 коммитов) стандартные методы фильтрации фильтров git занимали дни. Моя программа занимает несколько минут, чтобы выполнить ту же фильтрацию.

У этого сказочного имени git_filter и живет здесь:

https://github.com/slobobaby/git_filter

на GitHub.

Надеюсь, это кому-то полезно.

Я рекомендую руководство GitHub по разделению подпапок в новый репозиторий . Шаги похожи на ответ Paul , но я понял, что их инструкции легче понять.

Я изменил инструкции, чтобы они применились к локальному репозиторию, а не к размещенному на нем GitHub.

Разделение вложенной папки в новый репозиторий

1. Открыть Git Bash.
2. Измените текущий рабочий каталог в том месте, где вы хотите создать новый репозиторий.
3. Клонирование репозитория, содержащего подпапку.

git clone OLD-REPOSITORY-FOLDER NEW-REPOSITORY-FOLDER

4. Измените текущий рабочий каталог на ваш клонированный репозиторий.

cd REPOSITORY-NAME

5. Чтобы отфильтровать подпапку от остальной части файлы в репозитории, запустите git filter-branch, предоставив эту информацию: FOLDER-NAME: папка внутри вашего проекта, из которой вы хотите создать отдельный репозиторий. Совет. Пользователи Windows должны использовать / для разграничения папок. BRANCH-NAME: ветвь по умолчанию для вашего текущего проекта, например, master или gh-pages.

git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME  BRANCH-NAME 
# Filter the specified branch in your directory and remove empty commits
Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89)
Ref 'refs/heads/BRANCH-NAME' was rewritten

Я уверен, что поддерева git прекрасна и прекрасна, но мои подкаталоги git-кода, которые я хотел переместить, были в затмении. Поэтому, если вы используете egit, это очень легко. Возьмите проект, который хотите переместить, и team-> отключите его, а затем team-> поделитесь им с новым местоположением. Он по умолчанию пытается использовать старое местоположение репо, но вы можете снять флажок существующего выбора и выбрать новое место для его перемещения. Все приветствуют.

Вам может понадобиться что-то вроде «git reflog expire --expire = now -all» перед сборкой мусора, чтобы фактически очистить файлы. git filter-branch просто удаляет ссылки в истории, но не удаляет записи reflog, которые хранят данные. Конечно, сначала проверьте это.

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

Проверьте проект git_split в https://github.com/vangorra/git_split

Поверните каталоги git в свои собственные репозитории в своем собственном месте. Нет поддерева смешного дела. Этот скрипт возьмет существующий каталог в вашем репозитории git и превратит этот каталог в самостоятельный собственный репозиторий. По пути он скопирует всю историю изменений для предоставленного вами каталога.

./git_split.sh <src_repo> <src_branch> <relative_dir_path> <dest_repo>
        src_repo  - The source repo to pull from.
        src_branch - The branch of the source repo to pull from. (usually master)
        relative_dir_path   - Relative path of the directory in the source repo to split.
        dest_repo - The repo to push to.