Git clone b что это

A3.2 Приложение C: Команды Git — Клонирование и создание репозиториев

Существует два способа создать Git репозиторий. Первый — клонировать его из существующего репозитория (например, по сети); второй — создать репозиторий в существующем каталоге.

git init

Чтобы превратить обычный каталог в Git репозиторий и начать версионировать файлы в нём, просто запустите git init .

Впервые мы продемонстрировали эту команду в разделе Создание Git-репозитория главы 2 на примере создания нового репозитория для последующей работы с ним.

Мы немного поговорили о смене названия ветки по умолчанию с «master» на что-нибудь другое в разделе Удалённые ветки главы 3.

Мы использовали эту команду для создания чистого репозитория для работы на стороне сервера в разделе Размещение голого репозитория на сервере главы 4.

Ну и наконец мы немного покопались во внутренностях этой команды в разделе Сантехника и Фарфор главы 10.

git clone

На самом деле git clone работает как обёртка над некоторыми другими командами. Она создаёт новый каталог, переходит внутрь и выполняет git init для создания пустого репозитория, затем она добавляет новый удалённый репозиторий ( git remote add ) для указанного URL (по умолчанию он получит имя origin ), выполняет git fetch для этого репозитория и, наконец, извлекает последний коммит в ваш рабочий каталог, используя git checkout .

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

Первоначальное знакомство происходит в разделе Клонирование существующего репозитория главы 2, где мы даём немного объяснений и приводим несколько примеров.

В разделе Установка Git на сервер главы 4 мы рассмотрели как использовать опцию —bare , чтобы создать копию Git репозитория без рабочей копии.

В разделе Создание пакетов главы 7 мы использовали git clone для распаковки упакованного с помощью git bundle репозитория.

Наконец, в разделе Клонирование проекта с подмодулями главы 7 мы научились использовать опцию —recursive чтобы упростить клонирование репозитория с подмодулями.

И хотя git clone используется во многих других местах в книге, перечисленные выше так или иначе отличаются от других вариантов использования.

Получение изменений из удаленного репозитория

Для доступа к удаленным репозиториям можно использовать распространенные команды Git.

Options for getting changes

These commands are very useful when interacting with a remote repository. clone and fetch download remote code from a repository’s remote URL to your local computer, merge is used to merge different people’s work together with yours, and pull is a combination of fetch and merge .

Cloning a repository

To grab a complete copy of another user’s repository, use git clone like this:

$ git clone https://github.com/USERNAME/REPOSITORY.git # Clones a repository to your computer 

You can choose from several different URLs when cloning a repository. While logged in to GitHub, these URLs are available on the main page of the repository when you click

When you run git clone , the following actions occur:

• A new folder called repo is made
• It is initialized as a Git repository
• A remote named origin is created, pointing to the URL you cloned from
• All of the repository’s files and commits are downloaded there
• The default branch is checked out

For every branch foo in the remote repository, a corresponding remote-tracking branch refs/remotes/origin/foo is created in your local repository. You can usually abbreviate such remote-tracking branch names to origin/foo .

Fetching changes from a remote repository

Use git fetch to retrieve new work done by other people. Fetching from a repository grabs all the new remote-tracking branches and tags without merging those changes into your own branches.

If you already have a local repository with a remote URL set up for the desired project, you can grab all the new information by using git fetch *remotename* in the terminal:

$ git fetch REMOTE-NAME # Fetches updates made to a remote repository 

Otherwise, you can always add a new remote and then fetch. For more information, see «Managing remote repositories.»

Merging changes into your local branch

Merging combines your local changes with changes made by others.

Typically, you’d merge a remote-tracking branch (i.e., a branch fetched from a remote repository) with your local branch:

$ git merge REMOTE-NAME/BRANCH-NAME # Merges updates made online with your local work 

Pulling changes from a remote repository

git pull is a convenient shortcut for completing both git fetch and git merge in the same command:

$ git pull REMOTE-NAME BRANCH-NAME # Grabs online updates and merges them with your local work 

Because pull performs a merge on the retrieved changes, you should ensure that your local work is committed before running the pull command. If you run into a merge conflict you cannot resolve, or if you decide to quit the merge, you can use git merge —abort to take the branch back to where it was in before you pulled.

Further reading

• «Working with Remotes» from the Pro Git book»
• «Troubleshooting connectivity problems»

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. Форки

Сведения о GIT

Узнайте о системе управления версиями, Git и о том, как она работает с GitHub.

Сведения об управлении версиями и GIT

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

Разработчики могут просматривать журнал проекта, чтобы узнавать следующее:

• какие изменения были внесены;
• кто внес изменения;
• какие изменения были внесены;
• зачем потребовались изменения.

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

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

• GIT позволяет разработчикам просматривать всю временную шкалу изменений, решений и хода выполнения любого проекта в одном месте. С момента доступа к истории проекта разработчик получает всю необходимую информацию, чтобы разобраться в проекте и начать вносить свой вклад.
• Разработчики работают в разных часовых поясах. Благодаря распределенной системе управления версиями, такой как GIT, совместную работу можно вести в любое время, сохраняя целостность исходного кода. С помощью ветвей разработчики могут безопасно предлагать изменения для рабочего кода.
• Организации, использующие GIT, могут устранить коммуникационные барьеры между командами, чтобы те могли сосредоточиться на выполнении своих задач с максимальной эффективностью. Кроме того, GIT позволяет согласовать совместную работу экспертов над крупными проектами в масштабе всего предприятия.

Сведения о репозиториях

Репозиторий или проект GIT включает в себя полный набор файлов и папок, связанных с проектом, а также журнал изменений каждого файла. Журнал файла представлен в виде моментальных снимков на определенные моменты времени. Эти снимки называются фиксациями. Фиксации можно упорядочивать по нескольким линиям разработки, называемым ветвями. Так как GIT — распределенная система управления версиями, репозитории являются автономными единицами и любой пользователь, имеющий копию репозитория, может получать доступ ко всей базе кода и ее истории. С помощью командной строки или других удобных интерфейсов возможны также следующие действия с репозиторием GIT: взаимодействие с журналом, клонирование репозитория, создание ветвей, фиксация, слияние, сравнение изменений в разных версиях кода и многое другое.

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

Принципы работы GitHub

GitHub служит для размещения репозиториев GIT и предоставляет разработчикам средства для поставки более качественного кода: функции командной строки, проблемы (цепочки обсуждений), запросы на вытягивание, проверка кода и коллекция бесплатных и платных приложений в GitHub Marketplace. С такими уровнями совместной работы, как поток GitHub, сообществом 100 миллионов разработчиков и экосистемой с сотнями интеграции, GitHub изменяет способ создания программного обеспечения.

GitHub позволяет интегрировать совместную работу непосредственно в процесс разработки. Работа организована по репозиториям, в которых разработчики могут устанавливать требования или давать указания участникам команды. Затем, используя поток GitHub, разработчики просто создают ветвь для работы с обновлениями, фиксируют изменения, чтобы сохранять их, открывают запросы на вытягивание, чтобы предлагать и обсуждать изменения, и выполняют слияние запросов на вытягивание после их согласования. Дополнительные сведения см. в разделе «AUTOTITLE».

Сведения о планах и затратах на GitHub см. в разделе GitHub Pricing. Сведения о том, как GitHub Enterprise сравнивается с другими параметрами, см. в статье Сравнение GitHub с другими решениями DevOps.

GitHub и командная строка

Основные команды Git

Работая с GIT, разработчики используют определенные команды для копирования, создания, изменения и объединения кода. Эти команды можно выполнять непосредственно из командной строки или с помощью приложения, например GitHub Desktop. Ниже приведены некоторые распространенные команды для работы с GIT.

• git init — инициализирует новый репозиторий GIT и начинает отслеживание существующего каталога. В существующий каталог добавляется скрытая вложенная папка, в которой размещается внутренняя структура данных, необходимая для управления версиями.
• git clone — создает локальную копию проекта, который уже существует удаленно. Клон включает в себя все файлы проекта, журнал и ветви.
• git add — подготавливает изменение. GIT отслеживает изменения в базе кода разработчика, но для включения изменений в журнал проекта необходимо подготавливать их и создавать моментальные снимки. Эта команда выполняет первую часть этого двухэтапного процесса, то есть подготовку. Все подготовленные изменения станут частью следующего моментального снимка и журнала проекта. Раздельные подготовка и фиксация дают разработчикам полный контроль над историей проекта без необходимости изменять подход к написанию кода и работе в целом.
• git commit — сохраняет моментальный снимок в журнале проекта и завершает процесс отслеживания изменений. Иначе говоря, фиксация похожа на создание фотографии. Все, что было подготовлено с помощью команды git add , станет частью моментального снимка при использовании git commit .
• git status — выводит состояние изменений: не отслеживаются, изменены или подготовлены.
• git branch — показывает ветви, с которыми ведется локальная работа.
• git merge — выполняет слияние линий разработки. Эта команда обычно применяется для объединения изменений, внесенных в двух разных ветвях. Например, разработчик выполняет слияние, когда необходимо объединить изменения из ветви функции с главной ветвью для развертывания.
• git pull — применяет к локальной линии разработки обновления из удаленного аналога. Разработчики используют эту команду, если коллега выполнил фиксации в ветви удаленного репозитория и эти изменения нужно отразить в локальной среде.
• git push — обновляет удаленный репозиторий с учетом фиксаций, выполненных в ветви локально.

Пример. Участие в существующем репозитории

# download a repository on GitHub to our machine # Replace `owner/repo` with the owner and name of the repository to clone git clone https://github.com/owner/repo.git # change into the `repo` directory cd repo # create a new branch to store any new changes git branch my-branch # switch to that branch (line of development) git checkout my-branch # make changes, for example, edit `file1.md` and `file2.md` using the text editor # stage the changed files git add file1.md file2.md # take a snapshot of the staging area (anything that's been added) git commit -m "my snapshot" # push changes to github git push --set-upstream origin my-branch 

Пример. Создание нового репозитория и его публикация в GitHub

Сначала необходимо создать репозиторий на GitHub. Дополнительные сведения см. в разделе «AUTOTITLE». Не инициализируйте репозиторий с помощью файла сведений, GITIGNORE или файла лицензии. Этот пустой репозиторий ожидает добавления кода.

# create a new directory, and initialize it with git-specific functions git init my-repo # change into the `my-repo` directory cd my-repo # create the first file in the project touch README.md # git isn't aware of the file, stage it git add README.md # take a snapshot of the staging area git commit -m "add README to initial commit" # provide the path for the repository you created on github git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git # push changes to github git push --set-upstream origin main 

Пример. Участие в существующей ветви на GitHub

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

# change into the `repo` directory cd repo # update all remote tracking branches, and the currently checked out branch git pull # change into the existing branch called `feature-a` git checkout feature-a # make changes, for example, edit `file1.md` using the text editor # stage the changed file git add file1.md # take a snapshot of the staging area git commit -m "edit file1" # push changes to github git push 

Модели совместной разработки

Существует два основных способа совместной работы на GitHub:

1. общий репозиторий;
2. создание вилок и вытягивание.

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

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