Оформить заказ подкаталоги в Git?
Можно ли проверить подкаталоги репозитория в Git?
Представьте, что я устанавливаю новую установку WordPress. Я создам две новые директории для своего плагина и настройки темы:
wordpress/wp-content/plugins/myplugins/
wordpress/wp-content/themes/mytheme/
Я хочу поддерживать эти каталоги через Git. В Subversion я бы достиг этого, имея trunk/myplugins/
а также trunk/mytheme/
каталоги и проверка подкаталогов. Есть ли у Git способ выполнить ту же задачу, используя один репозиторий?
Я мог бы просто пропустить лодку по какой-то парадигме Git, как давний пользователь SVN, мало знакомый с Git.
Изменить: несколько ветвей, хранящих различное содержимое, является интересным способом справиться с этим.
10 ответов
Редкие проверки теперь в Git 1.7.
Также см. Вопрос " Можно ли сделать редкую проверку без предварительной проверки всего хранилища?".
Обратите внимание, что для редких проверок по-прежнему требуется загрузить весь репозиторий, даже если некоторые файлы, загружаемые Git, не окажутся в вашем рабочем дереве.
git clone --filter
из Git 2.19
Эта опция фактически пропускает выборку ненужных объектов с сервера:
git clone --depth 1 --no-checkout --filter=blob:none \
"file://$(pwd)/server_repo" local_repo
cd local_repo
git checkout master -- mdir/
Сервер должен быть настроен с:
git config --local uploadpack.allowfilter 1
git config --local uploadpack.allowanysha1inwant 1
Начиная с версии v2.19.0 сервер не поддерживается, но его уже можно локально протестировать.
file://$(path)
требуется преодолеть git clone
Протокол Shenanigans: Как отмелить клонирование локального репозитория git с относительным путем?
Помни что --depth 1
уже подразумевает --single-branch
Смотрите также: Как мне клонировать одну ветку в Git?
СДЕЛАТЬ: --filter=blob:none
пропускает все BLOB-объекты, но по-прежнему выбирает все объекты дерева. Но в обычном репо это должно быть крошечным по сравнению с самими файлами, так что это уже достаточно хорошо. На вопрос: https://www.spinics.net/lists/git/msg342006.html Разработчики ответили --filter=tree:0
находится в работе, чтобы сделать это.
Формат --filter
задокументировано man git-rev-list
,
Для поддержки этой функции было сделано расширение к протоколу Git remote.
Документы по дереву Git:
- https://github.com/git/git/blob/v2.19.0/Documentation/technical/partial-clone.txt
- https://github.com/git/git/blob/v2.19.0/Documentation/rev-list-options.txt
- https://github.com/git/git/blob/v2.19.0/t/t5616-partial-clone.sh
Проверьте это
#!/usr/bin/env bash
set -eu
list-objects() (
git rev-list --all --objects
echo "master commit SHA: $(git log -1 --format="%H")"
echo "mybranch commit SHA: $(git log -1 --format="%H")"
git ls-tree master
git ls-tree mybranch | grep mybranch
git ls-tree master~ | grep root
)
# Reproducibility.
export GIT_COMMITTER_NAME='a'
export GIT_COMMITTER_EMAIL='a'
export GIT_AUTHOR_NAME='a'
export GIT_AUTHOR_EMAIL='a'
export GIT_COMMITTER_DATE='2000-01-01T00:00:00+0000'
export GIT_AUTHOR_DATE='2000-01-01T00:00:00+0000'
rm -rf server_repo local_repo
mkdir server_repo
cd server_repo
# Create repo.
git init --quiet
git config --local uploadpack.allowfilter 1
git config --local uploadpack.allowanysha1inwant 1
# First commit.
# Directories present in all branches.
mkdir d1 d2
printf 'd1/a' > ./d1/a
printf 'd1/b' > ./d1/b
printf 'd2/a' > ./d2/a
printf 'd2/b' > ./d2/b
# Present only in root.
mkdir 'root'
printf 'root' > ./root/root
git add .
git commit -m 'root' --quiet
# Second commit only on master.
git rm --quiet -r ./root
mkdir 'master'
printf 'master' > ./master/master
git add .
git commit -m 'master commit' --quiet
# Second commit only on mybranch.
git checkout -b mybranch --quiet master~
git rm --quiet -r ./root
mkdir 'mybranch'
printf 'mybranch' > ./mybranch/mybranch
git add .
git commit -m 'mybranch commit' --quiet
echo "# List and identify all objects"
list-objects
echo
# Restore master.
git checkout --quiet master
cd ..
# Clone. Don't checkout for now, only .git/ dir.
git clone --depth 1 --quiet --no-checkout --filter=blob:none "file://$(pwd)/server_repo" local_repo
cd local_repo
# List missing objects from master.
echo "# Missing objects after --no-checkout"
git rev-list --all --quiet --objects --missing=print
echo
echo "# Git checkout fails without internet"
mv ../server_repo ../server_repo.off
! git checkout master
echo
echo "# Git checkout fetches the missing directory from internet"
mv ../server_repo.off ../server_repo
git checkout master -- d1/
echo
echo "# Missing objects after checking out d1"
git rev-list --all --quiet --objects --missing=print
Выход в Git v2.19:
# List and identify all objects
c6fcdfaf2b1462f809aecdad83a186eeec00f9c1
fc5e97944480982cfc180a6d6634699921ee63ec
7251a83be9a03161acde7b71a8fda9be19f47128
62d67bce3c672fe2b9065f372726a11e57bade7e
b64bf435a3e54c5208a1b70b7bcb0fc627463a75 d1
308150e8fddde043f3dbbb8573abb6af1df96e63 d1/a
f70a17f51b7b30fec48a32e4f19ac15e261fd1a4 d1/b
84de03c312dc741d0f2a66df7b2f168d823e122a d2
0975df9b39e23c15f63db194df7f45c76528bccb d2/a
41484c13520fcbb6e7243a26fdb1fc9405c08520 d2/b
7d5230379e4652f1b1da7ed1e78e0b8253e03ba3 master
8b25206ff90e9432f6f1a8600f87a7bd695a24af master/master
ef29f15c9a7c5417944cc09711b6a9ee51b01d89
19f7a4ca4a038aff89d803f017f76d2b66063043 mybranch
1b671b190e293aa091239b8b5e8c149411d00523 mybranch/mybranch
c3760bb1a0ece87cdbaf9a563c77a45e30a4e30e
a0234da53ec608b54813b4271fbf00ba5318b99f root
93ca1422a8da0a9effc465eccbcb17e23015542d root/root
master commit SHA: fc5e97944480982cfc180a6d6634699921ee63ec
mybranch commit SHA: fc5e97944480982cfc180a6d6634699921ee63ec
040000 tree b64bf435a3e54c5208a1b70b7bcb0fc627463a75 d1
040000 tree 84de03c312dc741d0f2a66df7b2f168d823e122a d2
040000 tree 7d5230379e4652f1b1da7ed1e78e0b8253e03ba3 master
040000 tree 19f7a4ca4a038aff89d803f017f76d2b66063043 mybranch
040000 tree a0234da53ec608b54813b4271fbf00ba5318b99f root
# Missing objects after --no-checkout
?f70a17f51b7b30fec48a32e4f19ac15e261fd1a4
?8b25206ff90e9432f6f1a8600f87a7bd695a24af
?41484c13520fcbb6e7243a26fdb1fc9405c08520
?0975df9b39e23c15f63db194df7f45c76528bccb
?308150e8fddde043f3dbbb8573abb6af1df96e63
# Git checkout fails without internet
fatal: '/home/ciro/bak/git/test-git-web-interface/other-test-repos/partial-clone.tmp/server_repo' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
# Git checkout fetches the missing directory from internet
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.
# Missing objects after checking out d1
?8b25206ff90e9432f6f1a8600f87a7bd695a24af
?41484c13520fcbb6e7243a26fdb1fc9405c08520
?0975df9b39e23c15f63db194df7f45c76528bccb
Выводы: все капли снаружи d1/
не хватает.
Обратите внимание, что root/root
а также mybranch/mybranch
также отсутствуют, но --depth 1
скрывает это от списка отсутствующих файлов. Если вы удалите --depth 1
Затем они отображаются в списке отсутствующих файлов.
Нет реального способа сделать это в git. И если вы не будете вносить изменения, которые влияют на оба дерева одновременно, как на единую рабочую единицу, нет веской причины использовать один репозиторий для обоих. Я думал, что пропущу эту функцию Subversion, но обнаружил, что создание репозиториев требует очень незначительных административных затрат (просто из-за того, что репозитории хранятся рядом с их рабочей копией, вместо того, чтобы требовать от меня явного выбора некоторого места вне рабочая копия), к которой я привык просто делать множество небольших одноцелевых репозиториев.
Если вы настаиваете (или действительно нуждаетесь в этом), вы можете создать git-репозиторий с помощью mytheme
а также myplugins
каталоги и символические ссылки изнутри установки WordPress.
MDCore написал:
сделав коммит, например, mytheme увеличит номер ревизии для myplugin
Обратите внимание, что это не имеет значения для git, если вы решите поместить оба каталога в один репозиторий, потому что git полностью избавляется от концепции монотонно увеличивающегося номера ревизии любой формы.
Единственный критерий того, что нужно собрать в один репозиторий в git - это то, является ли он единым целым, т.е. в вашем случае, есть ли изменения, когда нет смысла смотреть на изменения в каждом каталоге изолированно. Если у вас есть изменения, в которых вам нужно отредактировать файлы в обоих каталогах одновременно, и изменения должны быть вместе, это должен быть один репозиторий. Если нет, то не обманывайте их вместе.
Git действительно хочет, чтобы вы использовали отдельные репозитории для отдельных сущностей.
Подмодули не учитывают желание хранить оба каталога в одном репозитории, поскольку они фактически навязывают наличие отдельного репозитория для каждого каталога, которые затем объединяются в другом репозитории с использованием подмодулей. Хуже того, поскольку каталоги внутри установки WordPress не являются прямыми подкаталогами одного и того же каталога и также являются частью иерархии со многими другими файлами, использование репозиториев для каждого каталога в качестве подмодулей в объединенном репозитории не принесет никакой пользы, потому что унифицированный репозиторий хранилище не будет отражать какой-либо вариант использования / необходимость.
Одна вещь, которая мне не нравится в редких извлечениях, это то, что если вы хотите извлекать подкаталог с несколькими каталогами, ваша структура каталогов должна содержать все ведущие к нему каталоги.
Как обойти эту проблему, можно клонировать репо в месте, которое не является моим рабочим пространством, а затем создать символическую ссылку в моем каталоге рабочего пространства на подкаталог в репозитории. Git работает очень хорошо, потому что такие вещи, как git status, будут отображать файлы изменений относительно вашего текущего рабочего каталога.
На самом деле, "узкие", "частичные" или "редкие" извлечения находятся в настоящее время в тяжелом развитии для Git. Обратите внимание, у вас все еще будет полный репозиторий .git
, Итак, две другие записи являются текущими для текущего состояния Git, но похоже, что в конечном итоге мы сможем делать редкие проверки. Проверьте списки рассылки, если вы заинтересованы в более подробной информации - они быстро меняются.
Вы не можете извлечь один каталог из репозитория, потому что весь репозиторий обрабатывается единственной папкой.git в корне проекта вместо множества каталогов.svn в Subversion.
Проблема с работой над плагинами в одном репозитории заключается в том, что при фиксации, например, mytheme, будет увеличиваться номер ревизии для myplugin, поэтому даже в subversion лучше использовать отдельные репозитории.
Парадигма subversion для подпроектов - это svn:externals, что несколько переводит на подмодули в git (но не совсем, если вы использовали svn:externals ранее.)
Я посмотрел на разные ответы, в том числе на вопрос « Как клонировать только подкаталог репозитория Git?»
Это были не очень простые ответы, поэтому я решил написать небольшой скрипт, который должен помочь упростить процесс. См. https://gist.github.com/hiranp/a26e334369386211709f4846929a6157 .
#!/bin/env bash
# This script clones the remote repository using the --filter=blob:none option to avoid downloading any file contents.
# It then checks out the specified remote branch and enables sparse-checkout. The sparse-checkout pattern is set to only
# include the desired folder, and finally, the latest changes are pulled from the remote branch.
# NOTE:
# Customize this script by setting the REMOTE_REPO_URL, REMOTE_BRANCH, GIT_FOLDER_PATH, and LOCAL_REPO_PATH variables.
# Set the remote repository URL
REMOTE_REPO_URL="<URL>"
# Set the remote branch name
REMOTE_BRANCH="branch-name"
# Set the path to the folder you want to copy
GIT_FOLDER_PATH="path/to/folder"
# Set the path to the local repository
LOCAL_REPO_PATH="path/to/local/repo"
echo "Cloning the remote repository...to ${LOCAL_REPO_PATH}"
if [ ! -d "${LOCAL_REPO_PATH}" ]; then
mkdir -p "${LOCAL_REPO_PATH}"
# Shadow clone the remote repository
git clone --depth 1 --no-checkout --filter=blob:none "${REMOTE_REPO_URL}" "${LOCAL_REPO_PATH}"
fi
# Change to the repository directory
cd "${LOCAL_REPO_PATH}"
# Checkout the remote branch
git checkout "${REMOTE_BRANCH}"
if [ ! -f ".git/info/sparse-checkout" ]; then
# Enable sparse-checkout
git sparse-checkout init
# Set the sparse-checkout pattern to only include the desired folder
git sparse-checkout set "${LOCAL_REPO_PATH}"
fi
# Pull the latest changes from the remote branch
git pull origin "${REMOTE_BRANCH}"
Как указывает ваше редактирование, вы можете использовать две отдельные ветви для хранения двух отдельных каталогов. Это сохраняет их обоих в одном репозитории, но вы все равно не можете иметь коммиты, охватывающие оба дерева каталогов. Если у вас есть изменение в одном, которое требует изменения в другом, вам придется сделать это как два отдельных коммита, и вы открываете возможность того, что пара проверок двух каталогов может быть не синхронизирована.
Если вы хотите рассматривать пару каталогов как один блок, вы можете использовать "wordpress / wp-content" в качестве корня вашего репозитория и использовать файл.gitignore на верхнем уровне, чтобы игнорировать все, кроме двух подкаталогов, представляющих интерес. Это, наверное, самое разумное решение на данный момент.
Редкие проверки, как утверждается, происходят в течение двух лет, но до сих пор нет никаких признаков их появления в репозитории git development, а также никаких признаков того, что необходимые изменения когда-либо появятся там. Я бы на них не рассчитывал.
Здесь есть вдохновение. Просто используйтеshell regex
или git regex
.
git checkout commit_id */*.bat # *.bat in 1-depth subdir exclude current dir, shell regex
git checkout commit_id '*.bat' # *.bat in all subdir include current dir, git regex
Используйте цитату, чтобы избежать интерпретации регулярного выражения оболочки и передать подстановочные знаки в git.
Первый не рекурсивный, только файлы в 1-глубине subdir
. Но второй - рекурсивный.
Что касается вашей ситуации, может быть достаточно следующего.
git checkout master */*/wp-content/*/*
git checkout master '*/wp-content/*'
Просто взломайте линии по мере необходимости.
Вы можете вернуть незафиксированные изменения только к определенному файлу или каталогу:
git checkout [some_dir|file.txt]