Локальные и удаленные репозитории должны иметь одни и те же файлы для фиксации
Ответ на ваш первый вопрос: да, Git может обрабатывать несколько локальных репозиториев, но, похоже, вы не используете Git так, как он был разработан для использования - поэтому вам будет сложно помочь вам решить эту проблему, или, по крайней мере, вам будет лучше изменить рабочий процесс, если вы хотите сделать это с помощью Git.
Позвольте мне объяснить:
У меня есть foo. cpp в каталоге source_code. Я не хочу копировать все из удаленного репо в source_code.
Я предполагаю, что под «удаленным репо» вы имеете в виду репо на удаленном сервере, то есть Bitbucket. В Git нет такой вещи, как наличие локальной копии удаленного репо с меньшим количеством файлов для данной фиксации. Когда вы клонируете репозиторий Git, вы получаете все файлы. Фактически, обычно все файлы со всеми коммитами / историей. В этом и состоит суть Git - контролировать версии всех ваших файлов, чтобы вы могли воссоздать точную копию всех файлов из любого коммита на любом P C.
Если вы просто хотите обновить foo.cpp в репо, просто измените foo.cpp, добавьте его в индекс, а pu sh верните его на удаленный. В новом коммите все остальные файлы останутся, только foo.cpp изменено в новом коммите.
Как выйти из текущей ситуации?
Вы можете выйти из перебазирования / слияния, выполнив полный сброс до последней фиксации в вашем локальном репо. Это сбросит все, чтобы начать снова. Но я не думаю, что вы сможете работать так, как вы sh, и при этом синхронизировать данные c.
Когда вы выбираете и пытаетесь перебазировать, перемотать вперед или объединить, Git запутается, если вы удалите файлы, потому что вы не хотите, чтобы они находились в локальном репо, но они существуют на удаленном - таким образом, вы получаете ошибки
Несколько локальных репозиториев?
Я не уверен, зачем вам нужны разные локальные репозитории для разных IDE, но вы МОЖЕТЕ сделать это, если это действительно необходимо. Просто дважды клонируйте репозиторий в разные каталоги.
Просто поймите, что всякий раз, когда вы sh подключаетесь к удаленному от одного из локальных, он будет выглядеть так же, как другой пользователь, отправленный на удаленный из другого репо. Вам нужно будет получить эти изменения и выполнить fastforward / merge (git pull - это комбинация git fetch и git merge) в другом локальном репо, чтобы включить их. Если вы обновляете оба локальных репозитория независимо, в конечном итоге вы столкнетесь с конфликтами слияния, если они будут редактировать одни и те же файлы. Однако, если вы всегда "переключаете" между репозиториями, отталкиваясь от одного, а затем опускаясь, прежде чем работать над другим, этого никогда не должно произойти.
Рассмотрите возможность использования одного локального репозитория (или нескольких удаленных репозиториев).
Однако я бы задал вопрос, зачем вам нужны два отдельных репозитория локально для «разных IDE». Я бы действительно изучил ваши аргументы в пользу такой настройки - вероятно, существует лучший рабочий процесс.
Вы должны иметь возможность работать из одного локального репо, в котором есть все файлы, необходимые для любой из IDE. Если вам действительно нужны разные файлы и нужно управлять ими отдельно, подумайте о создании для них полностью отдельных репозиториев. Существуют различные методы, которые можно использовать для обмена общими файлами между двумя репозиториями, например, субмодули третьего репо в виде библиотеки, которая имеет общие файлы.
Нам потребуется более подробная информация о цели использования двух отдельных IDE в одном репо, чтобы дать ответ на лучшие практики, как выполнить sh то, что с Git. Например, одна установка для разработки, а другая для выпуска? (Это был бы отличный отдельный вопрос для StackOverflow ...)