Отсоединить (переместить) подкаталог в отдельный репозиторий Git

у меня есть Git репозиторий, который содержит несколько подкаталогов. Теперь я обнаружил, что один из подкаталогов не связан с другим и должен быть отделен от отдельного репозитория.

Как я могу это сделать, сохраняя историю файлов в подкаталоге?

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

чтобы было понятно, у меня есть следующая структура:

XYZ/
    .git/
    XY1/
    ABC/
    XY2/

но я бы хотел, чтобы вместо этого:

XYZ/
    .git/
    XY1/
    XY2/
ABC/
    .git/
    ABC/

22 ответов


обновление: этот процесс настолько распространен, что команда git сделала его намного проще с помощью нового инструмента,git subtree. Смотрите здесь: отключить (перемещать) подкаталог в отдельный репозиторий Git


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

  1. клонировать локальный репозиторий:

    git clone /XYZ /ABC
    

    (Примечание: репозиторий будет клонироваться с использованием жестких ссылок, но это не проблема, так как жестко связанные файлы не будут изменены сами по себе-будут созданы новые.)

  2. теперь давайте сохраним интересные ветви, которые мы также хотим переписать, а затем удалим origin, чтобы избежать нажатия туда и убедиться, что старые коммиты не будут ссылаться на origin:

    cd /ABC
    for i in branch1 br2 br3; do git branch -t $i origin/$i; done
    git remote rm origin
    

    или для всех удаленных ветви:

    cd /ABC
    for i in $(git branch -r | sed "s/.*origin\///"); do git branch -t $i origin/$i; done
    git remote rm origin
    
  3. теперь вы можете также удалить теги, которые не имеют никакого отношения к подпроекту; вы также можете сделать это позже, но вам может потребоваться снова обрезать ваше РЕПО. Я этого не сделал и получил WARNING: Ref 'refs/tags/v0.1' is unchanged для всех тегов (поскольку все они не связаны с подпроектом); кроме того, после удаления таких тегов будет освобождено больше места. Видимо git filter-branch должен быть в состоянии переписать другие теги, но я не мог проверить это. Если вы хотите удалить все теги, использовать git tag -l | xargs git tag -d.

  4. затем используйте filter-branch и reset, чтобы исключить другие файлы, чтобы их можно было обрезать. Давайте также добавим --tag-name-filter cat --prune-empty чтобы удалить пустые коммиты и переписать теги (обратите внимание, что для этого придется лишить их подписи):

    git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter ABC -- --all
    

    или, альтернативно, переписать только головную ветвь и игнорировать теги и другие ветви:

    git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter ABC HEAD
    
  5. затем удалите резервные reflogs, чтобы пространство можно было действительно восстановить (хотя теперь операция разрушительна)

    git reset --hard
    git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
    git reflog expire --expire=now --all
    git gc --aggressive --prune=now
    

    и теперь у вас есть локальный репозиторий Git подкаталога ABC со всей его историей.

Примечание: Для большинства применений, git filter-branch должен действительно иметь добавленный параметр -- --all. Да это действительно --пробел-- all. Это должны быть последние параметры команды. Как обнаружил Матли, это сохраняет ветви и теги проекта, включенные в новое РЕПО.

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


Легкий Путь™

оказывается, это такая распространенная и полезная практика, что оверлорды git сделали ее очень простой, но у вас должна быть более новая версия git (>= 1.7.11 May 2012). Вижу приложение для того, как установить последнюю версию git. Кроме того, есть пример на прохождение ниже.

  1. подготовьте старое РЕПО

    pushd <big-repo>
    git subtree split -P <name-of-folder> -b <name-of-new-branch>
    popd
    

    Примечание: <name-of-folder> не должно содержать ведущие или конечные символы. Например, папка с именем subproject должно быть передано как subproject, а не ./subproject/

    Примечание для пользователей windows: когда ваша глубина папки > 1,<name-of-folder> должен иметь разделитель папок стиля *nix (/). Например, папка с именем path1\path2\subproject должно быть передано как path1/path2/subproject

  2. создать новый РЕПО

    mkdir <new-repo>
    pushd <new-repo>
    
    git init
    git pull </path/to/big-repo> <name-of-new-branch>
    
  3. связать новое РЕПО с Github или где

    git remote add origin <git@github.com:my-user/new-repo.git>
    git push origin -u master
    
  4. очистка при желании

    popd # get out of <new-repo>
    pushd <big-repo>
    
    git rm -rf <name-of-folder>
    

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

...

прохождение

это же шаги, как выше, но следуя моим точным шагам для моего репозитория вместо использования <meta-named-things>.

вот проект, который у меня есть для реализации модулей браузера JavaScript в узле:

tree ~/Code/node-browser-compat

node-browser-compat
├── ArrayBuffer
├── Audio
├── Blob
├── FormData
├── atob
├── btoa
├── location
└── navigator

я хочу разделить одну папку,btoa, в отдельный репозиторий git

pushd ~/Code/node-browser-compat/
git subtree split -P btoa -b btoa-only
popd

у меня теперь новая ветка,btoa-only, который имеет только коммиты для btoa и я хочу создать новый репозиторий.

mkdir ~/Code/btoa/
pushd ~/Code/btoa/
git init
git pull ~/Code/node-browser-compat btoa-only

далее я создаю новое РЕПО на Github или bitbucket, или что угодно, и добавьте это origin (кстати, "origin" - это просто соглашение, а не часть команды - вы можете назвать его "удаленным сервером" или как угодно)

git remote add origin git@github.com:node-browser-compat/btoa.git
git push origin -u master

счастливый день!

Примечание: если вы создали РЕПО с README.md, .gitignore и LICENSE, вам нужно будет сначала потянуть:

git pull origin -u master
git push origin -u master

наконец, я хочу удалить папку с большим РЕПО

git rm -rf btoa

...

приложение

последние git на OS X

чтобы получить последнюю версию git:

brew install git

чтобы получить варево для OS X:

http://brew.sh

последние git на Ubuntu

sudo apt-get update
sudo apt-get install git
git --version

если это не работает (у вас есть очень старая версия ubuntu), попробуйте

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git

если это все еще не работает, попробуй!--45-->

sudo chmod +x /usr/share/doc/git/contrib/subtree/git-subtree.sh
sudo ln -s \
/usr/share/doc/git/contrib/subtree/git-subtree.sh \
/usr/lib/git-core/git-subtree

благодаря rui.Араужо из комментариев.

очистка журнала

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

git filter-branch --prune-empty --tree-filter 'rm -rf <name-of-folder>' HEAD

после этого вы можете проверить, что ваш файл или папка больше не отображается в истории git на все!--45-->

git log -- <name-of-folder> # should show nothing
, вы не удается "нажать" удаление в github и тому подобное. Если вы попытаетесь, вы получите ошибку, и вам придется git pull перед git push - и затем вы возвращаетесь к тому, что все в вашей истории.

поэтому, если вы хотите удалить историю из "origin" - то есть удалить ее из github, bitbucket и т. д. - Вам нужно удалить РЕПО и повторно нажать обрезанную копию РЕПО. Но подождите ... --39-->больше! - Если вы действительно беспокоитесь о том, чтобы избавиться от пароля или чего-то подобного, вам нужно будет обрезать резервную копию (см. ниже).

делая .git меньше

вышеупомянутая команда delete history по - прежнему оставляет после себя кучу резервных файлов-потому что git слишком добр, помогая вам не испортить ваше РЕПО случайно. В конечном итоге он удалит осиротевшие файлы в течение нескольких дней и месяцев, но оставит их там на некоторое время, если вы понимаете, что вы случайно удалил то, что не хотел.

так что если вы действительно хотите очистить корзину to уменьшить размер клона РЕПО сразу же вы должны сделать все это действительно странные вещи:

rm -rf .git/refs/original/ && \
git reflog expire --all && \
git gc --aggressive --prune=now

git reflog expire --all --expire-unreachable=0
git repack -A -d
git prune

тем не менее, я бы рекомендовал не выполнять эти шаги, если вы не знаете, что вам нужно - просто на случай, если вы обрезали неправильный подкаталог, вы знаете? Резервные файлы не должны клонироваться, когда вы нажимаете РЕПО, они просто будут в ваша локальная копия.

кредит


Павла создает новый репозиторий, содержащий /ABC, но не удаляет /ABC из /XYZ. Следующая команда удалит /ABC из /XYZ:

git filter-branch --tree-filter "rm -rf ABC" --prune-empty HEAD

конечно, сначала протестируйте его в репозитории "clone --no-hardlinks" и следуйте за ним с помощью команд reset, gc и prune.


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

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

    git clone --no-hardlinks foo bar; cd bar
    git filter-branch --subdirectory-filter subdir/you/want
    
  2. удалить все ссылки на старую историю. "origin" отслеживал ваш клон, а "original" -это то, где filter-branch сохраняет старый материал:

    git remote rm origin
    git update-ref -d refs/original/refs/heads/master
    git reflog expire --expire=now --all
    
  3. даже сейчас, ваша история может застрять в packfile, который fsck не трогает. Разорвите его в клочья, создав новый packfile и удалив неиспользуемые объекты:

    git repack -ad
    

здесь объяснение на инструкция для фильтра-филиала.


Edit: добавлен скрипт 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 MB. Может, это кому-то помогает :)


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

!/bin/bash

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


clone=/tmp/Clone
newN=/tmp/

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

git filter-branch --subdirectory-filter   --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 команда на клоне вас repo для отбраковки подкаталогов, которые вы не хотите,а затем нажмите на новый пульт.

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

обновление: модуль git-subtree был настолько полезен, что команда git вытащила его в ядро и сделала его git subtree. Смотрите здесь: отключить (перемещать) подкаталог в отдельный репозиторий Git

git-поддерево может быть полезно для этого

http://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt (устарело)

http://psionides.jogger.pl/2010/02/04/sharing-code-between-projects-with-git-subtree/


вот небольшая модификация CoolAJ86 ' s "легкий путь™" ответ для того, чтобы разделить несколько подпапок (скажем sub1и sub2) в новый репозиторий Git.

The Easy Way™ (несколько подпапок)

  1. подготовьте старое РЕПО

    pushd <big-repo>
    git filter-branch --tree-filter "mkdir <name-of-folder>; mv <sub1> <sub2> <name-of-folder>/" HEAD
    git subtree split -P <name-of-folder> -b <name-of-new-branch>
    popd
    

    Примечание: <name-of-folder> не должно содержать ведущие или конечные символы. Например, папка с именем subproject Должно быть передано как subproject, а не ./subproject/

    Примечание для пользователей windows: когда глубина вашей папки > 1,<name-of-folder> должен иметь разделитель папок * Nix style (/). Например, папка с именем path1\path2\subproject должно быть передано как path1/path2/subproject. Более того, не используйте но move.

    Конечная нота: уникальной и большой разницей с базовым ответом является вторая строка скрипта"git filter-branch..."

  2. создать новое РЕПО

    mkdir <new-repo>
    pushd <new-repo>
    
    git init
    git pull </path/to/big-repo> <name-of-new-branch>
    
  3. свяжите новое РЕПО с Github или где угодно

    git remote add origin <git@github.com:my-user/new-repo.git>
    git push origin -u master
    
  4. очистка при желании

    popd # get out of <new-repo>
    pushd <big-repo>
    
    git rm -rf <name-of-folder>
    

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


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

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

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

I lost contiuity after filter-branch

мой ответ на вопрос заключается в том, чтобы сделать 2 копии репозитория и вручную удалить папки, которые вы хотите сохранить в каждом. Человек-страница поддерживает меня с этим:

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


добавить Павла, я обнаружил, что в конечном итоге восстановить пространство, я должен нажать голову в чистый репозиторий и что урезает размер .каталог git/objects / pack.

то есть

$ mkdir ...ABC.git
$ cd ...ABC.git
$ git init --bare

после чернослива gc, также сделайте:

$ git push ...ABC.git HEAD

затем вы можете сделать

$ git clone ...ABC.git

и размер ABC/.Git-это уменьшенная

на самом деле, некоторые из трудоемких шагов (например, git gc) не нужны для очистки репозиторий, т. е.:

$ git clone --no-hardlinks /XYZ /ABC
$ git filter-branch --subdirectory-filter ABC HEAD
$ git reset --hard
$ git push ...ABC.git HEAD

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

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

GitHub теперь даже есть небольшой статье о таких случаях.

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

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

  1. клонировать репозиторий в другой каталог
  2. используя git filter-branch осталось только файлы под некоторым подкаталогом, нажмите на new remote
  3. create commit для удаления этого подкаталога из исходного удаленного РЕПО

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

 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. теперь только каталогом целевой модуль остается
  9. избавиться от подкаталоге модуль так, чтобы корневая модуль становится новым корнем проекта
  10. git mv moduleSubdir1/* .
  11. удалить реликвия каталогом: 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

таким образом на гитхабе doc "разделение подпапки на новый репозиторий" шаги 6-11, чтобы переместить модуль на новое РЕПО.

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


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

Он имеет сказочное имя git_filter и живет здесь:

https://github.com/slobobaby/git_filter

на GitHub.

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


для чего это стоит, вот как использовать GitHub на машине Windows. Предположим, у вас есть клонированное РЕПО в проживании в C:\dir1. Структура каталогов выглядит следующим образом:C:\dir1\dir2\dir3. The dir3 каталог-это тот, который я хочу быть новым отдельным РЕПО.

Github:

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

Bash Подсказка:

  1. $ cd c:/Dir1
  2. $ git filter-branch --prune-empty --subdirectory-filter dir2/dir3 HEAD
    Вернулся:Ref 'refs/heads/master' was rewritten (fyi: dir2/dir3 чувствителен к регистру.)

  3. $ git remote add some_name git@github.com:MyTeam/mynewrepo.git
    git remote add origin etc. не получилось, вернулся "remote origin already exists"

  4. $ git push --progress some_name master


Как Я упомянутые выше, мне пришлось использовать обратное решение (удаление всех коммитов, не касаясь моего dir/subdir/targetdir), который, казалось, работал довольно хорошо, удаляя около 95% коммитов (по желанию). Однако остаются еще два небольших вопроса.

первый, filter-branch сделал взрывную работу по удалению коммитов, которые вводят или изменяют код, но, по-видимому,коммитов слияния находятся под его станцией в Gitiverse.

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

второй на несколько коммитов, которые остаются в значительной степени все дублируются! Кажется, я приобрел вторую, избыточную временную шкалу, которая охватывает почти всю историю проекта. Интересная вещь (которая вы можете видеть на рисунке ниже), является то, что мои три локальные ветви не все на одной временной шкале (что, конечно, почему он существует и не просто мусор собирается).

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

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


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

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


вам может понадобиться что-то вроде "Git reflog expire --expire=now --all" перед сборкой мусора, чтобы фактически очистить файлы. фильтр-ветку в Git просто удаляет ссылки в истории, но не устраняет reflog записи, которые содержат данные. Конечно, сначала проверьте это.

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


Проверьте проект 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.

поместите это в свой 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'

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


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

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


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

  1. открыть ГИТ Баш.

  2. измените текущий рабочий каталог на место, где вы хотите создать свой новый репозиторий.

  3. клонировать репозиторий, содержащий подпапку.

git clone OLD-REPOSITORY-FOLDER NEW-REPOSITORY-FOLDER
  1. измените текущий рабочий каталог на клонированный репозиторий.

cd REPOSITORY-NAME
  1. отфильтровать подпапку от остальной части файлы в репозитории, run 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