i

Вариант 1 (история изменений, добавлений файлов в папках останется):

1. Удалить локально, закомитить
   
2. Добавить названия папок в .gitignore
   
3. git push
   

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

1. git obliterate <путь_папки>(https://github.com/tj/git-extras)
   
2. git push --force
   

После этой операции другим участникам, надо будет локально сбросить ветки:

git fetch
git checkout master
git reset --hard origin/master

Аналог команды git obliterate исключительно средствами Git:

git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch -r <путь_папки>' \
--prune-empty --tag-name-filter cat -- --all

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

MYSQL_PWD=pass mysqldump \
-uUSER -hHOST \
--compact \
--add-drop-table \
--extended-insert=FALSE \
db_name > dump.sql

Это важно для избежания конфликтов.

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

Предположу что вы изначально клонировали свой форк и поэтому origin указывает на ваш проект.
Для решение надо в терминале проекта выполнить команду:
git remote set-url origin url_repo
url_repo - ссылка на репозиторий в который надо заливать.

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

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

Кода разработчик, а в идеале вся команда, делает фиксацию истории изменений, появляются возможности:

• Понимание чем мотивированно изменение, потому что коммит привязан к номеру задачи или содержит внятный комментарий;
  
• Понимание, как добавить новый функционал, если в истории коммиты это концентрированные изменения относящиеся к конкретным требования;
  
• Имея в своем активе вышеперечисленные возможности и добавив Пару приемов работы с git (это же относится и к другим VCS) получаем реальный король над проектом.
  

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

git clone <git repository A url>
cd <git repository A directory>
git remote rm origin
git filter-branch --subdirectory-filter <directory 1> -- --all
mkdir <directory 1>
mv * <directory 1>
git add .
git commit

Источник: Moving Files from one Git Repository to Another, P...