Подкаталоги выписки в Git?

Можно ли проверить подкаталоги репозитория в Git?

Представьте, что я устанавливаю новую установку WordPress. Я создам два новых каталога для моей настройки плагина и темы:

  • wordpress/wp-content/plugins/myplugins/
  • wordpress/wp-content/themes/mytheme/

Я хочу поддерживать эти каталоги через Git. В Subversion я выполнил бы это, имея каталоги trunk/myplugins/ и trunk/mytheme/ и проверив подкаталоги. Имеет ли Git способ выполнить одну задачу с помощью одного репозитория?

Я мог бы просто пропустить лодку на какой-то парадигме Git, как долгое время SVN-пользователь с небольшой экспозицией Git.

Изменить: Несколько веток, хранящие различный контент, - это интересный способ справиться с этим.

Ответ 1

Редкие проверки теперь в Git 1.7.

Также см. вопрос "Возможно ли разрешить проверку, не проверив сначала весь репозиторий?.

Обратите внимание, что для редких проверок по-прежнему требуется загрузить весь репозиторий, хотя некоторые из файлов Git загрузок не окажутся в рабочем дереве.

Ответ 2

Нет реального способа сделать это в git. И если вы не будете делать изменения, которые влияют на оба дерева одновременно как единое рабочее подразделение, нет веских оснований использовать единый репозиторий для обоих. Я думал, что пропущу эту функцию Subversion, но я обнаружил, что создание репозиториев имеет настолько мало административных накладных расходов (просто из-за того, что хранилища хранятся непосредственно рядом с их рабочей копией, вместо того, чтобы потребовать от меня явно выбрать какое-то место за пределами рабочая копия), что я привык к тому, чтобы создавать множество небольших универсальных хранилищ.

Если вы настаиваете (или действительно нуждаетесь в нем), вы можете создать репозиторий git с помощью только mytheme и myplugins каталогов и символических ссылок из установки WordPress.


MDCore писал (а):

совершение фиксации, например, mytheme, увеличит номер версии для myplugin

Обратите внимание, что это не проблема для git, если вы решите поместить оба каталога в один репозиторий, потому что git полностью исключает концепцию монотонно увеличивающихся номеров версий любой формы.

Единственный критерий для того, что вещи собраны в одном репозитории в git, состоит в том, является ли он одной единицей, т.е. в вашем случае, есть ли изменения, когда нет смысла рассматривать отдельные изменения в каждом каталоге изолированно. Если у вас есть изменения, когда вам нужно редактировать файлы в обоих каталогах одновременно, а изменения принадлежат друг другу, они должны быть одним хранилищем. Если нет, то не сгладьте их вместе.

Git действительно хочет, чтобы вы использовали отдельные репозитории для отдельных объектов.

подмодули

Субмодули не обращают внимания на желание сохранить обе директории в одном репозитории, потому что они фактически обеспечивали бы наличие отдельного репозитория для каждого каталога, которые затем объединяются в другой репозиторий с использованием подмодулей. Хуже того, поскольку каталоги внутри установки WordPress не являются прямыми подкаталогами одного и того же каталога и также являются частью иерархии со многими другими файлами, использование репозиториев per-directory в качестве подмодулей в унифицированном репозитории не принесет никакой пользы, поскольку унифицированный репозиторий не будет отражать какой-либо прецедент/необходимость.

Ответ 3

Фактически, "узкие" или "частичные" или "редкие" проверки находятся в текущем тяжелом развитии для Git. Обратите внимание: у вас все равно будет полный репозиторий под .git. Таким образом, остальные два столбца являются текущими для текущего состояния Git, но он выглядит, так как мы в конце концов можем сделать разреженные проверки. Оформить списки рассылки, если вас интересует более подробная информация - они быстро меняются.

Ответ 4

Одна вещь, которая мне не нравится в редких проверках, заключается в том, что если вы хотите проверить подкаталог, содержащий несколько каталогов, ваша структура каталогов должна содержать все каталоги, ведущие к нему.

Как я работаю, это клонировать репо в месте, которое не является моей рабочей областью, а затем создавать символическую ссылку в моем каталоге рабочей области в подкаталоге в репозитории. Git работает так хорошо, потому что такие вещи, как Git статус, будут отображать файлы изменений относительно вашего текущего рабочего каталога.

Ответ 5

Вы не можете проверить один каталог репозитория, потому что весь репозиторий обрабатывается одной .git-папкой в ​​корне проекта, а не подрывной мириадой каталогов .svn.

Проблема с работой над плагинами в одном репозитории заключается в том, что совершение фиксации, например, mytheme, увеличит номер версии myplugin, поэтому даже в subversion лучше использовать отдельные репозитории.

Парадигма subversion для подпроектов svn: externals, которая несколько переводится как в git (но не совсем в том случае, если вы использовали svn: externals before.)

Ответ 6

Как вы можете указать, вы можете использовать две отдельные ветки для хранения двух отдельных каталогов. Это удерживает их обоих в одном хранилище, но вы по-прежнему не можете зафиксировать оба дерева каталогов. Если у вас есть изменение в одном, которое требует изменения в другом, вам придется делать это как две отдельные коммиты, и вы открываете возможность того, что пара проверок двух каталогов может выйти из синхронизации.

Если вы хотите рассматривать пару каталогов как единое целое, вы можете использовать "wordpress/wp-content" в качестве корня вашего репо и использовать файл .gitignore на верхнем уровне, чтобы игнорировать все, кроме двух подкаталогов интерес. На данный момент это, вероятно, самое разумное решение.

Предполагалось, что в течение двух лет появятся редкие проверки, но в репозитории развития git по-прежнему нет никаких признаков, а также никаких указаний на то, что необходимые изменения когда-либо прибудут туда. Я не буду рассчитывать на них.