Экспериментируя, похоже, что стратегия, которую я изложил, является лучшей / наиболее функциональной.
По сути, вы создали каталог верхнего уровня, который мы можем назвать "venv". Затем вы создаете виртуальную среду в этом каталоге. Если вы это сделаете, вы увидите все скрытые файлы, которые реализуют virtualenv. В частности, посмотрите на «секретные» файлы (выполнив «ls. *»). Пока все хорошо.
Теперь создайте две подкаталоги, которые мы будем называть foo и bar. перейдите к первому и выполните «git init» с последующим клонированием репозитория для ветви 1. (Не забудьте выполнить «git --add», за которым следует «git commit», так что все файлы Git для подкаталога "foo" застряли в этом подкаталоге.)
Теперь перейдите в другую ветку ("cd ../bar") и сделайте то же самое (т.е. "git init" с последующим клоном, добавлением и фиксацией). Это должно сделать bar и все его подкаталоги управляемыми из собственного Git репозитория.
Что немного сбивает с толку, так это то, что для того, чтобы активировать виртуальную среду из root любого из подкаталогов, вам нужно выполнить «source ../bin/activate». Другими словами, каталог / bin в каталоге / venv является узлом обоих каталогов, которые «содержат» все файлы magi c Git (снова попробуйте «ls. *», Чтобы они появились).
Но сама виртуальная среда, похоже, не должна быть частью чего-либо, о чем Git знает.
Все еще рад слышать другие мнения, но это удивительно мало объясняется, учитывая, как часто у человека есть проект с (скажем) внешним и внутренним интерфейсом.