Git клонировать не все файлы

Обновлено: 07.07.2024

Я запускаю UNIX. Когда я делаю ls , все, что я вижу, это папка .git, и ни одна из страниц images/index.html не была клонирована здесь. Я пытался:

Я знаю, что мне нужно делать origin , потому что, когда я делаю git remote -v , вот что я получаю:

Итак, вкратце, вот что мне нужно сделать:

Выясните, как клонировать все мои файлы из /live/website в/developer1
Уметь вносить изменения в файлы локально на developer1 и возвращать эти изменения.

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

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

Инициализируйте голый репо на своем сервере, как вы писали:
git --bare init --shared=0777

Проверьте этот каталог на своей рабочей станции1:
git clone git://server/repo.git

Отбросьте некоторые файлы в это недавно клонированное репо и добавьте их на дорожку. Чтобы добавить все из них, выполните git add .

Заблокируйте добавленные файлы в локальный репозиторий:
git commit -m 'initial commit'
Теперь изменения (добавление файлов) были сохранены в локальном репозитории.

Наконец, отбросьте файлы (при условии, что вы работаете с мастером ветки) на сервер (известный как источник):
git push origin master

Чтобы вернуть изменения к центральному репо, вы можете просто набрать git push , поскольку вы настроили отслеживание ветки на шаге 5.

Теперь, если вы выполните git clone git://server/repo.git с другого компьютера (например, workstation2), вы получите файлы, которые вы только что отметили в.

Что общий рабочий процесс git:

Получить файлы с сервера (начальный: clone , последовательный pull )
Сделайте некоторые изменения и сохраните их в локальном репо ( git commit )
Когда наступит время, отмените локальные коммиты до голого репо ( git push )

Чтобы получить более подробное объяснение, см. раздел "Частная небольшая команда" в онлайн-версии прогитной книги.

У меня есть каталог A с файлами, совпадающими с каталогом B. В каталоге A могут быть другие необходимые файлы. Каталог B - это git-репо.

Я хочу клонировать каталог B в каталог A, но git-clone не разрешит мне, так как каталог не пустой.

Я надеялся, что он просто клонирует .git, и, поскольку все файлы совпадают, я могу перейти оттуда?

Я не могу клонировать в пустой каталог, потому что у меня есть файлы в каталоге A, которых нет в каталоге B, и я хочу их сохранить.

Копирование .git не вариант, так как я хочу, чтобы ссылки пушли / тянули, и я не хочу устанавливать их вручную.

Есть какой-либо способ сделать это?

Обновление: я думаю, что это работает, кто-нибудь может увидеть какие-либо проблемы? ->

Это сработало для меня:

ПРИМЕЧАНИЕ: -t установит ветку upstream для вас, если это то, что вы хотите, и обычно это так.

Это не работает в непустом каталоге, когда входящие файлы уже существуют (как описывает оригинальный вопрос). Но если вы git reset origin/master после git fetch , это будет работать (также сохраняя любые локальные изменения). Неустранимый: Невозможно обновить пути и переключиться на ветку 'master' одновременно. Этот ответ не работает для меня. Когда я делаю git checkout . git, жалуется, что все мои файлы будут перезаписаны, и я должен сначала переместить их. Когда я сначала выполняю `git reset origin / master /`, команда checkout жалуется, что ветвь с именем master уже существует. git checkout master был достаточным последним шагом для меня. Все шаги работали отлично, но последний получил меня fatal: A branch named 'master' already exists . Я думаю, что мне это не нужно.

В следующих командах оболочки existing-dir есть каталог, содержимое которого соответствует отслеживаемым файлам в repo-to-clone репозитории git.

Мне нужно было сделать, git reset --hard HEAD иначе он не отказался бы от «удаленных» файлов. 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. Эта версия работала для меня, просто пришлось сделать git reset --hard HEAD

Предупреждение - это может перезаписать файлы.

Модифицировано из ответа @ cmcginty - без -f у меня не получилось

Конечно, вам нужно проверить все файлы после этого с git checkout . ?

Вот что я в итоге делал, когда у меня была та же проблема (по крайней мере, я думаю, что это та же проблема). Я пошел в каталог А и побежал git init .

Поскольку я не хотел, чтобы за файлами в каталоге A следовал git, я отредактировал .gitignore и добавил в него существующие файлы. После этого я побежал git remote add origin '<url>' && 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. Надеюсь, что это поможет некоторым веб-разработчикам легко создать промежуточный сервер.

Я хочу клонировать репозиторий 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 — это процесс создания идентичной копии удаленного репозитория Git на локальную машину.

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

Как работает клонирование в Git?

Многие люди хотят создать общий репозиторий, чтобы позволить команде разработчиков публиковать свой код на GitHub / GitLab / BitBucket и т. д. Репозиторий, загружаемый в сеть для совместной работы, называется вышестоящим репозиторием или центральным репозиторием.

Центральный репозиторий указывает, что все изменения от всех участников помещаются только в этот репозиторий. Таким образом, это самый обновленный экземпляр репозитория самого себя. Иногда это часто называют исходным хранилищем. Изображение, приведенное ниже, довольно ясно говорит о концепции клонирования.

Что касается приведенного выше изображения, то процесс клонирования работает на следующих этапах:

Клонирование репозитория: пользователь начинает работу с вышестоящего репозитория на GitHub. Процесс начинается с клонирования репозитория на локальную машину. Теперь у пользователя есть точная копия файлов проекта в их системе, чтобы внести изменения.

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

Проталкивание изменений: как только изменения будут сделаны, они могут быть перемещены в вышестоящий репозиторий.

Примечание: владелец репозитория может разрешить / запретить прямые изменения в Центральном репозитории, установить различные уведомления о любом изменении, перенесенном в центральное хранилище и многое другое.

Как использовать команду git Clone

Клонирование в Git может быть сделано на собственном репозитории или в любом другом репозитории.

Как клонировать репозиторий или использовать команду git Clone?

Клонирование репозитория из GitHub — это простой процесс. Но, прежде чем клонировать, пожалуйста, убедитесь, что у вас есть репозиторий на вашем аккаунте GitHub.

Каковы основные различия между раздвоением и клонированием?

Чтобы очистить свой разум от воздуха, если он у вас есть, давайте посмотрим, чем отличаются эти два термина:

Разветвление делается на аккаунт github, а клонирование осуществляется с использованием git. При форке репозитория вы создаете копию исходного репозитория (вышестоящего репозитория), но этот репозиторий остается в вашей учетной записи GitHub. В то же время, когда вы клонируете репозиторий, он копируется на вашу локальную машину с помощью Git.

В последнем уроке мы познакомились с командой Git fetch и Read more

В одной из последних статей мы узнали о команде Git Read more

Мы уже знаем, как вносить изменения в локальное хранилище и Read more

Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more

Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more

Все данные, доступные в локальном репозитории, могут быть загружены в Read more

Читайте также: