На локальной машине, у меня есть общие сценарии, которые импортируются несколько проектов, например .:Git: несколько поддеревьев/подмодулей в одной папке?
/common/
.git/
scripts/
common1.py
/projectA/
.git/
scripts/
A1.py (imports from common1.py)
/projectB/
.git/
scripts/
B1.py (imports from common1.py)
Общие сценарии и проекты отслеживаются в отдельных GIT РЕПО. Это отлично работает для моей личной работы, потому что я могу клонировать все необходимые репозитории. При создании проекта в открытом доступе через мерзавец, я могу включать в себя общие файлы через поддеревьев или подмодулей (ссылки на общие файлы обновляются в B1.py, очевидно):
/projectB/
.git/
scripts/
common/ (subtree from common)
common1.py
B1.py
Теперь я хотел бы собрать суперпроект (цель):
/projectC/
.git/
scripts/
common1.py
A1.py
B1.py
с поддеревами и подмодулями я смог достичь:
/projectC/
.git/
scripts/
common/
common1.py
projectA_scripts/ (via subtree)
A1.py
common/ (via subtree w/in projectA)
common1.py
projectB_scripts/ (via subtree)
B1.py
common/ (via subtree w/in projectB)
common1.py
C1.py
Однако это совершенно излишняя и распространение изменений через суб-х цепной Виль l быть утомительным. Как я могу достичь целевой структуры каталогов выше, сохраняя возможность извлекать обновления для проектов и общих файлов? Для чего это стоит, я не ожидаю, что вам придется подталкивать изменения поддерева/подмодуля вверх по течению.
Бонус для кросс-платформенных (Windows-UNIX) решений, не требующих независимой настройки на обеих ОС. Предпочтительные решения на основе Git.
Интересный подход - конечно, может работать. Я не упомянул в OP, но я надеюсь на кросс-платформенное решение для Windows-UNIX, которое не требует независимой настройки в обеих ОС (в качестве символических ссылок). Предпочтительными являются решения на основе Git. – metasequoia
@metasequoia Ну, у Windows тоже есть символическая ссылка;) ([mklink] (http://technet.microsoft.com/en-us/library/cc753194%28v=ws.10%29.aspx), которая требует административных привилегий) – VonC