Проблема
Я хочу, чтобы моя компания сохраняла все включенные внешние библиотеки в системе контроля версий, но я хотел бы, чтобы эти внешние библиотеки были в одном репо (не включены в каждыйиндивидуальный проект), так как есть довольно много библиотек, и они большие.
Уровень техники
Этот вопрос решает проблему, но никто не ответил на нее напрямую.(Как мне организовать мое Git-репо [лучшее название приветствуется])
Это довольно хорошо описывает аналогичную ситуацию, но без кубиков.(Git, суб-репо и внешние библиотеки для веб-разработки - лучшая стратегия раз и навсегда?)
Это определенно отвечает на вопрос, но использует подмодули.(Лучшая практика для Git-репозиториев с несколькими проектами в традиционном n-уровневом дизайне)
Git Slave звучит замечательно, но я бы предпочел не добавлять другой инструмент git в наш репертуар, посколькуНовое для нас.
Это то, о чем я думаю до сих пор.
my coding dir/
app1/
.git/
src/
com/
...
app2/
.git/
src/
com/
...
ext libs/
.git/
server crap/
apache tomcat 7.0.123/
...
apache cxf versionnumber/
...
util crap/
someones really great util lib-1.0/
...
И тогда в конфигурации будет переменная $ PATHили что-то подобное, что указывало бы на директорию lib.
Больше мыслей
- У нас нет инженера по инфраструктуре, и потому что я не хочуБудь на связи каждый раз, когда кому-то нужно добавить или обновить библиотеку, я бы хотел уйти от подмодуля git, потому что он кажется грубым.Я рад перейти к этому в будущем, но мы только начинаем наш напиток из мерзавца koolaid.
- Я также рад использовать подмодули сейчас, если кто-то может указать мне на ясное объяснение , что это такое, и ясное руководство , как использоватьчтобы я мог передать эту информацию своим коллегам. Я не хочу, чтобы все читали два часа документации по продвинутым темам, пока мы только сейчас встаем на ноги с Git.
- Было бы неплохо связать версии репозитория lib с версиями репозиториев приложений.
Опять же, меня можно отговорить от моих настроений против субмодулей, но тот факт, чтоучебники, которые я могу найти, устарели и / или сбивают с толку - это серьезный недостаток.Это должен быть простой процесс для любого инженера, и его легко отменить.Мы не мерзкие ниндзя!
Наконец, я не знаю, имеет ли это значение, но мы все на Unix и все время на Java.
Заранее спасибо!
Обновление 3-1-2012
Я собираюсь заставить ребенка Линуса Торвальдса плакать.
Я провел немало исследований, и я пришел к выводу, что подмодули - это замечательно , если вы уже git ninja .Таким образом, я сказал, что собираюсь поступить неправильно и создать каталог libs в каждом git-проекте.Зачем?Это проще, и это огромное улучшение по сравнению с тем, что мы делаем в настоящее время.Это также предполагает гораздо более низкий порог знаний git.Однажды, когда мы все твердо разберемся с основными и промежуточными концепциями git (патчи? Переписывание истории? Расширенное ветвление?), Мы, вероятно, перейдем к подмодулям.В нынешнем виде я не хочу настраивать своих инженеров на неудачу, давая им слишком много жевать.
Надеемся, что между этим моментом и когда мы будем готовы перейти на «правильный путь», подмодули будутменьше гнар.