Git для начинающих. Урок 2.
Создание и клонирование репозитория
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое репозиторий
Это каталог в файловой системе, где хранится информация о проекте:
- файлы и папки проекта
- история проекта
- настройки проекта
- служебная информация
Информация о репозитории хранится в скрытой папке .git в корне проекта.
Можно ли работать с git локально
Да, можно. Но при этом проект находится только на нашей машине и в случае поломки железа или случайной потери данных мы не сможем восстановить проект.
Локальный репозиторий
Это репозиторий, который хранится на нашей машине, в рабочей папке проекта. Это та самая скрытая папка .git
Удаленный репозиторий, зачем он нужен
Это репозиторий, который хранится в облаке, на сторонних сервисах, специально созданных под работу с проектами git.
Плюсы удаленного репозитория
- выполняет роль резервной копии
- возможность работать в команде
- некоторые дополнительные возможности, которые предоставляет хостинг. Например, визуализация истории или возможность работать над проектом прямо в веб-интерфейсе
Что такое клонирование
Это копирование удаленного репозитория на локальную машину. Обычно это первое действие при работе с проектом. При клонировании на нашу машину копируются файлы и папки проекта и вся его история. То есть мы получаем доступ к истории не с момента начала нашей работы над проектом, а с самого начала проекта.
Как клонировать готовый проект
В первую очередь, нужно получить ссылку на проект. Мы можем найти ее сами или получим готовую, например, на новой работе. Возьмем для примера репозиторий vuejs — https://github.com/vuejs/vue.git
Наберем в командной строке
$ git clone https://github.com/vuejs/vue.git
При этом в текущем каталоге создастся папка vue, в ней окажутся все файлы проекта vue и специальная скрытая папка .git, то есть сам репозиторий, или информация о нем.
Как клонировать проект в другую папку
При клонировании по умолчанию создается папка с таким же названием, как и у репозитория. Но можно склонировать репозиторий и в другую папку вот так
$ git clone https://github.com/vuejs/vue.git vue-new
Где vue-new — нужное название папки.
Свой удаленный репозиторий
Для своих проектов нам понадобится собственный репозиторий. Можно работать и локально, но плюсы удаленного мы уже рассматривали выше. Теперь нужно выбрать хостинг для наших git-проектов.
Где держать репозиторий
Есть множество вариантов, самые известные — это github и bitbucket. Нужно выбирать.
На самом деле не парьтесь. У них схожий функционал, и в начале работы с git мы не заметим разницы. bitbucket мне нравится больше из-за интерфейса, но в уроках выберем github из-за его большей популярности.
Чтобы продолжить уроки, нужно зарегистрироваться на github. Если у вас нет там аккаунта, то форму регистрации увидите сразу на главной странице — https://github.com/
Как создать репозиторий в github
После регистрации создание репозитория доступно с главной страницы github. При создании нужно указать название проекта и тип (публичный или приватный). На остальное пока не обращаем внимания.
Права на репозиторий, публичные и приватные
Есть 2 типа репозиториев:
- публичный (public), открыт всем
- приватный (private), доступен только определенному кругу лиц — в первую очередь, нам самим
Публичные репозитории хороши для opensource-проектов и чтобы показать в резюме. Пока нам это не нужно.
Для себя будем создавать приватные репозитории. Для этого нам понадобятся ssh-ключи.
Что такое ssh-ключи
ssh-ключи используются для идентификации клиента на сервере при подключении по безопасному ssh-протоколу. Другими словами, ssh-ключ нужен для того, чтобы пускать на сервер только определенных клиентов. Только тех, кому разрешен доступ к проекту.
ssh-ключ не имеет прямого отношения к git, но так репозитории находятся на удаленных серверах, то ssh-ключи используются для разграничения доступа к приватным репозиториям.
ssh-ключ состоит из пары ключей: публичного и приватного ключа. Это просто 2 текстовых файла:
- /домашний-каталог/.ssh/id_rsa.pub — публичный
- /домашний-каталог/.ssh/id_rsa — приватный
Публичный ключ передается сторонним серверам, например, github, для открытия доступа на эти сервера. Приватный ключ хранится только на нашей машине и никому не передается. То есть когда у нас просят ssh-ключ, чтобы дать доступ на какой-нибудь сервер, мы отдаем именно публичный ключ, id_rsa.pub
Как сгенерировать ssh-ключ
ssh-ключи сами собой не появляются, но стоит проверить, возможно, они были установлены раньше. Запустим в терминале команды
$ cd ~/.ssh $ ls -l
Если видим файлы id_rsa и id_rsa.pub — отлично, ключи уже есть.
Если этих файлов нет, то нужно сгенерировать ключи утилитой ssh-keygen. В Windows она устанавливается вместе с git, в Linux и MacOS при необходимости установите. В Linux, например, вот так
$ sudo apt install ssh-keygen
После этого нужно сгенерировать пару ключей, запустив команду в терминале
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
$ ls -l total 24 -rw------- 1 sn8 sn8 1675 Feb 11 2017 id_rsa -rw-r--r-- 1 sn8 sn8 392 Feb 11 2017 id_rsa.pub -rw-r--r-- 1 sn8 sn8 5746 Oct 28 21:52 known_hosts
Появились файлы id_rsa и id_rsa.pub — значит, ключи успешно сгенерированы.
known_hosts — это файл, в котором ssh прописывает сервера, на которые мы заходим. При первом подключении к github нужно будет разрешить доступ к github.com (напечатать yes в терминале)
Как добавить ssh-ключ в настройках github
Открываем публичный ключ id_rsa.pub и копируем его содержимое. В настройках github ищем раздел «SSH и GPG keys» — https://github.com/settings/keys. Жмем «New SSH key», задаем название ключа, например, имя, и вставляем форму публичный ключ, прямо текстом. Все, теперь у нас есть доступ к нашим приватным репозиториям.
Два способа создания проекта
Первый, когда мы начинаем новый проект. Удобнее будет создать репозиторий на github и склонировать пустой проект на локальную машину.
Второй, когда у нас уже есть проект. Нужно зайти в папку проекта и связать его с уже существующим репозиторием на github. Это называется инициализация.
Рассмотрим оба способа.
Пустой проект
Создаем приватный репозиторий на github, назовем его first-site. Я зарегистрировался под именем Webdevkin, моя ссылка для клонирования будет такая — git@github.com:Webdevkin/first-site.git. Ваша зависит от имени пользователя.
Идем в командную строку и запускаем
$ git clone git@github.com:Webdevkin/first-site.git
В текущей папке получим новую папку с названием first-site — это и есть наш проект.
P.S. У вас склонировать этот репозиторий не получится — он закрытый. Создайте свой 🙂
Непустой проект
Допустим, у нас на локальной машине уже есть проект second-site. Создаем в github репозиторий second-site. Заходим в папку проекта и выполняем команды
$ git init $ git add . $ git commit -m "Initial commit" $ git remote add origin git@github.com:Webdevkin/second-site.git $ git push -u origin master
Все, можно приступать к работе над проектом. Команды add, commit и push мы разберем в следующих уроках.
Это единственный урок, в котором мы разбирались с тонкостями репозиториев. В дальнейшем будем считать, что репозиторий = проект.
Что могу посоветовать
- github или bitbucket? Для личных проектов неважно, оба сервиса разрешают бесплатно создавать приватные репозитории. Для open source или резюме — github
- не увлекайтесь клонированием в папку со своим названием. Есть шанс запутаться, самому или коллегам
- не путайте публичный и приватный ключи. Отдаем вовне только публичный ключ id_rsa.pub
- при смене рабочей машины можно не генерировать ssh-ключи заново, а скопировать их со старой машины. Тогда не придется заново прописывать новые ключи на серверах
Немного подробнее о копировании ssh-ключей
Как скопировать ssh-ключи с одной машины на другую
Хочу немного затронуть эту тему отдельно. Генерировать ключ на новой машине не обязательно. Но нужно выполнить такие действия
- Скопировать id_rsa и id_rsa.pub со старой машины на новую
- Посмотреть права на файлы, возможно, ключи окажутся слишком «открытыми» для записи и потребуется сменить им права доступа — sudo chmod 700 ~/.ssh/*
- Выполнить команду ssh-add
Ссылки, которые могут пригодиться
- github — https://github.com/
- bitbucket — https://bitbucket.org/
- подробнее об ssh-ключах (en) — connecting-to-github-with-ssh
На этом все. В следующем уроке мы сделаем первые изменения в проекте и начнем понимать, в чем заключается прелесть git.
Спасибо за внимание и до встречи!
Все уроки курса
- Вводный урок
- 1. Установка и базовая настройка git
- 2. Создание и клонирование репозитория git
- 3. Делаем первые изменения, git status и git diff
- 4. Коммиты и история коммитов, git commit, git log и git show
- 5. Подробнее об истории коммитов. Путешествие по истории
- 6. Работа с сервером, git push и git pull
- 7. Ветки — главная фишка git, git branch и git checkout
- 8. Работа с ветками на сервере, git fetch
- 9. Слияния или мерджи веток, git merge
- 10. Конфликты и их разрешение
- Платная часть курса. Презентация
- * 11. Работа с gitignore и git exclude
- * 12. Буфер обмена git, git stash
- * 13. Копирование коммитов, git cherry-pick
- * 14. Отмена и редактирование последнего коммита
- * 15. Отмена произвольного коммита, git revert
- 16. Склеивание коммитов, git rebase —interactive и git reflog
- * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
- * 18. Работа с git rebase. Отличия от merge
- * 19. Что такое git push —force и как с ним работать
- * 20. Ищем баги с помощью git, git bisect
- * 21. Как и зачем работать с тегами git
- * 22. Процессы: github flow и git flow
- * 23. Псевдонимы в git
- 24. Мердж-реквесты
- * 25. Форки
Клонирование репозитория
When you create a repository on GitHub.com, it exists as a remote repository. You can clone your repository to create a local copy on your computer and sync between the two locations.
Platform navigation
Tool navigation
About cloning a repository
You can clone a repository from GitHub.com to your local computer, or to a codespace, to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub.com to your local machine, or to a remote virtual machine when you create a codespace. For more information about cloning to a codespace, see «Creating a codespace for a repository.»
You can clone a repository from GitHub.com to your local computer to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub.com to your local machine.
You can clone a repository from GitHub.com to your local computer to make it easier to fix merge conflicts, add or remove files, and push larger commits. When you clone a repository, you copy the repository from GitHub.com to your local machine.
Cloning a repository pulls down a full copy of all the repository data that GitHub.com has at that point in time, including all versions of every file and folder for the project. You can push your changes to the remote repository on GitHub.com, or pull other people’s changes from GitHub.com. For more information, see «Using Git».
You can clone your existing repository or clone another person’s existing repository to contribute to a project.
Cloning a repository
- On GitHub.com, navigate to the main page of the repository.
- Above the list of files, click
Code.
-
To clone the repository using HTTPS, under «HTTPS», click
.
git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY > Cloning into `Spoon-Knife`. > remote: Counting objects: 10, done. > remote: Compressing objects: 100% (8/8), done. > remove: Total 10 (delta 1), reused 10 (delta 1) > Unpacking objects: 100% (10/10), done. To learn more about GitHub CLI, see «About GitHub CLI.»
To clone a repository locally, use the repo clone subcommand. Replace the repository parameter with the repository name. For example, octo-org/octo-repo , monalisa/octo-repo , or octo-repo . If the OWNER/ portion of the OWNER/REPO repository argument is omitted, it defaults to the name of the authenticating user.
gh repo clone REPOSITORY You can also use the GitHub URL to clone a repository.
gh repo clone https://github.com/PATH-TO/REPOSITORY - On GitHub.com, navigate to the main page of the repository.
- Above the list of files, click
Code.
Open with GitHub Desktop.
Cloning an empty repository
An empty repository contains no files. It’s often made if you don’t initialize the repository with a README when creating it.
- On GitHub.com, navigate to the main page of the repository.
- To clone your repository using the command line using HTTPS, under «Quick setup», click
. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click SSH, then click
.
Alternatively, to clone your repository in Desktop, click
Set up in Desktop and follow the prompts to complete the clone.
git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY > Cloning into `Spoon-Knife`. > remote: Counting objects: 10, done. > remote: Compressing objects: 100% (8/8), done. > remove: Total 10 (delta 1), reused 10 (delta 1) > Unpacking objects: 100% (10/10), done. Troubleshooting cloning errors
When cloning a repository it’s possible that you might encounter some errors.
If you’re unable to clone a repository, check that:
- You can connect using HTTPS. For more information, see «Troubleshooting cloning errors.»
- You have permission to access the repository you want to clone. For more information, see «Troubleshooting cloning errors.»
- The default branch you want to clone still exists. For more information, see «Troubleshooting cloning errors.»
Further reading
Глава 4. Все о клонировании
В старых системах управления версиями стандартная операция для получения файлов — это checkout. Вы получаете набор файлов в конкретном сохраненном состоянии.
В Git и других распределенных системах управления версиями стандартный способ — клонирование. Для получение файлов вы создаете «клон» всего хранилища. Другими словами, вы фактически создаете зеркало центрального сервера. При этом всё, что можно делать с основным хранилищем, можно делать и с локальным.
Синхронизация компьютеров
Я вполне приемлю создание архивов или использование rsync для резервного копирования и простейшей синхронизации. Но я работаю то на ноутбуке, то на стационарном компьютере, которые могут никак между собой не взаимодействовать между этим.
Создайте хранилище Git и закоммитьте файлы на одном компьютере. А потом выполните на другом
$ git clone первый.компьютер:/путь/к/файлам
для создания второго экземпляра файлов и хранилища Git. С этого момента команды
$ git commit -a $ git pull другой.компьютер:/путь/к/файлам HEAD
будут «втягивать» состояние файлов с другого компьютера на тот, где вы работаете. Если вы недавно внесли конфликтующие изменения в один и тот же файл, Git даст вам знать, и нужно будет сделать коммит заново после разрешения ситуации.
Классическое управление исходным кодом
Создайте хранилище Git для ваших файлов:
$ git init $ git add . $ git commit -m "Начальный коммит"
На центральном сервере создайте так называемое «голое» (bare) хранилище Git в неком каталоге:
$ mkdir proj.git $ cd proj.git $ git init --bare $ # вариант «в одну строчку»: GIT_DIR=proj.git git init
Запустите Git-демон, если необходимо:
$ git daemon --detach # возможно уже запущен
Для создания нового пустого хранилища Git на публичных серверах следуйте их инструкциям. Обычно, нужно заполнить форму на веб-странице.
Отправьте ваши изменения в центральное хранилище вот так:
$ git push git://центральный.сервер/путь/к/proj.git HEAD
Для получения ваших исходников разработчик вводит
$ git clone git://центральный.сервер/путь/к/proj.git
После внесения изменений разработчик сохраняет изменения локально:
$ git commit -a
Для обновления до последней версии:
$ git pull
Любые конфликты слияния нужно разрешить и закоммитить:
$ git commit -a
Для выгрузки локальных изменений в центральное хранилище:
$ git push
Если на главном сервере были новые изменения, сделанные другими разработчиками, команда push не сработает. В этом случае разработчику нужно будет вытянуть к себе (pull) последнюю версию, разрешить возможные конфликты слияний и попробовать еще раз.
Голые (bare) хранилища
Голое (bare) хранилище называются так потому, что у него нет рабочего каталога. Оно содержит только файлы, которые обычно скрыты в подкаталоге .git. Другими словами, голое хранилище содержит историю изменений, но не содержит снимка какой-либо определенной версии.
Голое хранилище играет роль, похожую на роль основного сервера в централизованной системе управления версиями: это дом вашего проекта. Разработчики клонируют из него проект и закачивают в него свежие официальные изменения. Как правило, оно располагается на сервере, который не делает почти ничего кроме раздачи данных. Разработка идет в клонах, поэтому домашнее хранилище может обойтись и без рабочего каталога.
Многие команды Git не работают в голых хранилищах, если переменная среды GIT_DIR не содержит путь до хранилища и не указан параметр —bare.
Push или pull?
Зачем вводится команда push, вместо использования уже знакомой pull? Прежде всего, pull не работает в голых хранилищах, вместо нее нужно использовать команду fetch, которая будет рассмотрена позже. Но даже если держать на центральном сервере нормальное хранилище, использование команды pull в нем будет затруднительным. Нужно будет сначала войти на сервер интерактивно и сообщить команде pull адрес машины, с которой мы хотим забрать изменения. Этому могут мешать сетевые брандмауэры (firewall), но в первую очередь: что если у нас нет интерактивного доступа к серверу?
Тем не менее, не рекомендутся push-ить в хранилище помимо этого случая — из-за путаницы, которая может возникнуть, если у целевого хранилища есть рабочий каталог.
Короче говоря, пока изучаете Git, push-те только в голые хранилища. В остальных случаях pull-те.
Создание форка проекта
Не нравится путь развития проекта? Думаете, можете сделать лучше? Тогда на вашем сервере выполните
$ git clone git://основной.сервер/путь/к/файлам
Теперь расскажите всем о форке (ответвлении, прим. пер.) проекта на вашем сервере.
Позже вы сможете в любой момент втянуть к себе изменения из первоначального проекта:
$ git pull
Максимальные бэкапы
Хотите иметь множество защищенных, географически разнесенных запасных архивов? Если в вашем проекте много разработчиков, ничего делать не нужно! Каждый клон — это и есть резервная копия; не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хешированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами.
Если ваш проект не такой популярный, найдите как можно больше серверов для размещения клонов.
Особо беспокоящимся рекомендуется всегда записывать самый последний 20-байтный SHA1 хеш HEAD в каком-нибудь безопасном месте. Оно должно быть безопасным, а не тайным. Например, хороший вариант — публикация в газете, потому что атакующему сложно изменить каждый экземпляр газеты.
Многозадачность со скоростью света
Скажем, вы хотите работать над несколькими функциями параллельно. Тогда закоммитьте ваши изменения и запустите
$ git clone . /некий/новый/каталог
Благодаря жёстким ссылкам создание локального клона требует меньше времени и места, чем простое копирование.
Теперь вы можете работать с двумя независимыми функциями одновременно. Например, можно редактировать один клон, пока другой компилируется. В любой момент можно сделать коммит и вытянуть изменения из другого клона:
$ git pull /другой/клон HEAD
Партизанское управление версиями
Вы работаете над проектом, который использует другую систему управления версиями, и вам очень не хватает Git? Тогда создайте хранилище Git в своем рабочем каталоге:
$ git init $ git add . $ git commit -m "Начальный коммит"
затем склонируйте его:
$ git clone . /некий/новый/каталог
Теперь перейдите в этот новый каталог и работайте в нем вместо основного, используя Git в свое удовольствие. В какой-то момент вам понадобиться синхронизировать изменения со всеми остальными — тогда перейдите в изначальный каталог, синхронизируйте его с помощью другой системы управления версиями и наберите
$ git add . $ git commit -m "Синхронизация с остальными"
Теперь перейдите в новый каталог и запустите
$ git commit -a -m "Описание моих изменений" $ git pull
Процедура передачи изменений остальным зависит от другой системы управления версиями. Новый каталог содержит файлы с вашими изменениями. Запустите команды другой системы управления версиями, необходимые для загрузки файлов в центральное хранилище.
Subversion (вероятно, наилучшая централизованная система управления версиями) используется неисчислимым множеством проектов. Команда git svn автоматизирует описанный процесс для хранилищ Subversion, а также может быть использована для экспорта проекта Git в хранилище Subversion.
Mercurial
Mercurial — похожая система управления версиями, которая может работать в паре с Git практически без накладок. С расширением hg-git пользователь Mercurial может без каких либо потерь push-ить и pull-ить из хранилища Git.
Получить hg-git можно с помощью Git:
$ git clone git://github.com/schacon/hg-git.git
$ hg clone http://bitbucket.org/durin42/hg-git/
К сожалению, мне неизвестен аналогичное расширение для Git. Поэтому я рекомендую использовать Git, а не Mercurial, для центрального хранилища, даже если вы предпочитаете Mercurial. Для проектов, использующих Mercurial, обычно какой-нибудь доброволец поддерживает параллельное хранилище Git для привлечения пользователей последнего, тогда как проекты, использующие Git, благодаря hg-git автоматически доступны пользователям Mercurial.
Хотя расширение может сконвертировать хранилище Mercurial в Git путем push’а в пустое хранилище, эту задачу легче решить, используя сценарий hg-fast-export.sh, доступный как
$ git clone git://repo.or.cz/fast-export.git
Для преобразования выполните в пустом каталоге
$ git init $ hg-fast-export.sh -r /hg/repo
после добавления сценария в ваш $PATH.
Bazaar
Упомянем вкратце Bazaar, так как это самая популярная свободная распределенная система управления версиями после Git и Mercurial.
Bazaar относительно молод, поэтому у него есть преимущество идущего следом. Его проектировщики могут учиться на ошибках предшественников и избавиться от исторически сложившихся неровностей. Кроме того, его разработчики заботятся о переносимости и взаимодействии с другими системами управления версиями.
Расширение bzr-git позволяет (в какой-то степени) пользователям Bazaar работать с хранилищами Git. Программа tailor конвертирует хранилища Bazaar в Git и может делать это с накоплением, тогда как bzr-fast-export хорошо приспособлена для разовых преобразований.
Почему я использую Git
Изначально я выбрал Git потому, что слышал, что он в состоянии справиться с совершенно неуправляемыми исходными текстами ядра Linux. Я никогда не ощущал потребности сменить его на что-то другое. Git работает замечательно и мне еще только предстоит напороться на его недостатки. Так как я в основном использую Linux, проблемы на других системах меня не касаются.
Я также предпочитаю программы на C и сценарии на bash исполняемым файлам вроде сценариев на Python-е: у них меньше зависимостей, и я привык к быстрому выполнению.
Я думал о том, как можно улучшить Git, вплоть до того, чтобы написать собственный инструмент, похожий на Git; но только как академическое упражнение. Завершив проект, я бы все равно продолжил пользоваться Git, потому что выигрыш слишком мал, чтобы оправдать использование самодельной системы.
Естественно, ваши потребности и пожелания вероятно отличаются от моих и вы, возможно, лучше уживетесь с другой системой. И всё же вы не слишком ошибетесь, используя Git.
Работаем с репозиториями в Git
Одна из самых распространенных систем управления версиями – Git. Ее ядро добавляет в систему ряд консольных команд, предназначенных для управления репозиториями. В самих же репозиториях хранятся важные каталоги, конфигурационные файлы, журналы и прочие связанные элементы.
Далее я расскажу, как создать, клонировать и удалить эти репозитории.
Следующие инструкции предназначены для тех, кто уже установил Git на свой сервер. Если вы еще не сделали этого, используйте руководство с GitHub, которое поможет разобраться с выполнением поставленной задачи.
Создание Git-репозитория
Сначала рассмотрим создание репозитория. Представим, что у вас уже есть папка для хранения файлов, но она еще не находится под контролем Git.
Откройте «Командную строку» (Windows) или Терминал (Linux/macOS) и перейдите по пути данной папки.
В Linux выполните команду:
cd /home/user/directory
В macOS :
cd /Users/user/directory
В Windows:
cd C:/Users/user/directory
Остается только ввести нижеуказанную команду, чтобы завершить первый этап.
git init
Благодаря этой команде создается структура подкаталога со всеми необходимыми файлами. Кстати, все они расположены в подпапке с названием .git . Пока что проект не находится под контролем учета версий, поскольку в него добавлены только нужные элементы для работы Git. Для добавления файлов в репозиторий будем использовать git add. Команда git commit является заключительной:
git add git commit -m 'initial project version'
Теперь у вас есть Git-репозиторий со всеми необходимыми составляющими и отслеживаемыми файлами.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Клонирование существующего репозитория
Второй вариант создания директории для контроля версий – копирование существующего проекта с другого сервера. Это актуально, когда осуществляется доработка готового проекта или вы желаете внедрить его компоненты в свой. В этом поможет команда git clone , о которой и пойдет речь далее.
При использовании упомянутой команды вы получаете клоны всех версий файлов, а значит, можете использовать любые из них, если что-то пойдет не так. Это же пригождается, когда требуется вернуть предыдущую версию проекта, что осуществимо благодаря файлам, помещенным под версионный контроль.
Для клонирования существующего репозитория понадобится ввести git clone . Пример такой команды вы видите ниже:
git clone https://github.com/rep/rep
Данная команда позволила вам получить клон всех версий указанного репозитория (в качестве примера было взято название rep ). Теперь на вашем сервере создана директория с указанным названием. К ней подключена поддержка контроля версий, то есть появилась папка .git .
При использовании вышеуказанной команды репозиторий клонируется с текущим названием. Если же оно должно отличаться, используйте следующую вариацию команды:
git clone https://github.com/rep/rep myrep
Завершим этот раздел статьи описанием содержимого, которое появляется в консоли при выполнении команды. Данный вывод соответствует успешному клонированию:
Cloning into 'Git'. remote: Counting objects: 46, done. remote: Compressing objects: 100% (25/25), done. remote: Total 46 (delta 7), reused 43 (delta 4), pack-reused 0 Unpacking objects: 100% (46/46), done. Checking connectivity. done.
Удаление локального Git-репозитория
Если с созданием и клонированием репозиториев все понятно, то как быть, когда папка с проектом уже существует, но в нее нужно поместить новые данные, удалив предыдущие, или когда Git-репозиторий на сервере больше не нужен. В таком случае осуществляется стандартное удаление.
В корне каталога с проектом необходимо избавиться от папки .git, о которой уже шла речь выше. Так вы удаляете только ту информацию, которая связана с Git, но сам проект остается. В Linux через Терминал вы должны перейти к каталогу с проектом и ввести следующую команду:
rm -rf .git
Еще один вариант – удаление .gitignore и .gitmodules в случае их наличия. Тогда команда меняет свой вид на:
rm -rf .git*
Остается только убедиться в отсутствии скрытой папки, которая может помешать инсталляции новой. Для этого существует простая команда ls -lah , выполнить которую необходимо с указанием того же каталога.
Только что мы разобрались с основами создания, клонирования и удаления Git-репозитория. Удачи!