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

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

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

   git clone /XYZ /ABC
   

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

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

   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
   

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

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

5. Затем удалите резервные журналы рефлогов, чтобы можно было по-настоящему освободить пространство (хотя теперь операция разрушительна).

   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. Да, это действительно - - space - - all. Это должен быть последний параметр команды. Как обнаружил Матли, при этом ветки и теги проекта остаются включенными в новое репо.

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

Легкий путь ™

Оказывается, это настолько распространенная и полезная практика, что повелители Git упростили ее, но у вас должна быть более новая версия Git (›= 1.7.11 мая 2012 г.). См. приложение, чтобы узнать, как установить последнюю версию Git. Кроме того, в пошаговом руководстве ниже есть реальный пример.

0. Подготовить старое репо

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

Примечание. <name-of-folder> НЕ должен содержать начальные или конечные символы. Например, папка с именем subproject ДОЛЖНА передаваться как subproject, НЕ ./subproject/.

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

1. Создать новое репо

    mkdir ~/<new-repo> && cd ~/<new-repo>
    git init
    git pull </path/to/big-repo> <name-of-new-branch>
   

2. Свяжите новое репо с GitHub или где-нибудь еще

    git remote add origin <[email protected]:user/new-repo.git>
    git push -u origin master
   

3. Очистка внутри <big-repo>, при желании

    git rm -rf <name-of-folder>
   

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

Прохождение

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

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

tree ~/node-browser-compat

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

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

cd ~/node-browser-compat/
git subtree split -P btoa -b btoa-only

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

mkdir ~/btoa/ && cd ~/btoa/
git init
git pull ~/node-browser-compat btoa-only

Затем я создаю новое репо на GitHub или Bitbucket или на каком-либо другом и добавляю его как origin

git remote add origin [email protected]:node-browser-compat/btoa.git
git push -u origin master

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

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

git pull origin master
git push origin master

Наконец, я хочу удалить папку из большего репо.

git rm -rf btoa

Приложение

Последний Git для macOS

Чтобы получить последнюю версию Git с помощью Homebrew:

brew install git

Последний 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

Если это все еще не работает, попробуйте

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.araujo из комментариев.

Очистка вашей истории

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

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

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

git log -- <name-of-folder> # should show nothing

Однако вы не можете отправлять удаление на GitHub и т.п. Если вы попытаетесь, вы получите сообщение об ошибке, и вам придется git pull, прежде чем вы сможете git push - и тогда вы снова получите все, что есть в вашей истории.

Поэтому, если вы хотите удалить историю из источника, то есть удалить ее из GitHub, Bitbucket и т. Д., Вам необходимо удалить репо и повторно отправить обрезанную копию репо. Но подождите - это еще не все! - если вы действительно беспокоитесь о том, чтобы избавиться от пароля или чего-то подобного, вам необходимо удалить резервную копию (см. ниже).

Делаем .git меньше

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

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

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

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

Кредит

• http://psionides.eu/2010/02/04/sharing-code-between-projects-with-git-subtree/
• Окончательно удалить каталог из git
• http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
• Как удалить ненужные капли из моего репозитория git

Ответ Павла создает новый репозиторий, содержащий / 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. Даже сейчас ваша история может застрять в пакете, который fsck не коснется. Разорвите его в клочья, создав новый pack-файл и удалив неиспользуемые объекты:

   git repack -ad
   

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

Изменить: добавлен сценарий 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 filter-branch --prune-empty --subdirectory-filter <YOUR_SUBDIR_TO_KEEP> master
git push <MY_NEW_REMOTE_URL> -f .

При запуске git filter-branch с использованием более новой версии git (2.22+ может быть?) Он говорит об использовании этого нового инструмента git -фильтр-репо. Этот инструмент, безусловно, упростил мне задачу.

Фильтрация с помощью filter-repo

Команды для создания репозитория XYZ из исходного вопроса:

# create local clone of original repo in directory XYZ
tmp $ git clone [email protected]:user/original.git XYZ

# switch to working in XYZ
tmp $ cd XYZ

# keep subdirectories XY1 and XY2 (dropping ABC)
XYZ $ git filter-repo --path XY1 --path XY2

# note: original remote origin was dropped
# (protecting against accidental pushes overwriting original repo data)

# XYZ $ ls -1
# XY1
# XY2

# XYZ $ git log --oneline
# last commit modifying ./XY1 or ./XY2
# first commit modifying ./XY1 or ./XY2

# point at new hosted, dedicated repo
XYZ $ git remote add origin [email protected]:user/XYZ.git

# push (and track) remote master
XYZ $ git push -u origin master

предположения: * удаленное репо XYZ было новым и пустым перед отправкой

Фильтрация и перемещение

В моем случае я также хотел переместить пару каталогов для более согласованной структуры. Сначала я выполнил эту простую команду filter-repo, а затем git mv dir-to-rename, но обнаружил, что могу получить немного «лучшую» историю, используя параметр --path-rename. Вместо того, чтобы видеть последний измененный 5 hours ago в перемещенных файлах в новом репо, я теперь вижу last year (в пользовательском интерфейсе GitHub), который соответствует измененному времени в исходном репо.

Вместо того...

git filter-repo --path XY1 --path XY2 --path inconsistent
git mv inconsistent XY3  # which updates last modification time

В конце концов я сбежал ...

git filter-repo --path XY1 --path XY2 --path inconsistent --path-rename inconsistent:XY3

• Я думал, что Сообщение в блоге Git Rev News хорошо объясняет причину создания еще одного инструмента фильтрации репо.
• Сначала я попробовал создать подкаталог, соответствующий имени целевого репозитория в исходном репозитории, и выполнить затем фильтрацию (с использованием git filter-repo --subdirectory-filter dir-matching-new-repo-name). Эта команда правильно преобразовала этот подкаталог в корень скопированного локального репо, но она также привела к истории только трех коммитов, которые потребовались для создания подкаталога. (Я не понимал, что --path можно указывать несколько раз; таким образом, устраняется необходимость в создании подкаталога в исходном репо.) Поскольку кто-то привязался к исходному репо к тому времени, когда я заметил, что мне не удалось продолжить истории, я просто использовал git reset commit-before-subdir-move --hard после команды clone и добавил --force к команде filter-repo, чтобы заставить ее работать с слегка измененным локальным клоном.

git clone ...
git reset HEAD~7 --hard      # roll back before mistake
git filter-repo ... --force  # tell filter-repo the alterations are expected

• Я был в тупике при установке, так как не знал о шаблоне расширения с git, но в конечном итоге я клонировал git- filter-repo и привязал его к $(git --exec-path):

ln -s ~/github/newren/git-filter-repo/git-filter-repo $(git --exec-path)

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

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

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 ответ" Простой способ ", чтобы разделить несколько подпапок (скажем, sub1 и sub2) в новый репозиторий git.

Простой способ (несколько подпапок)

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 (/). Например, папка с именем path1\path2\subproject ДОЛЖНА быть передана как path1/path2/subproject. Более того, используйте не mvcommand, а 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 <[email protected]: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 / (* файлы) превратились в ABC / ABC / (* файлы). После реализации принятого ответа для моего собственного кода я заметил, что он фактически изменяет XYZ / ABC / (* файлы) на ABC / (* файлы). На странице руководства filter-branch даже сказано:

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

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

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

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

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

i.e.

$ 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 оставил только файлы в каком-то подкаталоге, нажмите на новый удаленный
3. создать фиксацию, чтобы удалить этот подкаталог из исходного удаленного репо

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

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

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

1. Откройте Git Bash.

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

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

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

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

cd REPOSITORY-NAME

5. To filter out the subfolder from the rest of the files in the repository, run git filter-branch, supplying this information:
   • FOLDER-NAME: The folder within your project that you'd like to create a separate repository from.
     • Tip: Windows users should use / to delimit folders.
   • 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 filter-branch --subdirectory-filter и ему подобных. Однако это может сработать в большинстве случаев в некоторых случаях, например, когда вы переименовали папку, например:

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

ABC/
    /move_this_dir_renamed

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

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

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. Избавьтесь от подкаталога модуля, чтобы корень модуля стал корнем нового проекта.
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

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

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

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

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

https://github.com/slobobaby/git_filter

на GitHub.

Надеюсь, это кому-то пригодится.

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

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

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

Github:

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

Подсказка Bash:

2. $ cd c:/Dir1

3. $ git filter-branch --prune-empty --subdirectory-filter dir2/dir3 HEAD
   Возвращено: Ref 'refs/heads/master' was rewritten (к сведению: dir2 / dir3 чувствительны к регистру.)

4. $ git remote add some_name [email protected]:MyTeam/mynewrepo.git
git remote add origin etc. не получилось, вернул "remote origin already exists"

5. $ git push --progress some_name master

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

ПЕРВЫЙ, filter-branch проделал огромную работу по удалению коммитов, которые вводят или изменяют код, но, очевидно, коммиты слияния находятся ниже его позиции в Gitiverse.

• Скриншот безумного! а>

• Double Norenshoret"> фильтр-ветвь

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

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

Более легкий путь

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, у которого есть путь: [email protected]: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 [email protected]: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 [email protected]:simpliwp/xyz.git

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

При этом использование моего диска резко упало, хотя мои первоначальные условия были несколько иными. Возможно --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 subtree все в порядке, но все мои подкаталоги управляемого кода git, который я хотел переместить, были в eclipse. Так что, если вы используете egit, это очень просто. Возьмите проект, который вы хотите переместить, и команда-> отключите его, а затем команда-> поделитесь им в новом месте. По умолчанию он будет пытаться использовать старое местоположение репо, но вы можете снять флажок использовать существующий выбор и выбрать новое место, чтобы переместить его. Всем привет, егит.

Вы можете легко попробовать https://help.github.com/enterprise/2.15/user/articles/splitting-a-subfolder-out-into-a-new-repository/

Это сработало для меня. Проблемы, с которыми я столкнулся в приведенных выше шагах, следующие:

1. в этой команде git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME BRANCH-NAME BRANCH-NAME - главный

2. если последний шаг завершился неудачно при фиксации из-за проблемы с защитой, следуйте - https://docs.gitlab.com/ee/user/project/protected_branches.html.

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

1) Клонируйте репозиторий, который хотите разделить

git clone [email protected]:testrepo/test.git

2) Перейти в папку git

cd test/

2) Удалите ненужные папки и зафиксируйте их

rm -r ABC/
git add .
enter code here
git commit -m 'Remove ABC'

3) Удалите ненужную историю форм папок с помощью BFG.

cd ..
java -jar bfg.jar --delete-folders "{ABC}" test
cd test/
git reflog expire --expire=now --all && git gc --prune=now --aggressive

для нескольких папок вы можете использовать запятую

java -jar bfg.jar --delete-folders "{ABC1,ABC2}" metric.git

4) Убедитесь, что в истории нет файлов / папок, которые вы только что удалили.

git log --diff-filter=D --summary | grep delete

5) Теперь у вас есть чистый репозиторий без ABC, поэтому просто вставьте его в новый источник.

remote add origin [email protected]:username/new_repo
git push -u origin master

Вот и все. Вы можете повторить шаги, чтобы получить другой репозиторий,

просто удалите XY1, XY2 и переименуйте XYZ -> ABC на шаге 3

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

1. Подготовка текущего репозитория

$ cd path/to/repository
$ git subtree split -P my-folder -b my-folder
Created branch 'my-folder'
aecbdc3c8fe2932529658f5ed40d95c135352eff

Имя папки должно быть относительным путем, начиная с корня репозитория.

2. Создание нового репозитория

$ cd my-folder
$ git init
Initialized empty Git repository in /Users/adamwest/Projects/learngit/shop/my-folder/.git/
$ git add .
$ git commit -m "initial commit"
[master (root-commit) 192c10b] initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file

Здесь нам просто нужно записать cd в новую папку, инициализировать новый репозиторий и зафиксировать любое содержимое.

3. Добавьте новый удаленный репозиторий и нажмите

$ git remote add origin [email protected]:robertlyall/my-folder.git
$ git push origin -u master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 199 bytes | 199.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:robertlyall/my-folder.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

Мы добавляем сюда новый репозиторий, удаленный от GitHub, а затем помещаем в него нашу первую фиксацию.

4. Удалите папку из основного репозитория и нажмите

$ cd ../
$ git rm -rf my-folder
rm 'my-folder/file'
$ git commit -m "Remove old folder"
[master 56aedbe] remove old folder
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 my-folder/file
$ git push
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 217 bytes | 217.00 KiB/s, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com:robertlyall/shop.git
   74dd8b3..56aedbe  master -> master

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