git clone
Назначение: создание копии проекта для совместной работы в разных репозиториях
Совместная работа в разных репозиториях
Важно понимать, что рабочая копия в Git существенно отличается от рабочей копии, получаемой при загрузке исходного кода из репозитория SVN. В отличие от SVN, в Git нет разницы между рабочими копиями и центральным репозиторием — все они являются полноценными репозиториями Git.
Поэтому совместная работа в Git принципиально отличается от совместной работы в SVN. В SVN работа строится на отношении между центральным репозиторием и рабочей копией, а модель совместной работы в Git основана на взаимодействии между репозиториями. Вместо загрузки рабочей копии в центральный репозиторий SVN в Git вы отправляете коммиты из одного репозитория в другой с помощью команды push или копируете их в обратном направлении с помощью команды pull.
Вы легко можете задавать особую роль определенным репозиториям Git. Например, обозначив один из репозиториев Git как «центральный», вы можете воспроизвести централизованный рабочий процесс с использованием Git. Однако такой подход требует договоренностей, поскольку он не встроен в саму систему контроля версий
Использование
Чаще всего с помощью команды git clone выбирается существующий репозиторий и создается его клон или копия. Это делается в новом каталоге и в другом месте. Исходный репозиторий может находиться в локальной файловой системе или на удаленном устройстве, к которому можно получить доступ с помощью поддерживаемых протоколов. Команда git clone копирует существующий репозиторий Git. Она похожа на команду SVN checkout, но имеет некоторые отличия: так, полученная «рабочая копия» представляет собой полноценный репозиторий Git с собственной историей и файлами, полностью обособленный от исходного репозитория.
Клонирование в конкретную папку
Клонирование репозитория из в директорию
! на локальной машине.
Клонирование конкретного тега
Поверхностное клонирование
Варианты конфигурации
В примере выше клонируется только ветка new_feature из удаленного репозитория Git. Эта опция нужна исключительно для удобства, чтобы не тратить время на получение ссылки HEAD в репозитории и извлечение необходимой ссылки.
Другие варианты конфигурации
Исчерпывающий список опций git clone приведен в официальной документации по Git. В этом документе будут рассмотрены в том числе и другие распространенные опции.
URL-адреса в Git
В Git используется особый синтаксис URL-адресов, с помощью которого в команде можно задать расположение удаленных репозиториев. Поскольку команда git clone чаще всего используется в работе с удаленными репозиториями, здесь будет рассмотрен синтаксис URL-адресов в Git.
URL-протоколы в Git
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/
— HTTP
Протокол для передачи гипертекста. Этот протокол повсеместно используется во Всемирной паутине. Чаще всего применяется для передачи данных веб-страниц в формате HTML через Интернет. Git можно настроить для работы по HTTP. http[s]://host.xz[:port]/path/to/repo.git/
Резюме
1. Команда git clone предназначена для создания копии целевого репозитория.
2. Целевой репозиторий может находиться в локальной системе или на удаленном устройстве.
3. Git поддерживает несколько сетевых протоколов для установки соединения с удаленными репозиториями.
4. Существует множество вариантов конфигурации команды, которые позволяют изменять содержание копии.
Подробные сведения о возможностях git clone см. в официальной документации по Git. Примеры использования команды git clone на практике также можно найти в нашем руководстве по настройке репозитория.
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
Для чего нужен флаг bare
1 ответ 1
совсем короткая формулировка
вот вам надо, допустим, скопировать архив с одного сервера на другой, и вам дают инструкцию:
более обстоятельный ответ
начать надо, пожалуй, с иллюстрации того, что, собственно, представляет собой git-хранилище (часто используется термин «git-репозиторий»).
вот оно, свежесозданное хранилище, не отслеживающее (пока) ни одного файла, но уже содержащее 9 каталогов и 13 файлов (в разных версиях и сборках программы git конкретные цифры могут, конечно, слегка отличаться), необходимый минимум, который позволит программе git начать отслеживание файлов вашего проекта (ну, почти необходимый — без файлов с примерами из каталога hooks можно было бы и обойтись):
эти файлы и каталоги появятся в текущем (изначально пустом) каталоге после выполнения команды:
«спрятаны» они будут не только «для эстетики» и не только потому, что эти «внутренние потроха» для «обычного» пользователя программы git представляют мало интереса. основная цель — «освободить» текущий каталог под собственно файлы (и каталоги) вашего проекта. в этом случае он (текущий каталог) будет выполнять функции рабочего каталога (working tree в оригинальной документации, другой нередко встречающийся перевод — рабочая копия).
если при хранилище имеется рабочий каталог, то такое хранилище называют «не-bare-хранилищем», или «хранилищем с рабочим каталогом», а чаще, для краткости — просто «хранилищем». а если рабочего каталога нет, то такое хранилище называют «bare-хранилищем» (дословно — «голым»).
а какая польза от такого «bare-хранилища»? какой практический смысл в нём? что с ним можно сделать?
ну, с точки зрения «конечного» пользователя (чаще всего — программиста) пользы, действительно, мало, ведь не видно же файлов/каталогов проекта. а вот с точки зрения программы git — это полноценное хранилище, которое можно клонировать, делать из него pull-ы, а в него — push-ы. именно в таком виде (без рабочего каталога) располагаются хранилища на таких серверах, как github.com, bitbucket.org и тому подобных. программа git легко может извлечь и отобразить любую информацию из такого хранилища: историю коммитов, листинг файлов проекта, содержимое любого из файлов проекта в том состоянии, как он выглядел после любого из коммитов, и так далее и тому подобное.
ах, да, совсем забыл:
Git: документация – часть 1: создание репозитория
Перевод замечательной документации от Atlassian.
Так же – есть отличный ресурс на русском тут>>>, в котором более детально рассматриваются вопросы, связанные с внутренней структурой Git.
В этой документации будут рассмотрены основные команды Git. В первой части – “Создание репозитория” – описаны утилиты, необходимые для начала работы с новым проектом под контролем Git.
git init
Команда git init создаёт новый репозиторий. Её можно использовать для превращения уже существующего проекта в Git-репозиторий – или для создания нового. Большинство других команд Git не смогут работать вне проинициализированного репозитория, поэтому как правило – это первая команда при запуске нового проекта.
Использование
Обсуждение
По сравнению с SVN – команда git init предоставляет очень простой способ создания нового проекта под контролем системы VSC (Version Control System). Git не требует от вас создания репозитория, импорта файлов и загрузки рабочей копии. Всё, что вам надо сделать – это перейти в каталог вашего проекта и выполнить git init – вы сразу получите полнофункциональный репозиторий Git.
Однако, во многих проектах git init требуется выполнить только для центрально репозитория – разработчики как правило не используют git init для создания локальных репозиториев. Вместо этого – они используют git clone для копирования имеющего репозитория на их локальные рабочие станции.
Неизолированные репозитории
Пример
Так как самым подходящим способом создания локальной копии проекта является git clone – то git init обычно использутеся для создания центрального репозитория:
git clone
Использование
Клонирует репозиторий, расположенный по пути на локальную машину. может быть расположен как на локальной файловой системе – так и на удалённом сервере, с доступом по HTTP(S) или SSH.
Обуждение
Если проект уже создан в центральном репозитории – git clone наиболее распространённый способ для пользователей получить свою рабочую копию этого проекта. Как и git init – git clone обычно выполняется один раз – после того как разработчик получил своб копию проекта все операции по контролю версий и совместная работа выполняются в локальном репозитории.
Свзять репозиторий-к-репозиторию (repo-to-repo)
Важно понимать, что смысл понятия “рабочая копия” у Git очень отличается от рабочий копии, которую вы получаете после загрузки кода из SVN. В отличии от SVN – Git не делает различий между рабочией копией кода и кодом в центральном репозитории – оба являются полноценными репозиториями Git.
Это делает работу с Git принципиально отличной от работы с SVN. В то время как SVN зависит от отношений между центральным репозиторием и рабочей копией – модель отношений в Git базируется на связи репозиторий-к-репозиторию. Вместо того, что бы загружать рабочую копию в центральный репозиторий SVN – вы загружаете в или из одного репозитория в другой.
Конечно, ничто не мешает назначить некоторым репозиториям Git особую роль. Например, просто указав один репозиторий как “центральный” – вы можете вести всю работу над кодом вокруг одного хранилища. Смысл тут заключается в том, что вы сами можете решать этот вопрос – а не зависеть от решений, ограниченных VCS.
Пример
Пример ниже дмеонстрирует, как получить копию данных из центрального репозитория, который хранится на сервере с именем example.com с помощью SSH и используя имя пользователя john:
git config
Команда git config позволяет вам настроить ваш Git (или отдельный репозиторий) из командной строки. С помощью неё можно определить все – от информации о пользователи до настроек поведения репозитория. Ниже показано нескорлько наиболее используемых настроек.
Использование
Определяет почтовый адрес автора для его коммитов.
Создаёт короткое имя для команды Git.
Определяет тектовый редактор, который будет использоваться такими командами как git commit для всех пользователей на этой машине. Аргумент должен быть именем исполняемого файла, который запускает желаемый редактор (например – vi ).
Открывает основной конфигурационный файл для ручного редактированияю
Обуждение
Git хранит опции в трёх различных файлах, что позволяет вам разделить опции для отдельных репозиториев, пользователей и всей системы:
В случае конфликтов – локальные настройки имеюти преимущество над настройками пользователя, а настройки пользователя – над общесистемными. Если вы откроете любой из этих файлов – вы увидите что-то вроде такого:
Пример
Первое, что вы можете захотеть сделать после установки Git – это определить ваше имя и почтовый ящик, а так же задать некоторые значения по умолчанию. Обычная конфигурация может выглядеть так:
Bare Repositories in Git
What is a Non-bare repository?
A non-bare or default git repository has a .git folder, which is the backbone of the repository where all the important files for tracking the changes in the folders are stored. It stores the hashes of commits made in the branches and a file where the hash of the latest commit is stored.
The file structure of the default repository should look something like this:
As you can see, the .git folder contains all the required files for tracking the project folder. The default repository is always used for local repositories.
What is a bare repository?
A bare repository is the same as default, but no commits can be made in a bare repository. The changes made in projects cannot be tracked by a bare repository as it doesn’t have a working tree. A working tree is a directory in which all the project files/sub-directories reside. Bare repository is essentially a .git folder with a specific folder where all the project files reside.
Practically speaking everything in the repository apart from .git is a part of working tree. To create a bare repository, navigate to the chosen directory in bash (for linux users) or command prompt (for windows users) and type:
The file structure of the bare repository should look like this:
Note: This is the exact same file structure of .git folder in non-bare repository
It is important to note that all bare repositories have .git extension (E.g. notice BareRepo.git). Since you cannot commit, or make changes to it, bare repositories are pretty useless on their own. But then why does it exist? When people collaborate to work on a project, they need a central repository where all the tracked changes are stored and prevent any conflict between the versions of the project on other’s computers. A central repository also means that any new contributor can clone the repository into a local one without getting any unsaved changes or conflicting work of others (in short, no mess). A central repository was strictly supposed to be something like a reference repository.
This requires one to use a remote repository as a central one, and initially, only Bare repositories could be used as remote repositories. With the latest changes in git, central repositories need not be bare, hence not many people know about it properly.
The only possible operations on the Bare Repository are Pushing or Cloning.
Using a Bare Repository
A bare repository is linked with a local repository, hence the files in .git of local repo should match with the files in the bare repo. First, create a bare repository (See section for the code snippet).
Then, create a local repository folder and clone the bare repository:
Don’t worry about the warning. The cloned repository will have the same name as that of the Bare Repository, navigate to that folder and add project files and commit changes. Then push the changes to the bare repository:
And thus, your local repo has been linked to the Bare Repository. In case you already have some files in the project directory, directly initialize the project folder as a git repository, then push its changes to a bare repository (make sure that the Bare repository is not linked to any other project or is newly created). Another way is to clone your working project repository into a bare one:
Why is only Bare Repository used as a Central Repository for syncing work?
Central Repositories use bare repositories only because git doesn’t allow you to push to a non-bare repository as the working tree will become inconsistent.
To demonstrate why you can’t push to a non-bare repository:
But if you still want to be stubborn about it, you can read the warning and go to the non-bare repository where you wish to push and set receive.denyCurrentBranch to ignore and then push the changes.
Unless you want to do this every time you push changes to the remote repository, it is recommended to use a bare repository.
A bare repository takes much less space to store the same information along with the tracked changes than a non-bare repository. Hence, its storage consumption is the most efficient. Therefore, only a bare repository is suited to serve as a remote or central repository.
Русские Блоги
Как клонировать все удаленные ветки в Git?
Я уверен, что упустил что-то очевидное, но я прочитал руководство и совершенно не доволен.
#1-й этаж
Git автоматически сделает правильные вещи:
Git проверит, существует ли ветка с таким же именем на удаленном сайте, и, если она существует, будет отслеживать ее так же, как вы явно указали ее как удаленную ветку. На странице руководства git-checkout Git 1.8.2.1:
Если
не найден, но действительно существует ветвь отслеживания на удаленном сайте (называемая ) с соответствующим именем, это эквивалентно
#2-ой этаж
Использовать мой инструментgit_remote_branch (Вам необходимо установить Ruby на свой компьютер). Он специально создан для упрощения операций удаленного филиала.
Каждый раз, когда он выполняет действие от вашего имени, он отображается на консоли красным цветом. Со временем они наконец-то проникают в ваш мозг 🙂
Если вы не хотите, чтобы grb запускал команды от вашего имени, просто используйте функцию «description». Эти команды будут напечатаны на вашей консоли, а не выполняться за вас.
Наконец, все команды имеют псевдонимы для облегчения запоминания.
Это помощь при запуске справки grb:
#3-й этаж
Или более подробный, но более легкий для запоминания
Может быть, лучше отслеживать удаленные репозитории.
#4-й этаж
Лучше опоздать, чем никогда, но это лучший способ сделать это:
#5-й этаж
Используйте псевдонимы. Хотя местного пассажирского самолета первой линии Git нет, вы можете определить себя как
Затем используйте его как
# 6 этаж
Для копирования и вставки в командную строку:
Чтобы улучшить читаемость:
# 7 этаж
Это не слишком сложно, очень простые и понятные шаги заключаются в следующем:
git fetch origin Это перенесет все удаленные ветки в ваш локальный.
Убедитесь, что вы находитесь в нужной ветке с помощью следующей команды;
Результат будет выглядеть так:
Обратите внимание, что символ * обозначает текущую ветвь.
# 8 этаж
Почему только «хозяин»
git clone Загрузите все удаленные удаленные ветки, но по-прежнему относитесь к ним как к «удаленным», даже если файлы находятся в вашем новом репозитории. Единственным исключением является то, что процесс клонирования создает локальную ветвь с именем «master» из удаленной ветки с именем «master». по умолчанию, git branch Показаны только локальные ветки, поэтому вы видите только «master».
Как получить местное отделение
В этом примере branchone Вы основаны на origin/branchone Имя созданной локальной ветки; если вы хотите создать локальную ветку с другим именем, вы можете сделать следующее:
# 9 этаж
Вам просто нужно использовать «git clone», чтобы получить все ветки.
Вы можете переключиться на любую существующую ветку.
# 10 этаж
Ни один из этих ответов не решает проблему, просто никто не идет по правильному пути.
У меня возникли проблемы с переносом репозитория с одного сервера / системы на другой сервер / систему. Когда я клонировал репозиторий, он создавал только локальную ветвь для мастера, поэтому, когда я нажимал на новый удаленный сервер, была отправлена только главная ветка.
Поэтому я нашел эти два метода очень полезными. Надеюсь, они смогут помочь другим.
способ 1:
Способ 2:
# 11 этаж
Глядя на один из ответов на вопрос, я заметил, что его можно сократить:
Но имейте в виду, что если одна из удаленных веток называется admin_master, она не будет загружена!
Спасибо за первоначальное намерение bigfish
# 12 этаж
Это еще одна короткая однострочная команда, которая создает локальные ветки для всех удаленных веток:
Если вы создали локальную ветку для отслеживания, она тоже будет работать. Вы можете в первую очередь git clone Или позвоните в любое время позже.
Если вам не нужно оформлять заказ после клонирования master Ветвь, пожалуйста, используйте
# 13 этаж
Все ответы, которые я здесь видел, действительны, но есть более чистый способ клонировать репозиторий и вытащить все ветки сразу.
При клонировании репозитория фактически загружается информация обо всех ветках, но ветви скрыты. С командой
Вы можете отобразить все ветки репозитория и использовать следующую команду
Вы можете вручную «загрузить» их все сразу.
Однако, если вы хотите клонировать репозиторий с множеством ветвей, все вышеперечисленные методы утомительны и утомительны, хотя и немного сложны, по сравнению с более чистым и быстрым методом, который я покажу. Вам необходимо выполнить следующие три шага:
Переключите этот репозиторий из пустого (голого) репозитория в обычный репозиторий, переключив логическое значение «голый», настроенное git, на false:
Возьмите все содержимое текущей папки и создайте все ветки на локальном компьютере, так что используйте его как обычный репозиторий.
Итак, теперь вам нужно только ввести команду «git branch», чтобы увидеть, что все ветки были загружены.
Это быстрый способ клонировать репозиторий git сразу для всех веток, но вы не хотите делать это для каждого проекта таким образом.
# 14 этаж
Используйте команду, которую вы помните
Я использую Bitbucket, службу хостинга репозиториев Atlassian. Поэтому я старался следить за их документацией. Это мне очень подходит. Вы можете проверить удаленные ветки, используя следующие простые и удобные команды.
Сначала клонируйте свой репозиторий, затем перейдите в целевую папку. И последнее, но не менее важное: снятие средств и оформление заказа:
Вот и все. Это более реальный пример:
# 15 этаж
И получить их вручную, зная ссылочное имя.
Затем снова проверьте все ветки:
Если описанный выше метод не помогает, вам нужно вручную добавить недостающие ветки в список отслеживания (потому что они каким-то образом потеряны):
от git remote set-branches Например:
Поэтому он может появиться в remotes/origin Вниз:
Исправление проблем
Если вы по-прежнему не можете получить ничего, кроме основной ветки, проверьте следующее:
# 16 этаж
Я написал это немногоPowershellФункция, позволяющая проверить все мои ветки git, которые находятся на исходном пульте.
вВ моем репозитории настроек gitМожно найти больше функций git
# 17 этаж
Эти коды перенесут весь удаленный код ветки в локальный репозиторий.
# 18 этаж
Клонирование из локального репозитория не подходит для git clone и git fetch: многие ветки / теги останутся невытянутыми.
Получите клон со всеми ветками и тегами.
Чтобы получить клон со всеми ветками и тегами, а также рабочую копию, выполните следующие действия:
# 19 этаж
По состоянию на начало 2017 г.В этом комментарииОтвет правильный:
git fetch
Снизил для тебя ветку. Хотя при этом не будут вытягиваться все ветви сразу, вы можете сделать это отдельно по ветке.
# 20 этаж
Мне нужно сделать то же самое. это моеRubyсценарий.
# 21 этаж
Если вы только зайдете в филиал, вы получите все необходимое.
Но как насчет ветвей, созданных другими после клонирования?
В этом случае сделайте следующее:
Если вы хотите снимать деньги и оформлять заказ одновременно, вы можете сделать следующее:
git fetch && git checkout your_branch_name
Следующие изображения также были созданы для вас, чтобы упростить то, что я говорю:
# 22 этаж
Если вы хотите получить сразу несколько удаленных веток, сделайте следующее:
Теперь вы можете проверить любую ветку по мере необходимости, не обращаясь к удаленному репозиторию.
# 23 этаж
Вот этотBashМне скрипт помог:
Он создаст ветки отслеживания для всех удаленных ветвей (кроме главного сервера) (вы можете получить его из исходной команды clone). Я думаю, вам все еще может понадобиться сделать
Кредиты первой линии начисляются пользователю CFI
# 24 этаж
# 25 этаж
Это ответ с использованием awk. Достаточно, если этот метод будет использован на новом складе.
Существующие ветки будут только извлечены или объявлены как существующие, но можно добавить фильтры, чтобы избежать конфликтов.
Этот ответ следуетNikos C.изидея 。
Кроме того, мы можем указать удаленные ветки. Это основано наmurphytalkизответ 。
При конфликте возникают сообщения о фатальных ошибках, но я думаю, что они безвредны.
Обе эти команды могут использовать псевдонимы.
использоватьни один. НиктоизответДля справки, мы можем использовать следующую команду для создания псевдонима:
Лично я буду использовать полную track-all Или все track-all-branches 。
# 26 этаж
Вы увидите, что ‘git clone git: //example.com/myprojectt’ будет извлекать все, даже ветки, вам нужно только проверить их, чтобы создать локальную ветку.
# 27 этаж
# 28 этаж
Когда вы выполняете «git clone git: // location», все ветки и теги будут извлечены.
Чтобы работать с определенной удаленной веткой, предположим, что это удаленный источник:
# 29 этаж
Выполняемая выборка должна извлекать все удаленные ветки, но не создавать для них локальные ветки. Если вы используете gitk, вы должны увидеть описание удаленной ветки как «remotes / origin / dev» или подобное.
Чтобы создать локальную ветку на основе удаленной ветки, сделайте следующее:
Он должен вернуть следующее:
Теперь, когда вы находитесь в ветке разработки, «git pull» обновит ваш локальный разработчик в том же месте, что и удаленная ветка разработчика. Обратите внимание, что он извлечет все ветви, но потянет только ту ветку, на которой вы находитесь, на вершину дерева.
# 30 этаж
Сначала клонируйте пультGitРепозиторий иcdВнутрь:
Далее смотрим на локальную ветку в репозитории:
Если вы просто хотите быстро просмотреть ветки восходящего потока, вы можете напрямую просмотреть:
Однако, если вы хотите работать с этой веткой, вам необходимо создать локальную ветвь отслеживания, что можно сделать автоматически следующими способами:
Теперь, если вы посмотрите на локальную ветку, вы увидите следующее:
Фактически, вы можете использовать git remote Отслеживайте несколько удаленных репозиториев.
В этот момент дела идут безумно, так что бегите gitk Посмотрите, что произошло:
