Git клонировать не все файлы
Я хочу клонировать репозиторий GIT и не заканчивать с . Другими словами, Мне нужны только файлы. Есть ли способ сделать это?
git clone --no-checkout сделал прямо противоположное тому, что я хочу (мне дали только ).
Я пытаюсь сделать это для пульт ДУ РЕПО, а не локальное, то есть это не дубликат of"как сделать "экспорт git" (например, "экспорт svn")" (хотя решение может в конечном итоге то же самое).
команда git, которая будет ближе всего от того, что вы ищете, будет git archive .
См.резервное копирование проекта, который использует git: он будет включать в архив все файлы (включая подмодули, если вы используете git-archive-all сценарий)
вы можете использовать этот архив в любом месте, возвращая вам только файлы, нет .
Если вам нужны папки и файлы просто с первого уровня:
перечислить только папки первого уровня удаленного РЕПО:
другой вариант - сделать неглубокий клон (как указано ниже), но найти его .папки в Git в другом месте.
папка РЕПО будет включать только файл, без .git .
Примечание: git --git-dir вариант команда git , а не git clone .
обновление с Git 2.14.X / 2.15 (Q4 2017): это будет убедитесь, чтобы избежать добавления пустых папок.
" git archive ", особенно при использовании с pathspec, хранится пустой каталог в его выходных данных, хотя Сам Git никогда этого не делает.
Это было исправлено.
archive не добавлять пустые каталоги в архив
при ЖКТ не отслеживает пустые каталоги, git archive можно обмануть, поставив некоторые в архивы.
Хотя это поддерживается базой данных объектов, он не может быть представлен в индексе и, следовательно, вряд ли произойдет в дикой природе.
поскольку пустые каталоги не поддерживаются git, они также не должны быть записано в архив.
Если пустой каталог действительно нужен, его можно отслеживать и архивировать, поместив пустой в нем.
вы можете создать неглубокий клон, чтобы получить только последние несколько версий:
затем либо просто удалить .каталог git или используйте git archive для экспорта дерева.
Почему бы не выполнить клон, а затем удалить .git каталог, так что у вас просто есть голая рабочая копия?
Edit: или на самом деле зачем вообще использовать clone? Это немного запутанно, когда вы говорите, что хотите РЕПО git, но без . Если вы имеете в виду, что вам просто нужна копия некоторого состояния дерева, то почему бы не сделать cp -R в оболочке вместо клона git, а затем удалите .git далее.
похоже, вам просто нужна копия исходного кода. Если да, то почему бы просто не скопировать каталог и исключить.каталог git из копии?
есть другой способ сделать это, разделив РЕПО от рабочего дерева.
мы сделаем две папки, одну для git, одну для рабочих файлов:
инициализировать голое репозиторий git:
затем создайте крюк после получения:
добавить это в качестве пульта ДУ:
теперь каждый раз, когда вы нажимаете на это голое РЕПО, он проверяет рабочее дерево на /workingfiles/ . Но!--5--> сам не находится под контролем версий; бег!--7--> на /workingfiles/ даст ошибку fatal: Not a git repository (or any parent up to mount point /data) . Это просто файлы.
в отличие от других решений rm -r .git команда не требуется, так что если /workingfiles/ это какой-то другой репозиторий git, вам не нужно беспокоиться о команде, используемой для удаления файлов git другого репозитория.
У меня есть репозиторий Git, в корне которого есть два подкаталога:
Когда это было в SVN, /finisht проверялся в одном месте, а /static был получен где-то еще, например:
Есть ли способ сделать это с помощью Git?
РЕДАКТИРОВАТЬ : начиная с Git 2.19 это, наконец, возможно, как видно из этого ответа. .
Подумайте о том, чтобы проголосовать за этот ответ.
Примечание: в Git 2.19 реализована только поддержка на стороне клиента, поддержка на стороне сервера по-прежнему отсутствует, поэтому работает только при клонировании локальных репозиториев. Также обратите внимание, что крупные хостеры Git, например GitHub, на самом деле не используют сервер Git, они используют свою собственную реализацию, поэтому даже если поддержка отображается на сервере Git, это не означает автоматически, что она работает на хостах Git. (OTOH, поскольку они не используют сервер Git, они могли бы реализовать его быстрее в своих собственных реализациях, прежде чем он появится на сервере Git.)
Нет, в Git это невозможно.
Реализация чего-то подобного в Git потребует значительных усилий и будет означать, что целостность клиентского репозитория больше не может быть гарантирована. Если вам интересно, поищите обсуждения по «разреженному клону» и «разреженной выборке» в списке рассылки git.
В общем, в сообществе Git существует консенсус в том, что если у вас есть несколько каталогов, которые всегда проверяются независимо, то на самом деле это два разных проекта, которые должны находиться в двух разных репозиториях. Вы можете снова склеить их вместе с помощью подмодулей Git.
То, что вы пытаетесь сделать, называется разреженной проверкой , и эта функция была добавлена в git 1.7.0 (февраль 2012 г.). Шаги по созданию разреженного клона следующие:
Это создает пустой репозиторий с вашим пультом дистанционного управления и извлекает все объекты, но не извлекает их. Затем сделайте:
Теперь вам нужно определить, какие файлы / папки вы хотите проверить. Это делается путем перечисления их в .git/info/sparse-checkout , например:
И последнее, но не менее важное: обновите пустое репо, указав состояние с пульта дистанционного управления:
Теперь у вас будут файлы, "извлеченные" для some/dir и another/sub/tree в вашей файловой системе (с этими путями), и никаких других путей нет.
Возможно, вы захотите ознакомиться с расширенным руководством и вам, вероятно, следует прочитать официальную документацию по разреженным проверкам.
Обратите внимание, что при этом все равно будет загружен весь репозиторий с сервера - только касса уменьшится в размере. На данный момент невозможно клонировать только один каталог. Но если вам не нужна история репозитория, вы можете хотя бы сэкономить на пропускной способности, создав неглубокий клон. См. ответ udondan ниже для получения информации о том, как комбинировать мелкие clone и разреженная проверка.
Начиная с git 2.25.0 (январь 2020 г.) экспериментальный sparse-checkout команда добавлена в git:
Вы можете комбинировать функции разреженного извлечения и неглубокого клонирования . мелкий клон обрезает историю, а разреженная проверка извлекает только файлы, соответствующие вашим шаблонам.
Вам понадобится как минимум git 1.9, чтобы это работало. Сам тестировал только с 2.2.0 и 2.2.2.
Таким образом, вы по-прежнему сможете нажимать , что невозможно с git archive .
git clone --filter из git 2.19 теперь работает на GitHub (проверено 2021-01-14, git 2.30.0)
Эта опция была добавлена вместе с обновлением удаленного протокола и действительно предотвращает загрузку объектов с сервера.
Этот репозиторий содержит:
- большой каталог с 10 файлами по 10 МБ
- небольшой каталог с 1000 файлов размером один байт
Все содержимое является псевдослучайным и, следовательно, несжимаемым.
Время клонирования в моем Интернете со скоростью 36,4 Мбит / с:
Часть sparse-checkout , к сожалению, тоже нужна. Вы также можете загружать только определенные файлы с гораздо более понятным:
Но этот метод по какой-то причине загружает файлы один за другим очень медленно, что делает его непригодным для использования, если вы в каталоге очень мало файлов.
Анализ объектов в минимальном репозитории
Команда clone получает только:
- один объект фиксации с кончиком ветки master
- все 4 древовидные объекты репозитория:
- каталог фиксации верхнего уровня
- три каталога d1 , d2 , master
Затем команда git sparse-checkout set извлекает с сервера только недостающие капли (файлы):
Более того, позже GitHub, вероятно, начнет поддерживать:
Предположительно потому, что составной фильтр --filter=combine: (добавлен в Git 2.24, подразумевается несколькими --filter ) еще не реализован.
Я наблюдал, какие объекты были получены с помощью:
Как указано на странице: Как перечислить ВСЕ объекты git в базе данных? Это не дает мне четкого указания на то, что именно представляет собой каждый объект, но он говорит о типе каждого объекта ( commit , tree , blob ), и поскольку в этом минимальном репо так мало объектов, я могу однозначно определить, что это за каждый объект.
git rev-list --objects --all действительно дает более четкий вывод с путями для дерева / блобов, но, к сожалению, он извлекает некоторые объекты, когда я его запускаю, что затрудняет определение того, что было извлечено и когда, дайте мне знать, есть ли у кого-нибудь лучшая команда.
git sparse-checkout
Я думаю, что эта команда предназначена для управления файлом настроек, который говорит: «Меня интересуют только эти поддеревья», так что будущие команды будут влиять только на эти поддеревья. Но в этом немного сложно быть уверенным, потому что текущая документация немного . скудна ;-)
Само по себе это не предотвращает получение капель.
Если это понимание верно, то это будет хорошим дополнением к git clone --filter , описанному выше, поскольку это предотвратит непреднамеренную выборку дополнительных объектов, если вы намереваетесь выполнять операции git в частичном клонированном репо.
Когда я попробовал Git 2.25.1:
Это не сработало, потому что init фактически получил все объекты.
Однако в Git 2.28 он не извлекал объекты должным образом. Но если я это сделаю:
Так что да, сейчас в этом слишком сложно быть уверенным, отчасти благодаря тому, что GitHub радует закрытым исходным кодом. Но давайте следить за этим.
Разбивка команд
Сервер должен быть настроен с:
--filter=blob:none пропускает все капли, но все равно получает все объекты в виде дерева
--depth 1 уже подразумевает --single-branch , см. Также: Как клонировать отдельную ветку в Git?
--filter=combine:FILTER1+FILTER2 - это синтаксис для одновременного использования нескольких фильтров, попытка передать --filter по какой-то причине не удалась: "несколько спецификаций фильтров не могут быть объединены". Это было добавлено в Git 2.24 по адресу e987df5fe62b8b29be4cdcdeb3704681ada2b29e «фильтр-список-объекты: реализовать составные фильтры».
Изменить: в Git 2.28 я экспериментально вижу, что --filter=FILTER1 --filter FILTER2 также имеет тот же эффект, поскольку GitHub еще не реализует combine: по состоянию на 2020-09-18 и жалуется на fatal: invalid filter-spec 'combine:blob:none+tree:0' . В какой версии введен TODO?
Формат --filter задокументирован на man git-rev-list .
Документы по дереву Git:
Протестируйте на месте
Вывод в Git v2.19.0:
Выводы: все капли за пределами d1/ отсутствуют. Например. 0975df9b39e23c15f63db194df7f45c76528bccb , то есть d2/b , отсутствует после проверки d1/a .
Обратите внимание, что root/root и mybranch/mybranch также отсутствуют, но --depth 1 скрывает это из списка отсутствующих файлов. Если вы удалите --depth 1 , они появятся в списке отсутствующих файлов.
У меня есть мечта
Эта функция может произвести революцию в Git.
Представьте, что у вас есть вся кодовая база вашего предприятия в одном репо без уродливые сторонние инструменты, такие как repo .
Представьте, что GitHub разрешил бы метаданные для каждого файла / каталога, такие как звездочки и разрешения, чтобы вы могли хранить все ваши личные вещи в рамках единого репо.
Для других пользователей, которые просто хотят скачать файл / папку с github, просто используйте:
(да, это svn. по-видимому, в 2016 году вам все еще понадобится svn, чтобы просто загрузить некоторые файлы github)
Важно . Убедитесь, что вы обновили URL-адрес github и заменили /tree/master/ на '/ trunk /'.
Как скрипт bash:
Если вы никогда не планируете взаимодействовать с репозиторием, из которого вы клонировали, вы можете выполнить полное git clone и переписать репозиторий с помощью git filter-branch --subdirectory-filter . Так хоть история сохранится.
Если история не нужна, то git-archive в помощь.
Как? Без клонирования всего репозитория.
В общем случае никак, git так не умеет, тебе нужно склонировать весь репозиторий. Но если ты хочешь просто сэкономить место и bandwidth — сделай shallow clone ( git clone --depth=1 ).
А оно точно каталогами может выгружать?
Shallow clone - это типа без истории и прочего?
А, гм, не знал про такую. Но это тоже без истории. У тебя ошибка скорее всего потому что слеш в начале пути не нужен.
Без слеша такой-же результат.
Похоже, на GitHub эта команда не работает, проверил с домашним Gitorious, там прокатывает.
если ты хочешь просто сэкономить место и bandwidth — сделай shallow clone (git clone --depth=1)
Я про этот шаллов клон вот тут давно спрашивал кх он не работает и внятного объяснения до сих пор не имею. Более того, так и не встретил человека, который бы его успешно использовал - все советуют друг другу то, что в гугле прочитали :). У тебя по тому топику идей нету?
Я успешно использую вот прямо сейчас. У тебя там транспорт у remote какой?
intelfx ★★★★★ ( 21.02.18 14:02:37 )
Последнее исправление: intelfx 21.02.18 14:05:12 (всего исправлений: 1)Я не дождался конца второго clone, но разницу в количестве объектов ты видишь. Удостоверься, что на том конце не dumb transport.
Разницу в количестве объектов я и у себя вижу, только трафика вытягивается-то все равно больше.
Удостоверься, что на том конце не dumb transport.
Deleted ( 21.02.18 14:45:10 )
Последнее исправление: Deleted 21.02.18 14:49:13 (всего исправлений: 1)Если хочется сэкономить на размере рабочего каталога и ускорить операции типа git status, можно использовать sparse checkout. Правда клонироваться будет все равно целый репозиторий (но не все файлы будут распаковываться)
Нет, мне именно часть репозитория стащить хотелось, не для редактирования и перезалива на github, а просто чтобы тему установить
У меня есть мой Git-репозиторий, в корне которого есть два подкаталога:
Когда это было в SVN , /finisht было проверено в одном месте, в то время как /static было проверено в другом месте, вот так:
Есть ли способ сделать это с Git?
Для пользователя 2014 года, какая самая git clone простая команда? Я использовал этот простой ответ . Если есть что-то более простое, пожалуйста, прокомментируйте
@JoachimBreitner: Этот вопрос касается проверки подкаталогов в Git (что легко), тогда как этот вопрос касается клонирования подкаталогов в Git (что невозможно).
РЕДАКТИРОВАТЬ : Начиная с Git 2.19, это наконец возможно, как видно из этого ответа .
Подумайте об этом ответе.
Примечание: в Git 2.19 реализована только поддержка на стороне клиента, поддержка на стороне сервера по-прежнему отсутствует, поэтому она работает только при клонировании локальных репозиториев. Также обратите внимание, что крупные хосты Git, например GitHub, на самом деле не используют сервер Git, они используют свою собственную реализацию, поэтому даже если поддержка появляется на сервере Git, это не означает, что она автоматически работает на хостах Git. (OTOH, поскольку они не используют Git-сервер, они могли бы реализовать его быстрее в своих собственных реализациях, прежде чем он появится на Git-сервере.)
Нет, это не возможно в Git.
Внедрение чего-то подобного в Git было бы существенным усилием, и это означало бы, что целостность клиентского репозитория больше не может быть гарантирована. Если вам интересно, поищите обсуждения "sparse clone" и "sparse fetch" в списке рассылки git.
В целом, в сообществе Git единодушным является то, что если у вас есть несколько каталогов, которые всегда извлекаются независимо, то это действительно два разных проекта, которые должны находиться в двух разных репозиториях. Вы можете склеить их вместе, используя Git Submodules .
@StijndeWitt: редкие проверки происходят в течение git-read-tree долгого времени get-fetch . Речь шла не о проверке только подкаталога, а о клонировании только подкаталога. Я не вижу, как редкие проверки могли бы сделать это, так как git-read-tree запускается после того, как клон уже завершен.
Вместо этого "заглушки", вы хотели бы, чтобы я удалил этот ответ, чтобы Chronial's мог всплыть наверх? Вы не можете удалить это самостоятельно, потому что это принято, но модератор может. Вы бы сохранили репутацию, которую заработали на ней, ведь она такая старая. (Я сталкивался с этим, потому что кто-то пометил его как «только для ссылок». :-)
@CodyGray: хронический ответ по- прежнему клонирует весь репозиторий, а не только подкаталог. (В последнем абзаце даже об этом прямо сказано.) Клонирование только подкаталога невозможно в Git. Сетевой протокол не поддерживает это, формат хранения не поддерживает это. Каждый ответ на этот вопрос всегда клонирует весь репозиторий. Вопрос простой, да / нет, и ответ состоит из двух символов: Нет. Если вообще, мой ответ излишне длинный , а не короткий.
То, что вы пытаетесь сделать, называется разреженной проверкой , и эта функция была добавлена в git 1.7.0 (февраль 2012 г.). Шаги для разреженного клона следующие:
Это создает пустой репозиторий с вашим пультом и выбирает все объекты, но не проверяет их. Затем сделайте:
Теперь вам нужно определить, какие файлы / папки вы хотите проверить. Это можно сделать, перечислив их .git/info/sparse-checkout , например:
И последнее, но не менее важное: обновите ваш пустой репо с помощью состояния с удаленного компьютера:
Теперь у вас есть файлы «проверило» для some/dir и another/sub/tree в файловой системе (с этими траекториями еще), и никаких других путями настоящим.
Возможно, вы захотите взглянуть на расширенный учебник, и вам, вероятно, следует прочитать официальную документацию для редких проверок .
Обратите внимание, что при этом все хранилище будет загружено с сервера - только размер извлечения уменьшается. На данный момент невозможно клонировать только один каталог. Но если вам не нужна история хранилища, вы можете по крайней мере сэкономить на пропускной способности, создав мелкий клон. См . Ответ Удондана ниже для получения информации о том, как объединить мелкий клон и редкую проверку.
Начиная с git 2.25.0 (январь 2020 г.) в git добавлена экспериментальная команда sparse-checkout :
Это улучшение, но по-прежнему необходимо загружать и хранить полную копию удаленного репозитория в оригинале, чего можно вообще избежать, если его интересуют только части кодовой базы (или если есть подпапки документации, как в моем случае )
@Chronial, @ErikE: вы оба правильно / неправильно: Р git remote add команда не не означает , выборка, но git remote add -f , как он используется здесь, делает! Вот что -f значит.
Используя это, --depth=1 я клонировал Chromium Devtools в 338 МБ вместо 4,9 ГБ полного источника Blink + история. Отлично.
git clone --filter из Git 2.19
Эта опция фактически пропускает выборку ненужных объектов с сервера. Кроме того, включая --filter=tree:0 Git 2.20 и --filter=combine композитный фильтр, добавленный в Git 2.24, мы получаем:
Сервер должен быть настроен с:
Было сделано расширение к протоколу удаленного доступа Git для поддержки этой функции v2.19.0 и пропуска выборки ненужных объектов, но в то время поддержка сервера отсутствовала. Но это уже можно проверить на месте.
- --filter=blob:none пропускает все BLOB- объекты , но по-прежнему выбирает все объекты дерева
- --filter=tree:0 пропускает ненужные деревья: https://www.spinics.net/lists/git/msg342006.html
- --depth 1 уже подразумевается --single-branch , см. также: Как мне клонировать одну ветку в Git?
- file://$(path) Требуется преодолеть git clone протокол shenanigans: Как мелко клонировать локальный репозиторий git с относительным путем?
- --filter=combine:FILTER1+FILTER2 это синтаксис для использования нескольких фильтров одновременно, попытка передать --filter по какой-то причине не удалась с помощью: «несколько спецификаций фильтра не могут быть объединены». Это было добавлено в Git 2.24 на e987df5fe62b8b29be4cdcdeb3704681ada2b29e "список-объект-фильтр: реализовать составные фильтры"
Формат --filter задокументирован man git-rev-list .
Документы по дереву Git:
Проверьте это
Выход в Git v2.19.0:
Выводы: все капли снаружи d1/ отсутствуют. Например 0975df9b39e23c15f63db194df7f45c76528bccb , которого d2/b нет после проверки d1/a .
Обратите внимание, что root/root и mybranch/mybranch также отсутствуют, но --depth 1 скрывает это из списка отсутствующих файлов. Если удалить --depth 1 , то они отобразятся в списке отсутствующих файлов.
У меня есть мечта
Эта функция может революционизировать Git.
Представьте себе, что вся кодовая база вашего предприятия в одном репо без уродливых сторонних инструментов, таких как repo .
Представьте, что GitHub разрешит метаданные для каждого файла / каталога, такие как звездочки и разрешения, чтобы вы могли хранить все свои личные вещи в одном репо.
Представьте, что подмодули обрабатываются точно так же, как обычные каталоги : просто запросите дерево SHA, и DNS-подобный механизм разрешит ваш запрос , сначала посмотрев на ваш локальный ~/.git сервер, затем сначала на более близкие серверы (зеркало / кэш вашего предприятия) и попав на GitHub.
Как ни странно, в macOS с версией git 2.20.1 (Apple Git-117) он жалуется, что «несколько спецификаций фильтра не могут быть объединены»
К сожалению, не повезло с версией macOS git. fatal: invalid filter-spec 'combine:blob:none+tree:0' Спасибо, в любом случае! Возможно это будет работать с более новыми версиями.
Это терпит неудачу при попытке сделать это в Windows 10 с использованием GIT 2.24.1 (выбрасывает тонны «невозможно прочитать файл sha1 из ..» + «Не удалось удалить ссылку из файла xxx.»). Работал как шарм с той же версией в Linux.
Вы можете объединить скудный контроль и мелкий клон . В мелком клоне отрежет историю и разреженной проверка тянет только файлы , которые соответствуют вашей модели.
Вам понадобится минимум git 1.9, чтобы это работало. Протестировал сам только с 2.2.0 и 2.2.2.
Таким образом, вы все равно сможете толкать , что невозможно с git archive .
Для других пользователей, которые просто хотят загрузить файл / папку с github, просто используйте:
(да, это svn здесь. очевидно, в 2016 году вам все еще нужно svn, чтобы просто загрузить некоторые файлы github)
Важно - убедитесь, что вы обновили URL-адрес github и заменили /tree/master/ на «/ trunk /».
Как скрипт bash:
Единственная версия, которая работала для меня с GitHub. Команды git извлекли> 10 тыс. Файлов, svn экспортирует только те 700, которые мне нужны. Спасибо!
@ zthomas.nc Вам нужно удалить 'trunk', предшествующий udacity, и заменить вместо него / tree / master / на / trunk /.
Эта команда работала на меня! Я просто хотел получить копию файла из репозитория, чтобы я мог изменить его локально. Старый добрый SVN на помощь!
Если вы никогда не планируете взаимодействовать с репозиторием, из которого вы клонировали, вы можете сделать полный клон git и переписать свой репозиторий, используя git filter-branch --subdirectory-filter . Таким образом, по крайней мере, история будет сохранена.
Преимущество этого метода заключается в том, что выбранный вами подкаталог становится корнем нового репозитория, и это именно то, что мне нужно.
Это выглядит намного проще:
Когда я делаю это на github, я получаю фатальную операцию: операция не поддерживается протоколом. Неожиданный конец командного потока
Не будет работать с Github -> Недопустимая команда: 'git-upload-archive' xxx / yyy.git '' Вы, похоже, используете ssh для клонирования URL git: //. Убедитесь, что опция конфигурации core.gitProxy и переменная окружения GIT_PROXY_COMMAND НЕ установлены. фатальный: удаленный конец неожиданно повесил трубку
Интерфейс не так удобен, как в SVN (например, нет способа сделать редкую проверку во время первоначального клона), но теперь доступна базовая функциональность, на которой могут быть построены более простые интерфейсы.
Невозможно клонировать подкаталог только с помощью Git, но ниже приведено несколько обходных путей.
Ветвь фильтра
Возможно, вы захотите переписать репозиторий, чтобы он выглядел так, как если бы trunk/public_html/ он был корневым каталогом проекта, и отбросьте всю другую историю (используя filter-branch ), попробуйте уже извлеченную ветку:
Примечания: Объект, -- который отделяет параметры ветви фильтра от параметров ревизии, и --all перезаписывает все ветви и теги. Вся информация, включая исходное время фиксации или информацию о слиянии, будет сохранена . Эта команда учитывает .git/info/grafts файл и ссылки в refs/replace/ пространстве имен, поэтому, если у вас есть какие-либо трансплантаты или refs определенные замены , выполнение этой команды сделает их постоянными.
Предупреждение! Переписанная история будет иметь разные имена объектов для всех объектов и не будет сходиться с исходной ветвью. Вы не сможете легко перемещать и распространять переписанную ветку поверх оригинальной ветви. Пожалуйста, не используйте эту команду, если вы не знаете всех последствий, и избегайте ее использования в любом случае, если для решения вашей проблемы будет достаточно простого коммита.
Редкий заказ
Вот простые шаги с подходом разреженной проверки, который будет редко заполнять рабочий каталог, так что вы можете указать Git, какие папки или файлы в рабочем каталоге стоит проверить.
Репозиторий клонов как обычно ( --no-checkout необязательно):
Вы можете пропустить этот шаг, если ваш репозиторий уже клонирован.
Подсказка: для больших репозиториев рассмотрите мелкий clone ( --depth 1 ), чтобы получить только последнюю версию или / и --single-branch только.
Включить sparseCheckout параметр:
Укажите папку (ы) для разреженной проверки ( без пробела в конце):
или редактировать .git/info/sparse-checkout .
Оформить заказ в филиале (например master ):
Теперь вы должны были выбрать папки в вашем текущем каталоге.
Вы можете рассмотреть символические ссылки, если у вас слишком много уровней каталогов или фильтрующих веток.
У меня есть каталог A с файлами, совпадающими с каталогом B. В каталоге A могут быть другие необходимые файлы. Каталог B - это git-репо.
Я хочу клонировать каталог B в каталог A, но git-clone не разрешит мне, так как каталог не пустой.
Я надеялся, что он просто клонирует .git, и, поскольку все файлы совпадают, я могу перейти оттуда?
Я не могу клонировать в пустой каталог, потому что у меня есть файлы в каталоге A, которых нет в каталоге B, и я хочу их сохранить.
Копирование .git не вариант, так как я хочу, чтобы ссылки пушли / тянули, и я не хочу устанавливать их вручную.
Есть какой-либо способ сделать это?
Обновление: я думаю, что это работает, кто-нибудь может увидеть какие-либо проблемы? ->
Это сработало для меня:
ПРИМЕЧАНИЕ: -t установит ветку upstream для вас, если это то, что вы хотите, и обычно это так.
Это не работает в непустом каталоге, когда входящие файлы уже существуют (как описывает оригинальный вопрос). Но если вы git reset origin/master после git fetch , это будет работать (также сохраняя любые локальные изменения).
Этот ответ не работает для меня. Когда я делаю git checkout . git, жалуется, что все мои файлы будут перезаписаны, и я должен сначала переместить их. Когда я сначала выполняю `git reset origin / master /`, команда checkout жалуется, что ветвь с именем master уже существует.
Все шаги работали отлично, но последний получил меня fatal: A branch named 'master' already exists . Я думаю, что мне это не нужно.
В следующих командах оболочки existing-dir есть каталог, содержимое которого соответствует отслеживаемым файлам в repo-to-clone репозитории git.
git reset HEAD работал нормально для меня. git reset --hard HEAD уничтожает любые изменения в ваших файлах, поэтому, если они не совпадают с файлами в хранилище, вы не должны этого делать.
git reset HEAD кажется, не имеет никакого влияния на меня. git reset --hard HEAD делает - но это теряет любые изменения, которые вы внесли в файлы. Есть ли лучшее решение?
@ Ответ Кейси - git init / remote add / fetch / checkout - чище и проще и не требует никаких временных папок.
Ответ @ Кейси не сработал, когда в папках уже были файлы, которые нужно было сохранить, но их не было в git-репо. Это полезно для обновления конфигурации после запуска сценариев установки, где создаются файлы и каталоги, но вам нужно обновить / добавить файлы поверх установленных элементов.
начать работу над мастер-веткой прямо сейчас.
пришлось сделать сброс HEAD --hard, чтобы очистить грязный существующий каталог, не удаляя ненужные файлы, указанные в gitignore
Предупреждение - это может перезаписать файлы.
Модифицировано из ответа @ cmcginty - без -f у меня не получилось
Вот что я в итоге делал, когда у меня была та же проблема (по крайней мере, я думаю, что это та же проблема). Я пошел в каталог А и побежал git init .
Поскольку я не хотел, чтобы за файлами в каталоге A следовал git, я отредактировал .gitignore и добавил в него существующие файлы. После этого я побежал git remote add origin '' && git pull origin master и вуаля, B «клонируется» в A без единого сбоя.
Этот метод не работает в непустом каталоге, когда входящие файлы уже существуют (как описывает оригинальный вопрос).
Я использовал это несколько минут назад, требуя наименее потенциально разрушительных команд:
Другой простой рецепт, кажется, хорошо работает для меня:
Мой основной вариант использования для извлечения в каталог с существующими файлами - это управление моими точечными файлами Unix с помощью Git. В новой учетной записи в домашнем каталоге уже будут некоторые файлы, возможно, даже те, которые я хочу получить из Git.
Только два отличия: 1.) .git/config Файл указывает, что репозитории пустые. 2.) Файлы, обычно хранящиеся в .git , хранятся в корне (который вы назвали .git )
Это именно те изменения, к которым будут относиться клонирование .git и настройка , поэтому я все еще чувствую себя хорошо в этом методе. core.bare false
Это сработало для меня:
У меня была похожая проблема с новым веб-каталогом Apache (учетная запись, созданная с помощью WHM), которую я планировал использовать в качестве промежуточного веб-сервера. Сначала мне нужно было клонировать мой новый проект с базой кода и периодически вносить изменения, извлекая данные из репозитория.
Проблема заключалась в том, что учетная запись уже содержала файлы веб-сервера, такие как:
. что я не хотел ни удалять, ни фиксировать в своем хранилище. Мне нужно было, чтобы они оставались там без посторонних и неотслеживаемых.
Я пошел в свою веб-папку (существующая_фолдер):
Он отображал (как и ожидалось) список многих не подготовленных файлов - тех, которые изначально существовали в моей учетной записи cPanel.
Затем, благодаря этой статье , я просто добавил список этих файлов в:
Этот файл, почти как .gitignore файл, позволяет вам игнорировать файлы от постановки. После этого мне нечего было коммитить в каталог .git / - он работает как личный .gitignore который никто не может увидеть.
Теперь проверяем git status возвраты:
Теперь я могу развернуть изменения на этом веб-сервере, просто извлекая данные из моего репозитория git. Надеюсь, что это поможет некоторым веб-разработчикам легко создать промежуточный сервер.
Читайте также: