Git mirror что это
To maintain a mirror of a repository without forking it, you can run a special clone command, then mirror-push to the new repository.
Note: If you have a project hosted on another version control system, you can automatically import your project to GitHub using the GitHub Importer tool. For more information, see "About GitHub Importer."
Before you can push the original repository to your new copy, or mirror, of the repository, you must create the new repository on GitHub. In these examples, exampleuser/new-repository or exampleuser/mirrored are the mirrors.
Mirroring a repository
- Open Terminal Terminal Git Bash .
- Create a bare clone of the repository.
- Mirror-push to the new repository.
- Remove the temporary local repository you created earlier.
Mirroring a repository that contains Git Large File Storage objects
- Open Terminal Terminal Git Bash .
- Create a bare clone of the repository. Replace the example username with the name of the person or organization who owns the repository, and replace the example repository name with the name of the repository you'd like to duplicate.
- Navigate to the repository you just cloned.
- Pull in the repository's Git Large File Storage objects.
- Mirror-push to the new repository.
- Push the repository's Git Large File Storage objects to your mirror.
- Remove the temporary local repository you created earlier.
Mirroring a repository in another location
If you want to mirror a repository in another location, including getting updates from the original, you can clone a mirror and periodically push the changes.
- Open Terminal Terminal Git Bash .
- Create a bare mirrored clone of the repository.
- Set the push location to your mirror.
As with a bare clone, a mirrored clone includes all remote branches and tags, but all local references will be overwritten each time you fetch, so it will always be the same as the original repository. Setting the URL for pushes simplifies pushing to your mirror. To update your mirror, fetch updates and push.
Варианты конфигурации
git clone -branch
Аргумент -branch позволяет выбрать ветку для клонирования. В противном случае будет клонирована ветка, на которую указывает HEAD в удаленном репозитории (обычно это главная ветка). Кроме того, для этих целей в команде можно задать тег вместо ветки.
В примере выше клонируется только ветка new_feature из удаленного репозитория Git. Эта опция нужна исключительно для удобства, чтобы не тратить время на получение ссылки HEAD в репозитории и извлечение необходимой ссылки.
Сравнение команд git clone -mirror и git clone -bare
git clone --bare
Как и git init --bare, аргумент -bare при назначении команде git clone приводит к созданию копии удаленного репозитория без рабочего каталога. Это означает, что репозиторий будет содержать историю проекта, к которой можно выполнять запросы push и pull, но которую нельзя редактировать напрямую. Кроме того, в репозитории, клонированном с опцией -bare , не будут настроены удаленные ветки. Как и git init --bare , эта команда создает удаленный репозиторий, который разработчики не смогут редактировать напрямую.
git clone --mirror
Вместе с аргументом --mirror команде неявно назначается и аргумент --bare . Поэтому можно сказать, что опция --mirror наследует поведение --bare , создавая чистый репозиторий без изменяемых рабочих файлов. Кроме того, --mirror клонирует ссылки удаленного репозитория и сохраняет конфигурацию отслеживания удаленных веток. Затем вы можете выполнить команду git remote update на созданном зеркале, в результате чего будут перезаписаны все ссылки из исходного репозитория. Так вы получите идентичные функциональные возможности для работы.
Другие варианты конфигурации
Исчерпывающий список опций git clone приведен в официальной документации по Git. В этом документе будут рассмотрены в том числе и другие распространенные опции.
git clone --template
Команда клонирует репозиторий, расположенный в , и применяет шаблон из каталога к созданной локальной ветке. Подробные сведения о шаблонах Git см. на странице команды git init.
В чем разница между git clone -- mirror и git clone --bare
страница справки git clone имеет это сказать о --mirror :
настройка зеркала удаленного репозитория. Это подразумевает --bare .
но не вдается в подробности о том, как --mirror клон отличается от --bare клон.
разница в том, что при использовании --mirror , все ссылки скопировать как есть. Это означает все: удаленные ветви отслеживания, заметки, ссылки / оригиналы/* (резервные копии из filter-branch). У клонированного РЕПО есть все. Он также настроен так, что удаленное обновление будет повторно извлекать все из источника (перезапись скопированных ссылок). Идея заключается в том, чтобы отразить репозиторий, иметь полную копию, чтобы вы могли, например, разместить свое центральное РЕПО в нескольких по местам или назад. Подумайте только о прямом копировании РЕПО, за исключением гораздо более элегантного способа git.
новая документация в значительной степени говорит все это:
--mirror
настройка зеркала исходного репозитория. Это подразумевает --bare . По сравнению с --bare , --mirror не только отображает локальные ветви источника в локальные ветви цели, он отображает все ссылки (включая удаленные ветви, заметки и т. д.) и устанавливает конфигурация refspec такая, что все эти ссылки перезаписываются git remote update в целевом хранилище.
мой первоначальный ответ также отметил различия между голым клоном и обычным (не голым) клоном - не-голый клон настраивает удаленные ветви отслеживания, создавая только локальную ветвь для HEAD , в то время как голый клон копирует ветви напрямую.
предположим, что origin имеет несколько ветвей ( master (HEAD) , next , pu и maint ), некоторые теги ( v1 , v2 , v3 ), некоторые удаленные филиалы ( devA/master , devB/master ), и некоторые другие рефы ( refs/foo/bar , refs/foo/baz , которые могут быть заметками, тайниками, пространствами имен других разработчиков, кто знает).
git clone origin-url (не голый): вы получите все теги скопированы, локальная ветвь master (HEAD) отслеживание удаленной ветки origin/master , и удаленных филиалов origin/next , origin/pu и origin/maint . Ветви отслеживания настроены так, что если вы сделаете что-то вроде git fetch origin они будут как вы и ожидали. Любые удаленные ветви (в клонированном удаленном) и другие ссылки полностью игнорируются.
git clone --bare origin-url : вы получите все теги скопированы, локальные ветви master (HEAD) , next , pu и maint , отсутствие дистанционных отслеживая ветвей. То есть, все ветви копируются "как есть", и он полностью независимым, без ожидания снова привлекательной. Любые удаленные ветви (в клонированном удаленном) и другие ссылки полностью игнорируемый.
git clone --mirror origin-url : каждый последний из этих ссылок будет скопирован как есть. Вы получите все теги, локальные ветви master (HEAD) , next , pu и maint , удаленными филиалами devA/master и devB/master , других ссылок refs/foo/bar и refs/foo/baz . Все точно так же, как было в клонированном пульте. Удаленное отслеживание настроено так, что если вы запустите git remote update все рефы будут перезаписаны из Origin, как если бы ты просто удалил зеркало и recloned его. Как документы первоначально сказал, это зеркало. Предполагается, что это функционально идентичная копия, взаимозаменяемая с оригиналом.
- это сокращение для
(скопировано непосредственно из здесь)
как текущий man-page ставит его:
по сравнению с --bare , --mirror не только отображает локальные ветви источника в локальные ветви цели, он отображает все ссылки (включая удаленные ветви, заметки и т. д.) и настраивает конфигурацию refspec таким образом, что все эти ссылки перезаписываются git remote update в целевом хранилище.
мои тесты с git-2.0.0 сегодня показывают, что параметр --mirror не копирует крючки, файл конфигурации, файл описания, файл info/exclude и, по крайней мере, в моем тестовом случае несколько ссылок (которые я не понимаю.) Я бы не назвал его "функционально идентичной копией, взаимозаменяемой с оригиналом"."
клон копирует ссылки с пульта ДУ и загружает их в подкаталог с именем "это ссылки, которые есть у пульта ДУ".
зеркало копирует ссылки с пульта и помещает их в собственный верхний уровень - он заменяет свои ссылки с пульта.
Это означает, что когда кто-то вытаскивает из вашего зеркала и запихивает refs зеркала в свой подкаталог, они получат те же refs, что и в оригинале. Результат извлечения из современное зеркало-это то же самое, что и извлечение непосредственно из начального РЕПО.
подробное объяснение из документации GitHub на дублирование репозитория:
как и с голым клоном, зеркальный клон включает в себя все удаленные ветви и теги, но все локальные ссылки будут перезаписываться каждый раз, когда вы получаете, поэтому он всегда будет таким же, как и исходный репозиторий.
добавляю картинку, показываю config разницу между зеркалом и голой. Левая голая, правая-зеркальная. Вы можете быть ясны, конфигурационный файл mirror имеет fetch ключ, что означает, что вы можете обновить его, по git remote update или git fetch --all
Резюме
В этом документе мы подробно изучили команду git clone . Ниже перечислены основные моменты:
1. Команда git clone предназначена для создания копии целевого репозитория.
2. Целевой репозиторий может находиться в локальной системе или на удаленном устройстве.
3. Git поддерживает несколько сетевых протоколов для установки соединения с удаленными репозиториями.
4. Существует множество вариантов конфигурации команды, которые позволяют изменять содержание копии.
Подробные сведения о возможностях git clone см. в официальной документации по Git. Примеры использования команды git clone на практике также можно найти в нашем руководстве по настройке репозитория.
git clone
В этой статье подробно рассматривается команда git clone . git clone — это утилита командной строки Git для выбора существующего репозитория и создания его клона, т. е. копии. На этой странице описаны варианты расширенной конфигурации и распространенные примеры использования команды git clone . Будут рассмотрены следующие вопросы:
- Клонирование локального или удаленного репозитория.
- Клонирование чистого репозитория.
- Поверхностное клонирование — частичное клонирование репозиториев.
- Синтаксис URL-адресов и поддерживаемые протоколы Git.
В руководстве по настройке репозитория мы рассмотрели пример классического использования команды git clone . На этой странице приводятся более сложные сценарии клонирования и конфигурации.
Полностью сделать резервную копию git-репо?
Есть ли простой способ сделать резервную копию всего репозитория git, включая все ветви и теги?
Я предполагаю, что вы ссылаетесь на местные репозитории git здесь. Некоторые поисковые запросы, которые я проводил, не включали этот вопрос в свои результаты: "git clone абсолютно все разветвляет теги заметки"; "git clone все в хранилище"; msgstr "сделать клон репо со всеми заметками тэгов".Как насчет просто сделать его клоном?
Каждый репозиторий является резервной копией своего удаленного.
@Daniel: если вы клонируете репозиторий, вы выбираете каждую ветку, но отмечается только одна ветка по умолчанию. Попробуй git branch -a . Возможно, это более очевидно: после клонирования репозитория вы не получаете каждую ветку, вы получаете каждый коммит. Ветви только ссылаются на существующий коммит. Я думаю, что он хорошо знает команду клонирования, если он может задать такой вопрос, и ему явно недостаточно (потому что это клон, а не дамп). Дампы - это разные вещи в виде простых копий, например: 1) они не нужны для того, чтобы быть оптимальными (или даже способными) для нормальной работы 2) но они должны иметь хорошую устойчивость и защиту от повреждения данных. @peterh Конечно, но git clone охватывает все это. (1) не является обязательным, не является обязательным требованием. Если результат все еще оптимизирован, это все еще резервная копия (2), уже покрытая самим git. - Смысл, который я хотел бы сказать, состоит в том, что, если git clone уже охватываются соответствующие пункты, для чего вам нужен другой инструмент? Хотя я также предпочитаю, git bundle я не думаю, что мой ответ неверен или недействителен. Вы можете рассматривать оба подхода как горячее резервное копирование. как насчет прав доступа к файлам? git clone обязательно копирует их? зависит от вариантов, я верюМне нравится этот метод, так как в результате получается всего один файл, который легче копировать.
Смотрите ProGit: маленький пучок радости .
Смотрите также « Как я могу послать кому-нибудь письмо с git-репозиторием? », Где команда
git bundle будет упаковывать только те ссылки, которые отображаются в git show-ref : сюда входят заголовки, теги и удаленные заголовки.
Очень важно, чтобы используемая основа удерживалась пунктом назначения.
Можно допустить ошибку, если в файле пакета содержатся объекты, уже находящиеся в месте назначения, так как они игнорируются при распаковке в месте назначения.
Для использования этого пакета вы можете клонировать его, указав несуществующую папку (вне любого git-репо):
Это git bundle правильный ответ на мой взгляд, а не принятый. Я думаю, что он хорошо знает команду клонирования, если он может задать такой вопрос, и ему явно недостаточно (потому что это клон, а не дамп). Дампы - это разные вещи, такие как простые копии, например: 1) они не нужны для того, чтобы быть оптимальными (или даже способными) для нормальной работы 2) но они должны обладать хорошей устойчивостью и устойчивостью к повреждению данных 3) это часто полезно если они легко различимы для инкрементных резервных копий, тогда как это не является целью для копий. Обратите внимание , что ни один git bundle или git clone получает все , например сценарии крючка. @Zitrax Да, это так. Крючки могут быть опасными или содержать конфиденциальную информацию. Могу ли я использовать git bundle против удаленного репо?Развивая некоторые другие ответы, это то, что я делаю:
Настройте репо: git clone --mirror user@server:/url-to-repo.git
Затем, когда вы хотите обновить резервную копию: git remote update из местоположения клона.
Это создает резервные копии всех веток и тегов, в том числе новых, которые добавляются позже, хотя стоит отметить, что удаляемые ветви не удаляются из клона (что для резервной копии может быть полезным).
Это атомарно, поэтому не имеет проблем, которые могут возникнуть у простой копии.
Расширяя великолепные ответы KingCrunch и VonC
Я объединил их обоих:
После этого у вас есть файл, reponame.bundle который можно легко скопировать. Затем вы можете создать новый нормальный git-репозиторий, используя это git clone reponame.bundle reponame .
Обратите внимание, что git bundle копируются только коммиты, которые приводят к некоторой ссылке (ветви или тегу) в хранилище. Таким образом, запутанные коммиты не сохраняются в связке.
Я думаю ты имел ввиду git bundle create reponame.bundle --all ? Спасибо @joe за то, что заметил. Определенно. Я обновлю ответ.Все содержится в .git каталоге. Просто сохраните это вместе с вашим проектом, как любой файл.
Означает ли это, что достаточно просто выполнить резервное копирование ВСЕХ содержимого каталога, содержащего проект Git? Договорились с Сунил - это не похоже на атомную операцию. И как вы гарантируете, что не будут внесены изменения в файлы в этом каталоге при создании резервной копии? Как подсказал Райдвальд, этот метод может привести к непоследовательному резервному копированию и, следовательно, к потере данных. Следовательно, этот ответ следует удалить или, по крайней мере, предупредить о возможности потери данных. Я думаю, что он хорошо знает команды copy или, cp и это не соответствует его потребностям. И я также думаю, что он думает о пустом хранилище (хотя его также можно скопировать, я думаю, что это не полнофункциональная резервная копия).использовать git bundle или клонировать
копирование каталога git не является хорошим решением, поскольку оно не является атомарным. Если у вас большой репозиторий, копирование которого занимает много времени, и кто-то отправляет его в ваш репозиторий, это повлияет на резервное копирование. Клонирование или создание пакета не будет иметь этой проблемы.
Вы можете сделать резервную копию git-репозитория с помощью git-copy с минимальным объемом хранилища.
Затем вы можете восстановить свой проект с git clone
@VonC Да, но у него может быть какая-то дополнительная функция во время переупаковки, или он может анализировать внутреннюю структуру git-репо, которую он может использовать для некоторой оптимизации (реструктуризация места назначения, увеличение скорости и т. Д.).Правильный ответ IMO - git clone --mirror . Это полностью сделает резервную копию вашего репо.
Git clone mirror клонирует весь репозиторий, заметки, заголовки, ссылки и т. Д. И обычно используется для копирования всего репозитория на новый git-сервер. Это уничтожит все ветки и все, весь репозиторий.
Обычно клонирование репо не включает все ветви, только Мастер.
Копирование папки репо будет «копировать» только те ветки, которые были извлечены . поэтому по умолчанию это только основная ветка или другие ветви, которые вы извлекли ранее.
Создает ли git clone --mirror согласованную резервную копию на определенный момент времени? Что пользователь нажимает на коммит во время резервного копирования? Это отклонено, поставлено в очередь или включено в резервную копию?Этот поток был очень полезен, чтобы получить некоторое представление о том, как можно создавать резервные копии git-репозиториев. Я думаю, что все еще не хватает некоторых подсказок, информации или заключения, чтобы найти «правильный путь» (тм) для себя. Поэтому делюсь своими мыслями здесь, чтобы помочь другим, и выставлять их на обсуждение, чтобы улучшить их. Спасибо.
Итак, начнем с подбора исходного вопроса:
- Цель состоит в том, чтобы максимально приблизиться к «полной» резервной копии репозитория git.
Затем обогатить его типичными пожеланиями и указать некоторые предварительные настройки:
- Резервное копирование через «горячее копирование» является предпочтительным, чтобы избежать простоев службы.
- Недостатки git будут обходиться дополнительными командами.
- Сценарий должен выполнять резервное копирование, чтобы объединить несколько шагов в одну резервную копию и избежать ошибок человека (опечаток и т. Д.).
- Кроме того, сценарий должен выполнить восстановление, чтобы адаптировать дамп к целевому компьютеру, например, даже конфигурация исходного компьютера могла измениться после резервного копирования.
- Среда - это git-сервер на компьютере с Linux, файловая система которого поддерживает жесткие ссылки.
Назначение: создание копии проекта для совместной работы в разных репозиториях
Если проект уже был настроен в центральном репозитории, для создания его копии чаще всего используется команда git clone . Клонирование, как и команда git init , обычно выполняется один раз. После того как разработчик получил рабочую копию, все операции контроля версий и совместная работа осуществляются уже из локального репозитория.
Совместная работа в разных репозиториях
Важно понимать, что рабочая копия в Git существенно отличается от рабочей копии, получаемой при загрузке исходного кода из репозитория SVN. В отличие от SVN, в Git нет разницы между рабочими копиями и центральным репозиторием — все они являются полноценными репозиториями Git.
Поэтому совместная работа в Git принципиально отличается от совместной работы в SVN. В SVN работа строится на отношении между центральным репозиторием и рабочей копией, а модель совместной работы в Git основана на взаимодействии между репозиториями. Вместо загрузки рабочей копии в центральный репозиторий SVN в Git вы отправляете коммиты из одного репозитория в другой с помощью команды push или копируете их в обратном направлении с помощью команды pull.
Вы легко можете задавать особую роль определенным репозиториям Git. Например, обозначив один из репозиториев Git как «центральный», вы можете воспроизвести централизованный рабочий процесс с использованием Git. Однако такой подход требует договоренностей, поскольку он не встроен в саму систему контроля версий
1. Что такое «полная» резервная копия git-репо?
Точка зрения отличается от того, что такое «100%» резервное копирование. Вот два типичных.
git - инструмент для разработчиков и поддерживает эту точку зрения через git clone --mirror и git bundle --all .
git - инструмент для разработчиков, и оставляет это администратору. Резервное копирование конфигурации git и конфигурации ОС следует рассматривать как отдельное от резервного копирования содержимого.
2. Техника
- "Cold-Copy"
- Остановите службу, чтобы иметь эксклюзивный доступ к ее файлам. Простои!
- Сервис предоставляет фиксированное состояние для целей резервного копирования. Текущие изменения не влияют на это состояние.
3. Другие темы для размышления
Большинство из них являются общими для резервных копий.
- Достаточно ли места для хранения полных резервных копий? Сколько поколений будет храниться?
- Требуется ли поэтапный подход? Сколько поколений будет храниться и когда снова создавать полную резервную копию?
- Как проверить, что резервная копия не повреждена после создания или со временем?
- Поддерживает ли файловая система жесткие ссылки?
- Поместить резервную копию в один архивный файл или использовать структуру каталогов?
4. Что Git предоставляет для резервного копирования контента
- документы: man git-gc
- Очищает и сжимает репозиторий.
- документы: man git-bundle, man git-rev-list
- Atomic = "Hot-Copy"
- Пакеты являются файлами дампа и могут использоваться напрямую с git (проверить, клонировать и т. Д.).
- Поддерживает пошаговое извлечение.
- Проверяется через git bundle verify .
git clone --mirror
- документы: man git-clone, man git-fsck, в чем разница между git clone --mirror и git clone --bare
- Atomic = "Hot-Copy"
- Зеркала - это настоящие git-репозитории.
- Основное назначение этой команды - создать полное активное зеркало, которое периодически получает обновления из исходного хранилища.
- Поддерживает жесткие ссылки для зеркал в той же файловой системе, чтобы избежать потери места.
- Проверяется через git fsck .
- Зеркала можно использовать как основу для полного резервного копирования файлов.
5. Холодная копия
Резервное копирование в режиме холодного копирования всегда может сделать полное резервное копирование файла: запретить все обращения к репозиториям git, сделать резервное копирование и разрешить доступ снова.
Использование
Чаще всего с помощью команды git clone выбирается существующий репозиторий и создается его клон или копия. Это делается в новом каталоге и в другом месте. Исходный репозиторий может находиться в локальной файловой системе или на удаленном устройстве, к которому можно получить доступ с помощью поддерживаемых протоколов. Команда git clone копирует существующий репозиторий Git. Она похожа на команду SVN checkout, но имеет некоторые отличия: так, полученная «рабочая копия» представляет собой полноценный репозиторий Git с собственной историей и файлами, полностью обособленный от исходного репозитория.
Для удобства в процессе клонирования автоматически создается удаленный доступ к исходному репозиторию (такое соединение называется origin). Это упрощает взаимодействие с центральным репозиторием. Автоматическое соединение обеспечивается за счет создания ссылок Git на концы удаленных веток в каталоге refs/remotes/origin , а также инициализации переменных конфигурации remote.origin.url и remote.origin.fetch .
Первая команда инициализирует новый репозиторий Git в каталоге my-project на локальной машине и наполняет его содержимым центрального репозитория. Теперь вы можете перейти в проект и приступить к редактированию файлов, созданию снимков состояния и взаимодействию с другими репозиториями. Обратите внимание, что расширение .git у клонированного репозитория отсутствует. Это означает, что у локальной копии есть рабочий каталог.
Клонирование в конкретную папку
Клонирование репозитория из в директорию
! на локальной машине.
Клонирование конкретного тега
Клонирование репозитория из и клонирование только ссылки на .
Поверхностное клонирование
Эта команда клонирует репозиторий, расположенный в , при этом количество коммитов в копируемой
истории определяется опцией depth=1. В примере создается клон , и в него включается только последний коммит. Поверхностное клонирование особенно эффективно, когда вы работаете с репозиториями с объемной историей коммитов. Объемная история коммитов может привести к появлению проблем с масштабированием в виде ограничений на использование дискового пространства и чрезмерной продолжительности операции клонирования. Поверхностное клонирование помогает устранить эти проблемы.URL-адреса в Git
В Git используется особый синтаксис URL-адресов, с помощью которого в команде можно задать расположение удаленных репозиториев. Поскольку команда git clone чаще всего используется в работе с удаленными репозиториями, здесь будет рассмотрен синтаксис URL-адресов в Git.
URL-протоколы в Git
-SSH
Secure Shell (SSH) — это популярный сетевой протокол, обеспечивающий защищенную аутентификацию. Большинство серверов настроены для работы с ним по умолчанию. Из-за специфики протокола для входа на центральный сервер вам нужно знать учетные данные. ssh://[user@]host.xz[:port]/path/to/repo.git/
- GIT
Уникальный протокол Git. Вместе с Git поставляется специальный демон, который использует отдельный порт (9418). Этот протокол похож на SSH, однако GIT НЕ ОБЛАДАЕТ средствами аутентификации. git://host.xz[:port]/path/to/repo.git/
6. Hot-Copy
Резервное копирование файлов не может быть выполнено с активными репозиториями из-за риска повреждения данных при текущих фиксациях. Оперативное копирование обеспечивает фиксированное состояние активного хранилища для целей резервного копирования. Текущие коммиты не влияют на эту копию. Как указано выше, git поддерживает функции клонирования и связки, но для резервного копирования «100% admin» необходимо выполнить несколько действий с помощью дополнительных команд.
Читайте также: