Это такой распространенный сценарий, что должно быть разумное решение, но, несмотря на страницы чтения и обильной гимнастики Git, мой мозг болит, и я не могу сделать эту работу...
Я работаю с Wordpress, хотя это будет соответствовать большинству сценариев веб-сайта. Я хочу управлять установкой сайта с помощью репозитория Git, а также управлять различными плагинами WP, плагинами jQuery и другими кодовыми битами в отдельных репозиториях, которые можно легко вытащить/вытолкнуть из внешних источников. Кажется достаточно простым, пока вы не посмотрите на детали...
Критерий "Подпапки" Папка для каждого плагина не должна привязываться к корневой папке исходного репо. Многие репозитории имеют несколько вложенных папок, таких как "my-repo-name/...", "dev/", "test/", "src/", где требуется содержимое более поздней версии. Это важно, чтобы сохранить ссылки на URL-адреса в чистоте и свести к минимуму общедоступный мусор.
Критерий "Нет Proxys" Идеальное решение не потребует дополнительных промежуточных ветвей или репозиториев. Нажатие изменений в внешний источник плагина должно быть простым и не требовать нескольких промежуточных слияний/нажатий.
Критерий "Реальные файлы" В идеале внешнее репо для всего веб-сайта должно фактически содержать файлы подположений плагинов (т.е. нет "подмодулей" ). Меня можно было убедить от этого, хотя...
Критерий "Публикация" Он должен хорошо работать с rsync и/или Git нажатием на живой сервер
Git Субмодули Достаточно просто для внесения изменений и нажатия/вытягивания, но подмодули выходят из строя на критериях "Подпапки" и "Реальный файл"
Git read-tree/subtree merge Решает проблему "Реальные файлы", а read-tree фактически позволяет вам ссылаться на вложенную папку ветки, но когда я это сделал, и попытался объединить изменения на возврате мастера upstream, Git не помнил, что он пришел из подпапки и объединил всю структуру цели в ветвь отслеживания ext libs... поэтому FAIL по этому критерию.
Расширение поддерева Apenwarrs (здесь) Отлично подходит для критерия "Реальные файлы" и довольно просто нажать/вытащить, пока вы не захотите применить правило "Подпапки". В лучшем случае это, похоже, требует промежуточных ветвей, где вы отделяете нужную папку от удаленной ветки отслеживания, а затем добавляете это как поддерево в свою основную ветку. У меня не было большой удачи слияния/нажатия изменений на сервере обратно в исходное репо. Я все еще думаю, что здесь может быть возможность...
Символьные ссылки с внешним репо Отличное решение до тех пор, пока Git не остановится после символических ссылок. Теперь он терпит неудачу в отношении критериев "Реальные файлы" и "Публикация"
Вложенные репозитории
Где-то я увидел ответ SO, где, если явным образом git add папка, содержащая другое репо и включающая конечную косую черту, Git НЕ подмодулирует ее, а вместо этого отслеживает отдельные файлы. Это казалось многообещающим, но оно не соответствует критерию "Подпапки".
Я видел ссылки на "редкую проверку" - или, возможно, что-то, связанное с обрезкой ветвей. Я надеюсь избежать решения, которое включает в себя сценарии оболочки или настолько сложно, что для меня требуется, чтобы я каждый раз изучал его (нечасто), я вношу изменения в плагин. Это должно быть проще, чем поддерживать отдельное репо для каждого плагина и копировать назад и вперед от основной установки CMS.
Несомненно, у кого-то есть простой функциональный способ сделать этот общий сценарий совместной работы? Заранее спасибо за помощь...
Очевидно, вы об этом подумали, и я всего лишь новичок в git, но моим первым инстинктом было бы добавить .gitignore в каталог плагинов и иметь каждый плагин с его собственным git repo. Вы можете сделать то же самое для тем. Поэтому я предполагаю, что это скорее вопрос, чем ответ - почему бы не использовать этот простой подход?
Я не знаю, ответит ли это на ваш вопрос полностью или даже рассмотрит ваш конкретный сценарий, но я подумал, что в любом случае я его отдам.
У нас есть несколько проектов, многие из которых ссылаются друг на друга, каждый в своем собственном репозитории Git. Они также содержатся в нескольких уровнях папок, например:
Repos
- Utilities
- Util repo1
- Util repo2
- Common
- Lib repo1
- Lib repo2
- Projects
- Client1
- Git repo1
- Git repo2
- Client2 repo
- Client3
...
У нас возникла проблема с ручным запуском/вытягиванием/фиксацией каждого репозитория, который стал кошмаром.
Итак, мы написали небольшую служебную программу, которая может выполнять операции push, pull, commit, tag, remote diff и diff Git в нескольких папках за раз, а также одновременно создавать несколько файлов решений VS, Он также проверит в подпапках для репозиториев.
Мы используем его в течение некоторого времени, и он отлично подходит для нас. Вы можете проверить это здесь: Gitter.7z
Откройте файл ReadMe.html, чтобы узнать, как его использовать. Надеюсь, что это поможет, дайте мне знать.