Как скопировать ветку git на локальный компьютер

Обновлено: 24.11.2024

  • Клонирование локального или удаленного репозитория
  • Клонирование пустого репозитория
  • Использование неглубоких опций для частичного клонирования репозиториев
  • Синтаксис Git URL и поддерживаемые протоколы

При настройке репозитория мы рассмотрели базовый вариант использования git clone . На этой странице рассматриваются более сложные сценарии клонирования и настройки.

Цель: копия совместной разработки репо-репо

Если проект уже настроен в центральном репозитории, команда git clone является наиболее распространенным способом получения пользователями копии для разработки. Как и git init, клонирование обычно является одноразовой операцией. После того, как разработчик получил рабочую копию, управление всеми операциями контроля версий и совместной работы осуществляется через его локальный репозиторий.

Сотрудничество между репо

Важно понимать, что идея Git о «рабочей копии» сильно отличается от рабочей копии, которую вы получаете, проверяя код из репозитория SVN. В отличие от SVN, Git не делает различий между рабочей копией и центральным репозиторием — все они являются полноценными репозиториями Git.

Это принципиально отличает совместную работу с Git от SVN. В то время как SVN зависит от отношений между центральным репозиторием и рабочей копией, модель совместной работы Git основана на взаимодействии между репозиториями. Вместо проверки рабочей копии в центральном репозитории SVN вы отправляете или извлекаете коммиты из одного репозитория в другой.

Конечно, ничто не мешает вам придавать некоторым репозиториям Git особое значение. Например, просто назначив один репозиторий Git «центральным» репозиторием, можно воспроизвести централизованный рабочий процесс с помощью Git. Дело в том, что это достигается с помощью соглашений, а не жестко запрограммировано в самой системе контроля версий.

Использование

git clone в основном используется для указания на существующий репозиторий и создания клона или копии этого репозитория в новом каталоге в другом месте. Исходный репозиторий может быть расположен в локальной файловой системе или на удаленном компьютере, доступном для поддерживаемых протоколов. Команда git clone копирует существующий репозиторий Git. Это похоже на проверку SVN, за исключением того, что «рабочая копия» представляет собой полноценный репозиторий Git — он имеет свою собственную историю, управляет своими собственными файлами и представляет собой полностью изолированную среду от исходного репозитория.

Для удобства клонирование автоматически создает удаленное соединение, называемое «источник», указывающее на исходный репозиторий. Это упрощает взаимодействие с центральным репозиторием. Это автоматическое соединение устанавливается путем создания ссылок Git на удаленные заголовки веток в разделе refs/remotes/origin и инициализации переменных конфигурации remote.origin.url и remote.origin.fetch.

Первая команда инициализирует новый репозиторий Git в папке my-project на вашем локальном компьютере и заполняет его содержимым центрального репозитория. Затем вы можете войти в проект и начать редактировать файлы, делать снимки и взаимодействовать с другими репозиториями. Также обратите внимание, что расширение .git отсутствует в клонированном репозитории. Это отражает состояние локальной копии, не являющееся голым.

Клонирование в определенную папку

Клонируйте репозиторий, расположенный в ＜repo＞, в папку с именем ~＜directory＞! на локальном компьютере.

Клонирование определенного тега

Клонируйте репозиторий, расположенный в ＜repo＞, и клонируйте ссылку только для ＜tag＞ .

Поверхностный клон

Клонировать репозиторий, расположенный в ＜repo＞, и клонировать только
историю коммитов, указанную параметром depth=1. В этом примере создается клон ＜repo＞, и только самая последняя фиксация включается в новый клонированный репозиторий. Поверхностное клонирование наиболее полезно при работе с репозиториями, имеющими обширную историю коммитов. Обширная история коммитов может вызвать проблемы с масштабированием, такие как ограничения на использование дискового пространства и длительное время ожидания при клонировании. Клонирование Shallow может решить эти проблемы с масштабированием.

Параметры конфигурации

git clone -ветка

Аргумент -branch позволяет указать конкретную ветвь для клонирования вместо ветки, на которую указывает удаленный HEAD, обычно это основная ветвь. Кроме того, вы можете передать тег вместо ветки для того же эффекта.

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

git clone -mirror и git clone -bare

git clone --bare

Подобно git init --bare, когда аргумент -bare передается в git clone, копия удаленного репозитория будет создана с опущенным рабочим каталогом. Это означает, что будет создан репозиторий с историей проекта, из которой можно выталкивать и извлекать, но нельзя редактировать напрямую.Кроме того, никакие удаленные ветки для репозитория не будут настроены с репозиторием -bare. Как и git init --bare, это используется для создания размещенного репозитория, который разработчики не будут редактировать напрямую.

git clone --mirror

Передача аргумента --mirror неявно передает и аргумент --bare. Это означает, что поведение --bare наследуется --mirror. В результате получается голое репо без редактируемых рабочих файлов. Кроме того, --mirror клонирует все расширенные ссылки удаленного репозитория и поддерживает конфигурацию отслеживания удаленных ветвей. Затем вы можете запустить удаленное обновление git на зеркале, и оно перезапишет все ссылки из исходного репозитория. Предоставляет вам точную «зеркальную» функциональность.

Другие параметры конфигурации

Полный список других параметров клонирования git см. в официальной документации Git. В этом документе мы коснемся некоторых других распространенных вариантов.

git clone --template

Клонирует репозиторий в ＜местоположение репозитория＞ и применяет шаблон из ＜каталога шаблонов＞ к вновь созданной локальной ветке. Подробный обзор шаблонов Git можно найти на нашей странице инициализации git.

URL-адреса Git

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

Протоколы Git URL

-SSH

Secure Shell (SSH) — это широко распространенный сетевой протокол с проверкой подлинности, который обычно настраивается по умолчанию на большинстве серверов. Поскольку SSH — это протокол с проверкой подлинности, перед подключением необходимо установить учетные данные на хост-сервере. ssh://[user@]host.xz[:port]/path/to/repo.git/

– ГИТ

Протокол, уникальный для git. Git поставляется с демоном, работающим на порту (9418). Протокол похож на SSH, но без АУТЕНТИФИКАЦИИ. git://host.xz[:port]/path/to/repo.git/

Обзор

<р>1. git clone используется для создания копии целевого репозитория

<р>2. Целевой репозиторий может быть локальным или удаленным

<р>3. Git поддерживает несколько сетевых протоколов для подключения к удаленным репозиториям

<р>4. Доступно множество различных параметров конфигурации, которые изменяют содержимое клона

Для получения более подробной информации о функциях клонирования git обратитесь к официальной документации Git. Мы также рассмотрим практические примеры git clone в нашем руководстве по настройке репозитория.

Боладжи Айодеджи

В отличие от старых централизованных систем управления версиями, таких как SVN и CVS, Git является распределенным. Каждый разработчик имеет полную историю и контроль над своим кодом локально или удаленно. Они также могут получать доступ к некоторым частям кода или управлять ими по своему усмотрению из разных мест.

С тех пор как Линус Торвальдс (известный создатель ядра операционной системы Linux) создал Git в 2005 году для разработки ядра Linux, он стал самой широко используемой современной системой управления версиями в мире.

В этой статье я познакомлю вас с рабочими процессами клонирования и ветки Git, а также покажу, как можно клонировать конкретную ветку в зависимости от ваших потребностей. Давай начнем! ?

Предпосылки

  • Базовые знания терминала
  • Возможность вводить команды в терминале
  • Git установлен (я покажу как)
  • Аккаунт GitHub
  • Улыбка на вашем лице (Поднимите эту улыбку, друг?)

Краткое введение в Git и GitHub

Git — это распределенная система контроля версий, предназначенная для отслеживания изменений в проекте (коде) при разработке программного обеспечения. Он предназначен для обеспечения координации, сотрудничества, скорости и эффективности среди разработчиков.

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

Как установить Git в Windows

Загрузите и установите последнюю версию установщика Git для Windows здесь.

Как установить Git в Linux

Вот команды для вашего дистрибутива Linux:

Debian или Ubuntu

Федора

ЦентрОС

Арх Linux

Генту

Как установить Git на Mac

Загрузите и установите последнюю версию установщика Git для Mac здесь.

Или вы можете ввести эту команду:

Теперь, когда мы установили Git, давайте перейдем к руководству.

Введение в Git Clone

Git позволяет управлять проектами и управлять ими в «репозитории». Этот репозиторий хранится на веб-хостинге для контроля версий, например на GitHub.

Затем вы можете клонировать этот репозиторий на свой локальный компьютер и иметь все файлы и ветки локально (скоро я объясню подробнее о ветках).

Например, вы можете клонировать репозиторий freeCodeCamp с помощью SSH следующим образом:

Введение в ветки Git

Во время работы над проектом у вас, скорее всего, будут разные функции. И несколько участников будут работать над этим проектом и его функциями.

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

Ветвление — это основная концепция Git, которая также используется в GitHub для управления рабочими процессами разных версий одного проекта. Основная ветвь всегда является ветвью по умолчанию в репозитории, который чаще всего считается «рабочим и развертываемым кодом». Новые ветки, такие как беспарольная-авторизация или refactor-signup-ux, могут быть созданы из основной ветки.

Все ветки в репозитории freeCodeCamp

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

Хотя вы можете клонировать репозитории с помощью команды git clone, имейте в виду, что при этом клонируется ветка и удаленный HEAD . Обычно это master по умолчанию и включает все остальные ветки в репозитории.

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

Допустим, вашей задачей в проекте является работа над функцией добавления аутентификации без пароля на панель управления пользователя. И эта функция находится в ветке беспарольной аутентификации.

Вам действительно не нужна основная ветвь, так как ваша "функциональная ветвь" впоследствии будет объединена с основной. Как же тогда клонировать эту ветку без пароля, не загружая все остальные ветки с «кучей файлов, которые вам не нужны»?

Я создал этот образец репозитория, чтобы объяснить это. Этот репозиторий содержит простой блог, созданный с помощью Nextjs, и имеет четыре фиктивные ветки:

  • мастер
  • разработчик
  • постановка
  • авторизация без пароля

В Nextjs любой файл в папке pages/api сопоставляется с путем /api/* и будет рассматриваться как конечная точка API, а не как страница. В нашем репозитории я создал разные фиктивные API в этом каталоге, чтобы каждая ветка отличалась друг от друга.

Главная ветвь содержит файл pages/api/hello.js, а ветка без пароля содержит файл pages/api/auth.js. Каждый файл просто возвращает фиктивный текстовый ответ. См. приветственный ответ API мастера здесь (со специальным сообщением для вас?).

Давайте клонируем репозиторий:

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

Интересно, откуда взялись ветки remotes/origin/..?

При клонировании репозитория данные извлекаются из репозитория в Интернете или с внутреннего сервера, называемого удаленным. Слово origin — это псевдоним, созданный вашим Git для замены удаленного URL-адреса (вы можете изменить или указать другой псевдоним, если хотите).

Эти ветки remotes/origin/.. указывают на исходный репозиторий, который вы клонировали из Интернета, поэтому вы все еще можете выполнять извлечение/передачу из источника.

Поэтому, когда вы клонируете master на свой компьютер, remotes/origin/master является исходной основной веткой в ​​Интернете, а master находится на вашем локальном компьютере. Таким образом, вы будете тянуть/нажимать от и к remotes/origin/master .

Подводя итог, Remote — это URL-адрес, который указывает на репозиторий в Интернете, а Origin — это псевдоним для этого удаленного URL-адреса.

Как клонировать конкретную ветку

Теперь давайте клонируем конкретную ветку из нашего демо-репозитория. Есть два способа клонировать конкретную ветку. Вы можете:

  • Клонируйте репозиторий, извлеките все ветки и немедленно извлеките определенную ветку.
  • Клонировать репозиторий и получить только одну ветвь.

Первый вариант

Здесь -b — это просто псевдоним для --branch

При этом вы получаете все ветки в репозитории, извлекаете из них ту, которую вы указали, и конкретная ветка становится настроенной локальной веткой для git push и git pull . Но вы все равно получили все файлы из каждой ветки. Это может быть не то, что вы хотите, верно? ?

Это автоматически настраивает беспарольную аутентификацию в качестве локальной ветки, но по-прежнему отслеживает другие ветки.

Второй вариант

Здесь -b — это просто псевдоним для --branch

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

Это автоматически настраивает аутентификацию без пароля как локальную ветвь и отслеживает только эту ветвь.

Если вы запустите cd pages/api, вы найдете файл auth.js в ветке аутентификации без пароля, как и ожидалось при предыдущей установке.

Заключение

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

Команда git clone –single-branch –branch клонирует определенную ветвь. Эта команда позволяет копировать содержимое репозитория, не загружая все ветки репозитория. Это полезно, если репозиторий большой и вы хотите загрузить только тот код, который будете использовать.

По умолчанию команда git clone дублирует все ветки из репозитория Git. Чтобы клонировать только определенную ветку, вы должны использовать флаг –single-branch с командой git commit.

В этом руководстве мы обсудим, как клонировать определенную ветку с помощью Git с помощью команды git clone. Мы рассмотрим пример, чтобы помочь вам закрепить ваши знания.

Что такое клонирование?

Клонирование позволяет сохранить копию репозитория, размещенного в другом месте, на локальном компьютере. Вы можете клонировать репозиторий с помощью команды git clone.

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

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

Git Клонировать определенную ветку

Команда git clone –single-branch –branch клонирует определенную ветку из репозитория Git. Укажите имя ветки, которую вы хотите клонировать, после команды –branch. Вы всегда можете загрузить любые другие ветки, которые вам нужны, после того, как вы клонировали репозиторий.

Вы можете ограничить ветки, извлекаемые командой clone, с помощью параметра –single-branch:

81 % участников заявили, что стали более уверенными в своих перспективах работы в сфере технологий после посещения учебного курса. Примите участие в тренировочном лагере сегодня.

Найдите подходящий вариант для буткемпа

В среднем выпускник буткемпа тратит менее шести месяцев на смену карьеры, начиная с буткемпа и заканчивая поиском своей первой работы.

Начните сменить профессию сегодня

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

Git клонирует определенную ветку: пример

У нас есть репозиторий ck-git. Этот репозиторий имеет две ветки: master и dev. Мы хотим получить только ветку master, потому что не планируем работать с веткой dev.

Чтобы получить только главную ветку, мы воспользуемся параметром –single-branch с командой git clone:

После флага –single-branch мы указали значение для флага –branch. Здесь мы сообщаем Git, какую ветку клонировать.Затем мы указываем URL репозитория, который хотим клонировать, как и с любой командой git clone.

Давайте посмотрим, что произойдет, когда мы запустим нашу команду:

Команда git clone скопировала репозиторий ck-git на наш локальный компьютер. Команда клонировала только ветку «master», потому что мы использовали флаг –single-branch.

Мы можем убедиться, что была клонирована только ветка «master», перейдя в папку нашего нового проекта и выполнив команду git branch:

В этом посте обсуждается, как клонировать определенную ветку Git.

1. git-удаленное добавление

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

В следующем примере сначала создается и инициализируется пустой репозиторий git. Затем он добавляет удаленный именованный источник для указанного репозитория и извлекает указанную ветвь из источника.


Команду git-fetch можно пропустить, если в git-remote переданы опции -t и -f. С параметром -f git fetch запускается сразу после настройки удаленной информации.

Это показано ниже:

2. git-клон

Самый распространенный подход к клонированию репозитория — использование git-clone . Вы можете передать флаг --single-branch, который предотвратит выборку всех веток в клонированном репозитории. С флагом --single-branch клонируется ветвь, указанная опцией --branch. Если ветвь не указана, клонируется главная ветвь.

Это показано ниже:


В качестве альтернативы вы можете указать параметр --depth, ограничивающий общее количество загружаемых коммитов до указанной глубины. По умолчанию подразумевается --single-branch.

Вот пример:

Это все, что касается клонирования конкретной ветки Git.

Средняя оценка 5/5. Количество голосов: 42

Пока нет голосов! Будьте первым, кто оценит этот пост.

Сожалеем, что этот пост не был вам полезен!

Расскажите, как мы можем улучшить этот пост?

Спасибо, что прочитали.

Нравится нам? Порекомендуйте нас своим друзьям и помогите нам расти. Удачного кодирования 🙂

Клонирует репозиторий во вновь созданный каталог, создает ветки для удаленного отслеживания для каждой ветки в клонированном репозитории (видимые с помощью git branch --remotes ), а также создает и извлекает начальную ветку, которая разветвляется из текущей ветки клонированного репозитория. активная ветвь.

После клонирования простой git fetch без аргументов обновит все ветки удаленного отслеживания, а git pull без аргументов дополнительно объединит удаленную главную ветку с текущей основной веткой, если таковая имеется (это неверно, когда " --single-branch"; см. ниже).

Эта конфигурация по умолчанию достигается путем создания ссылок на заголовки удаленных ветвей в refs/remotes/origin и инициализации переменных конфигурации remote.origin.url и remote.origin.fetch.

ВАРИАНТЫ

Если репозиторий для клонирования находится на локальном компьютере, этот флаг обходит обычный транспортный механизм с поддержкой Git и клонирует репозиторий, создавая копию HEAD и всего, что находится в каталогах объектов и ссылок. Файлы в каталоге .git/objects/ жестко связаны для экономии места, когда это возможно.

Если репозиторий указан как локальный путь (например, /path/to/repo ), это значение по умолчанию, а --local, по сути, не используется. Если репозиторий указан как URL, то этот флаг игнорируется (и мы никогда не используем локальные оптимизации). Указание --no-local переопределит значение по умолчанию, когда указан /path/to/repo, вместо этого будет использоваться обычный транспорт Git.

ПРИМЕЧАНИЕ: эта операция может выполняться одновременно с одновременным изменением исходного репозитория, аналогично запуску cp -r src dst при изменении src .

Заставьте процесс клонирования из репозитория в локальной файловой системе копировать файлы в каталог .git/objects вместо использования жестких ссылок. Это может быть желательно, если вы пытаетесь сделать резервную копию вашего репозитория.

Если репозиторий для клонирования находится на локальном компьютере, вместо использования жестких ссылок автоматически настройте .git/objects/info/alternates для совместного использования объектов с исходным репозиторием. Результирующий репозиторий запускается без какого-либо собственного объекта.

ПРИМЕЧАНИЕ: это потенциально опасная операция; не используйте его, если вы не понимаете, что он делает.Если вы клонируете свой репозиторий с помощью этой опции, а затем удаляете ветки (или используете любую другую команду Git, которая делает любую существующую фиксацию без ссылок) в исходном репозитории, некоторые объекты могут стать не имеющими ссылок (или зависшими). Эти объекты могут быть удалены обычными операциями Git (такими как git commit ), которые автоматически вызывают git Maintenance run --auto . (См. git-maintenance[1].) Если эти объекты будут удалены и на них ссылается клонированный репозиторий, клонированный репозиторий будет поврежден.

Обратите внимание, что запуск git repack без параметра --local в репозитории, клонированном с помощью --shared, скопирует объекты из исходного репозитория в пакет в клонированном репозитории, удалив экономию места на диске при клонировании --shared . Однако безопасно запускать git gc , который по умолчанию использует параметр --local.

Если вы хотите разорвать зависимость репозитория, клонированного с --shared, от его исходного репозитория, вы можете просто запустить git repack -a, чтобы скопировать все объекты из исходного репозитория в пакет в клонированном репозитории.

Если эталонный репозиторий находится на локальном компьютере, автоматически настройте .git/objects/info/alternates для получения объектов из эталонного репозитория. Использование уже существующего репозитория в качестве альтернативы потребует копирования меньшего количества объектов из клонируемого репозитория, что снизит затраты на сетевое и локальное хранилище. При использовании --reference-if-able несуществующий каталог пропускается с предупреждением вместо прерывания клонирования.

ПРИМЕЧАНИЕ: см. ПРИМЕЧАНИЕ для параметра --shared, а также для параметра --dissociate.

Заимствовать объекты из эталонных репозиториев, указанных с помощью параметров --reference, только для уменьшения передачи по сети и прекратить заимствование из них после создания клона путем создания необходимых локальных копий заимствованных объектов. Этот параметр также можно использовать при локальном клонировании из репозитория, который уже заимствует объекты из другого репозитория — новый репозиторий будет заимствовать объекты из того же репозитория, и этот параметр можно использовать для прекращения заимствования.

Работайте тихо. Ход выполнения не передается в стандартный поток ошибок.

Выполнить многословно. Не влияет на отчет о состоянии выполнения в стандартный поток ошибок.

Состояние выполнения сообщается в стандартном потоке ошибок по умолчанию, когда он подключен к терминалу, если не указан параметр --quiet. Этот флаг принудительно устанавливает состояние выполнения, даже если стандартный поток ошибок не направлен на терминал.

Передать данную строку на сервер при обмене данными по протоколу версии 2. Данная строка не должна содержать символы NUL или LF. Обработка сервером параметров сервера, включая неизвестные, зависит от сервера. Если задано несколько параметров --server-option=, все они отправляются другой стороне в порядке, указанном в командной строке.

После завершения клонирования извлечение HEAD не выполняется.

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

Создайте голый репозиторий Git. То есть вместо того, чтобы создавать и размещать административные файлы в /.git , сделайте сам $GIT_DIR . Это, очевидно, подразумевает --no-checkout, потому что негде проверить рабочее дерево. Кроме того, заголовки удаленных ветвей копируются непосредственно в соответствующие локальные заголовки ветвей, не сопоставляя их с refs/remotes/origin/ . При использовании этого параметра ни ветки удаленного отслеживания, ни связанные переменные конфигурации не создаются.

Используйте разреженное извлечение, при котором изначально присутствуют только файлы в каталоге верхнего уровня. Команду git-sparse-checkout[1] можно использовать для увеличения рабочего каталога по мере необходимости.

Используйте функцию частичного клонирования и запросите, чтобы сервер отправил подмножество доступных объектов в соответствии с заданным фильтром объектов. При использовании --filter поставляемый файл используется для фильтра частичного клонирования. Например, --filter=blob:none будет отфильтровывать все большие двоичные объекты (содержимое файла), пока они не потребуются Git. Кроме того, --filter=blob:limit= отфильтрует все большие двоичные объекты размером не менее . Дополнительные сведения о спецификациях фильтров см. в параметре --filter в git-rev-list[1].

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

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

Вместо того, чтобы указывать только что созданный HEAD на ветку, на которую указывает HEAD клонированного репозитория, вместо этого укажите на ветку. В не голом репозитории это ветка, которая будет извлечена.--branch также может принимать теги и отсоединять HEAD при этой фиксации в результирующем репозитории.

Если указано, и доступ к репозиторию для клонирования осуществляется через ssh, это указывает нестандартный путь для запуска команды на другом конце.

Укажите каталог, из которого будут использоваться шаблоны; (См. раздел «КАТАЛОГ ШАБЛОНОВ» в git-init[1].)

Установите переменную конфигурации во вновь созданном репозитории; это вступает в силу сразу после инициализации репозитория, но до извлечения удаленной истории или извлечения каких-либо файлов. Ключ имеет тот же формат, что и git-config[1] (например, core.eol=true ). Если для одного и того же ключа задано несколько значений, каждое значение будет записано в файл конфигурации. Это делает безопасным, например, добавление дополнительных спецификаций выборки к удаленному источнику.

Создайте поверхностный клон с историей, усеченной до указанного количества коммитов. Подразумевает --single-branch, если только --no-single-branch не задан для извлечения истории рядом с концами всех ветвей. Если вы хотите поверхностно клонировать подмодули, также передайте --shallow-submodules .

Создать неглубокий клон с историей после указанного времени.

Создайте неглубокий клон с историей, исключая коммиты, доступные из указанной удаленной ветки или тега. Этот параметр можно указать несколько раз.

Клонировать только историю, ведущую к вершине одной ветки, указанной либо параметром --branch, либо основной удаленной ветки, на которую указывает HEAD. Дальнейшие выборки в результирующий репозиторий будут обновлять только ветку удаленного отслеживания для ветки, которая использовалась для первоначального клонирования. Если HEAD на удаленном сервере не указывает ни на одну ветку при создании клона --single-branch, ветка удаленного отслеживания не создается.

Не клонируйте никакие теги и установите в конфигурации remote..tagOpt=--no-tags, чтобы гарантировать, что будущие операции git pull и git fetch не будут следовать никаким тегам. Последующие явные выборки тегов по-прежнему будут работать (см. git-fetch[1]).

Может использоваться в сочетании с --single-branch для клонирования и поддержки ветки без каких-либо ссылок, кроме одной клонированной ветки. Это полезно, например. поддерживать минимальные клоны ветки по умолчанию какого-либо репозитория для индексации поиска.

После создания клона инициализируйте и клонируйте подмодули в нем на основе предоставленного пути. Если путь не указан, все подмодули инициализируются и клонируются. Эта опция может быть указана несколько раз для путей, состоящих из нескольких записей. Полученный клон имеет submodule.active, установленный на указанный путь или "." (имеется в виду все подмодули), если путь не указан.

Подмодули инициализируются и клонируются с использованием настроек по умолчанию. Это эквивалентно запуску git submodule update --init --recursive сразу после завершения клонирования. Этот параметр игнорируется, если в клонированном репозитории нет рабочего дерева/проверки (т. е. если задан любой из --no-checkout / -n , --bare или --mirror)

Все клонированные подмодули будут мелкими с глубиной 1.

Все клонированные подмодули будут использовать статус ветки удаленного отслеживания подмодуля для обновления подмодуля, а не записанный SHA-1 суперпроекта. Эквивалентно передаче --remote в git submodule update .

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

Количество подмодулей, получаемых одновременно. По умолчанию используется параметр submodule.fetchJobs.

Репозиторий (возможно, удаленный) для клонирования. Дополнительные сведения об указании репозиториев см. в разделе URL-адреса GIT ниже.

Имя нового каталога для клонирования. «Человеческая» часть исходного репозитория используется, если явно не указан каталог ( repo для /path/to/repo.git и foo для host.xz:foo/.git ). Клонирование в существующий каталог разрешено только в том случае, если каталог пуст.

URL-адреса GIT

Как правило, URL-адреса содержат информацию о транспортном протоколе, адрес удаленного сервера и путь к репозиторию. В зависимости от транспортного протокола часть этой информации может отсутствовать.

Собственный транспорт (например, URL-адрес git://) не выполняет аутентификацию и должен использоваться с осторожностью в незащищенных сетях.

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