Как запустить репозиторий с github

Запуск GitHub Desktop из командной строки

1. В строке меню выберите меню GitHub Desktop и нажмите кнопку Установить программу командной строки.

github /PATH/TO/REPO 

Вы также можете изменить путь к репозиторию, а затем ввести github . , чтобы открыть этот репозиторий.

$ cd /PATH/TO/REPO [repo]$ github . 

1. Откройте командную строку.
2. Чтобы запустить GitHub Desktop для последнего открытого репозитория, введите github . Чтобы запустить GitHub Desktop для определенного репозитория, введите github и затем путь к репозиторию.

C:\Users\octocat> github PATH\TO\REPO 

Вы также можете изменить путь к репозиторию, а затем ввести github . , чтобы открыть этот репозиторий.

C:\Users\octocat> cd REPO\MY-REPO C:\Users\octocat\repo\myrepo> github . 

Как начать работать с GitHub

1. Создаем на сайте GitHub репозиторий. В нашем случае git@github.com:obemgcabazn/*имя репозитория*.git
2. Открываем в папке проекта командную строку и выполняем команду git init . Она создаст папку .git
3. git remote add origin https://github.com/obemgcabazn/*имя репозитория*.git Привязываем папку к нашему репозиторию на GitHub (origin — это синоним «удаленного репозитория»).
4. git add . — эта команда добавит в индекс все файлы из папки
5. git add -u — (u — updated) добавить в stage файлы измененные с последнего коммита файлы
6. git status покажет, что на данный момент находится в индексе
7. git rm -r —cached /frontend/psd/. — Если нам не нужно передавать какие-то файлы в коммит, то можем удалить их из индекса командой rm . Здесь нужно быть внимательным, так как без флагов эта команда удалит и файлы с жесткого диска.
   • Чтобы оставить файлы на диске и удалить их из индекса, есть флаг —cached
   • Если нужно удалить все файлы из индекса, лежащие в какой-то определенной папке, то нужно поставить флаг -r . Чтобы пройти рекурсивно по всем файлам.

Добавить SSH ключи

Если не работает по причине нехватки прав, то, возможно проблема с SSH ключами. Нужно запустить Gti Bash и набрать следующую команду: ssh-keygen -t rsa -C «myemail@mail.ru» . Конечно, указать свой почтовый ящик. На все вопросы нажимаем Enter. После выполнения, в каталоге C:\Documents and Settings\username\.ssh появятся файлы id_rsa и id_rsa.pub.

Далее на GitHub.com заходим в аккаунт в Settings -> SSH and GPG keys -> «New SSH key». В Заголовок вставляем что угодно, что поможет потом понять на какой компьютер установлен ключ (например, имя или место компьютера), а в поле key вставляем содержимое id_rsa.pub .

После этого гитхаб должен перестать ругаться на отсутствие прав доступа.

Часто используемые команды

• git add файлы — добавляет файлы в индекс
• git commit — отправляет из индекса в хранилище для дальнейшей отправки (git push) в удаленный репозиторий
• git reset — файлы заменяет файлы в индексе файлами из последнего коммита
• git checkout файлы — заменяет файлы проекта ни диске файлами из индекса
• git push origin master — отправляет файл на сервер, чтобы не вводить каждый раз логин/пароль, воспользуйтесь флагом ‘-u’

Чтобы создать новую ветку, нужно использовать команду git branch [Название_ветки] . Если написать просто git branch — покажет список существующих веток.

git checkout [Название ветки] — выбор ветки

Чтобы создать ветку и сразу ее выбрать git checkout -b [Новая ветка]

Использование локального репозитория

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

Создать репозиторий Git

Чтобы создать новый репозиторий Git для своего домена, перейдите на страницу Сайты и домены и нажмите Git. Если вы уже создали репозитории Git для своего домена через Plesk, нажмите Добавить репозиторий. Вы увидите страницу создания нового репозитория:

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

Репозиторий Git в Plesk. Укажите имя репозитория. По умолчанию используется имя домена с суффиксом .git.

В разделе Ваш сайт укажите следующее:

Режим развертывания. По умолчанию используется Автоматическое развертывание. Это означает, что все изменения, переданные в репозиторий Git, будут автоматически развернуты на рабочем сайте. Если вы хотите изменить режим развертывания, нажмите ссылку автоматически развернуты и выберите другую опцию в открывшемся окне Режим развертывания. Если выбрано Развертывание вручную, вам придется вручную развертывать файлы из репозитория Git на вашем хостинге. Если выбрано Без развертывания, файлы не будут развернуты на рабочем сайте (это можно использовать, например, для хранения и обмена кодом).

Нажмите OK. Новый репозиторий будет создан и появится на странице Git.

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

1. SSH (только для Linux) ― этот протокол используется по умолчанию, если на домене включен SSH-доступ для веб-хостинга. Чтобы настроить доступ по SSH для домена, перейдите на страницу Сайты и домены >Доступ к веб-хостингу и в меню Доступ к серверу по SSH выберите /bin/bash или /bin/sh. В этом случае URL репозитория похож на user1@example.net:~/repos/example.git.
2. HTTPS ― этот протокол используется по умолчанию, если запрещен доступ по SSH, и для домена настроен SSL/TLS (Настройки хостинга > Поддержка SSL/TLS). В этом случае URL-адрес похож на https://user1@example.net/plesk-git/example.git.
3. HTTP ― этот протокол используется по умолчанию, если запрещен доступ по SSH, и для домена не настроен SSL/TLS. В этом случае URL-адрес репозитория похож на http://user1@example.com/plesk-git/example.git.

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

Когда репозиторий инициализирован, можно просматривать информацию о записях изменений и имя активной ветки на странице Сайты и домены > Git. По умолчанию для работы Plesk с используется основная ветка. Вы можете потом добавить другие ветки (смотрите раздел Изменить ветку или путь ).

Теперь вы можете записать изменения файлов вашего сайта в локальный репозиторий и передать их в репозиторий сервера.

Передать и развернуть файлы

Когда вы записываете изменения файлов вашего сайта из локального репозитория и передаете их в репозиторий сервера, вы можете увидеть информацию о записи изменений на странице Сайты и домены > Git.

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

Например, если вы записали изменения и передали файл index.html с текстом “Привет! Добро пожаловать на мой сайт!” в репозиторий Git, вы можете тут же открыть адрес сайта и увидеть изменения.

Изменение ветки или пути

Развертывание из новой ветки

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

Чтобы добавить еще одну ветку, ее нужно создать в вашем локальном репозитории. Например, ветку dev можно добавить с помощью команд:

git checkout dev

Затем записать изменения файлов в эту ветку и передать в серверный репозиторий с помощью команд:

git commit -m «изменения в ветку»

git push -u origin dev

Теперь вы можете выбрать одну из двух активных веток. Перейдите на страницу Сайты и домены > Git, нажмите ссылку Изменить ветку и путь и выберите ветку в открывшемся окне в меню Ветка.

Когда вы выберете новую ветку и нажмете ОК, Plesk покажет новую активную ветку.

Изменение пути для развертывания

По умолчанию, для публикации файлов Git на вашем сайте используется папка /httpdocs . Если вы хотите изменить путь для развертывания, нажмите ссылку Изменить ветку и путь и выберите новую папку в открывшемся окне. Вы также можете создать новую папку, нажав кнопку Создать новую папку.

Выбор режима развертывания

Чтобы выбрать режим развертывания для репозитория, нажмите Настройки репозитория и выберите одну из опций в меню Выбрать режим развертывания:

• Автоматическое развертывание. Plesk будет разворачивать все изменения на рабочем сайте, как только они будут переданы в репозиторий Plesk.
• Развертывание вручную. Вам нужно будет вручную развернуть файлы, нажав кнопку Равернуть из репозитория на странице Сайты и домены > Git. Также можно вручную развернуть файлы, нажав кнопку Развернуть возле названия репозитория на странице Сайты и домены.
• Без развертывания (хостинг репозитория). Файлы не будут развернуты на рабочем сайте. Эту опцию можно использовать, например, когда вы хотите использовать репозиторий Git только для хранения кода.

Включение дополнительных действий развертывания

В большинстве случаев публикации сайта недостаточно для его полного развертывания. Например, при использовании таких платформ, как Ruby on Rails, вам может потребоваться выполнить задачу по переносу данных после развертывания с помощью подобной команды: bin/rails db:migrate .

Plesk предоставляет возможность настроить ряд дополнительных действий, которые будут выполняться каждый раз при развертывании фалов на сайте.

Перейдите на страницу Сайты и домены > Git, нажмите Настройки репозитория, выберите Включить дополнительные действия развертывания и укажите shell-команды, которые должны выполняться каждый раз при развертывании из этого репозитория. Каждую команду нужно начинать с новой строки.

Примечание: Если пользователю запрещен доступ по SSH в Linux, все указанные команды будут выполняться в chrooted-окружении. Домашняя папка системного пользователя подписки является корневой папкой файловой системы для этой подписки, и могут быть запущены только исполняемые файлы из ограниченной среды chroot. Например, если путь к вашему сайту /var/www/vhosts/example.com/httpdocs , то в chrooted-окружении этот путь будет ./httpdocs , таким образом, вы не сможете выполнять команды за пределами одного уровня выше папки /httpdocs .

Просмотр журналов записи изменений в репозиторий

Для просмотра всей истории записи изменений в репозиторий для текущей ветки, перейдите на страницу Сайты и домены > Git и нажмите ссылку Журналы записи изменений в репозиторий. Для каждой записи изменений показывается следующая информация: время, уникальный идентификатор, имя пользователя и сообщение о записи изменений. Нажмите Обновить, чтобы обновить журнал записи изменений.

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

Переименование или удаление репозитория

Вы в любое время можете переименовать репозиторий. Например, завершив развертывание, вы можете захотеть переименовать репозиторий из website-dev в website, чтобы не запутаться. Перейдите на страницу Сайты и домены > Git, нажмите Настройки репозитория, и укажите новое имя в поле Имя репозитория.

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

git remote set-url origin [новый URL]

Например, при переименовании репозитория из example в example1, выполните команду:

git remote set-url origin user1@example.com:~/repos/example1.git

Чтобы удалить репозиторий, нажмите ссылку Удалить репозиторий на странице Сайты и домены > Git. В этом случае Plesk удалит только репозиторий, целевая папка с опубликованными данными останется.

Практическое занятие «Используем клиент GitHub для десктопа»

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

Типичный процесс использования десктопного клиента

В этом разделе мы научимся использовать десктопный клиент GitHub для управления процессом Git.

Note: Вместо работы в Wiki GitHub (как делали в предыдущем разделе по GitHub ), будем работать в обычном Git-репозитории. В Wiki GitHub есть некоторые ограничения, когда дело касается отправки запросов.

Для настройки репозитория Git используя клиента GitHub Desktop:

• Скачаем и установим GitHub Desctop. Запускам приложение и авторизуемся. (По идее у нас уже есть аккаунт на GitHub, но есть нет, то создаем его).
• Заходим на страницу github.com и ищем наш репозиторий, созданный в предыдущем разделе. Открываем именно репозиторий, а не страницу Wiki. (Если не практические занятия из прошлого раздела не сделаны, то создаем новый репозиторий).
• Нажимаем кнопку Clone or download и выбираем Open on desktop

• Открываем приложение GitHub Desktop и переходим в File > Clone Repository .
• В диалоговом окне выбираем Open GitHub Desktop.app. GitHub Desktop должен запуститься с диалоговым окном «Клонировать репозиторий», содержащим запрос, где клонировать репозиторий. При желании локальный путь можно изменить.
• Переходим на вкладку URL и вставляем URL-адрес клона. В поле Local Path выбираем, куда клонировать репозиторий. Например:

• Нажимаем Clone
• Переходим в клонированный репозиторий и, либо добавляем простой текстовый файл с некоторым содержимым, либо вносим изменения в существующий файл.
• Возвращаемся в GitHub Desktop. Видим, что новый файл добавлен список незафиксированных изменений в левой колонке.

В списке измененных файлов зеленый знак + означает добавление нового файла. Желтый круг означает изменения существующего файла.

• В левом нижнем углу клиента GitHub Desktop (где написано Summary и Description) вводим описание коммита и кликаем Commit to master.

Когда мы фиксируем изменения, на левой панели исчезает список незафиксированных изменений. Однако изменения мы зафиксировали только локально. Коммит еще нужно отправить в удаленный (origin) репозиторий. («Origin» — это псевдоним, который относится к удаленному хранилищу.)

• Наверху кликаем Push origin

Если посмотреть репозиторий в сети, то увидим, что внесенные изменения были перенесены в основную ветку в источнике. Можно перейти на вкладку History в клиенте GitHub Desktop (вместо вкладки Changes) или перейти в меню View > Show History, чтобы просмотреть ранее внесенные изменения.

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

Создание ветки

Теперь создадим ветку, внесем изменения и посмотрим как влияют изменения на ветку.

• В GitHub Desktop переходим в Branch > New Branch и создаем новую ветвь. Назовем ее «development» и нажмем Create Branch.

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

• Откроем файл, которые ранее создали и внесем в него изменения, например добавим новую строку с текстом. Сохраним изменения.
• Вернемся в GitHub Desktop и обратим внимание, что на вкладке «Changes» у нас появились новые измененные файлы.

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

• Закоммитим изменения в левом нижнем углу и кликнем на Commit to development.
• Нажимаем Publish branch (в верхней части окна GitHub Desktop), чтобы сделать локальную ветку также доступной в Origin (GitHub). (Всегда существует две версии ветки: локальная версия и удаленная версия.)
• Вернемся в основную ветку (выбираем master в раскрывающемся меню). Затем посмотрим на свой файл (в текстовом редакторе). Стоит обратить внимание, что изменения, внесенные нами во время редактирования в ветке development , не отображаются в основной ветке.

Обычно новую ветку создают, когда вносят значительные изменения в контент. Например, нужно обновить раздел («Раздел X») в своих документах. Возможно, опубликовать другие обновления не нужно, прежде чем публиковать подробные изменения в Разделе X. Если работа была в той же ветке, было бы сложно выборочно загружать обновления для нескольких файлов за пределами Раздела X без отправки обновлений, которые сделали к файлам в разделе Х.

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

Слияние (merge) ветки development с master

Теперь научимся объединять наши ветки.

• В GitHub Desktop переключитесь на ветку, в которую вы хотите объединить ветку development. В селекторе веток выберите ветку master.
• Переходим Branch > Merge into Current Branch
• В окне слияния выбираем ветку development и кликаем Merge development into master

После слияния веток изменения будут отображаться и в файле в ветке master.

• Нажимаем Push origin для отправки изменений в удаленный репозиторий.

После этого наши изменения будут отображены в репозитории на GitHub.

Слияние ветки через pull request

Теперь объединим ветку development с master, используя процесс pull request. Мы притворимся, что клонировали репозиторий разработчика, и хотим, чтобы разработчик влил наше изменение в ветку development. (Другими словами, у нас может нет прав на слияние веток в мастер.) Для этого мы создадим запрос на извлечение (pull request).

• Как выше, переключаемся на ветку development, вносим изменения в содержимое файла, сохраняем и подтверждаем изменения. После внесения изменений нажимаем Push origin, чтобы отправить наши изменения в удаленную версию ветки разработки на GitHub.
• В GitHub Desktop, с выбранной веткой development, переходим в Branch > Create Pull Request.

На сайте GiHub pull request выглядит так:

Стрелка влево (указывающая из ветви development в направлении master) указывает, что запрос на извлечение («PR») хочет объединить ветку development с основной веткой.

• Напишем причину запроса на извлечение и нажмем Create pull request.
• На этом этапе разработчики получат запрос по электронной почте с просьбой объединить их изменения. Попробуем себя в роли разработчика, перейдя на вкладку Pull requests (на GitHub), чтобы проверить и подтвердить запрос. Пока запрос на слияние не вызывает конфликтов, видна кнопка Merge pull request.

• Чтобы увидеть, какие изменения объединяются с мастером, можете щелкнуть вкладку Files changed (которая появляется на дополнительной навигационной панели вверху). Затем кликаем Merge pull request для объединения в ветке и Confirm merge, чтобы завершить объединение.
• Теперь получим обновления, которые мы слили в master ветку, в свою локальную копию. В GitHub Desktop выбираем master ветку и кликаем кнопку Fetch origin. Fetch получает последние обновления из источника, но не обновляет локальную рабочую копию с изменениями.

После нажатия кнопка Fetch origin изменится на Pull Origin.

• Нажимаем на Pull Origin чтобы обновить локальную копию с полученными изменениями.

Проверим файлы и обратим внимание, что обновления, которые изначально были в ветке development, теперь отображаются и в master.

Note: Более подробное руководство по созданию запросов извлечения с использованием интерфейса GitHub см. В разделе Процесс Pull request на GitHub. Работать с Pull Request нужно уметь, если планируется участие в опен-сорс проектах.

Управление конфликтами слияния

Предположим, мы внесли изменения в свою локальную копию файла в хранилище, а кто-то другой изменяет этот же файл, используя интерфейс браузера GitHub.com. Изменения противоречат друг другу. Что происходит?

Когда нажимаем Push origin от клиента GitHub Desktop, увидим сообщение о том, что хранилище было обновлено с момента последнего извлечения:

“The repository has been updated since you last pulled. Try pulling before pushing.” 

Кнопка, которая раньше говорила «Push origin», теперь говорит «Pull origin». кликаем «Pull origin». Теперь получаем еще одно сообщение об ошибке, которое говорит:

“We found some conflicts while trying to merge. Please resolve the conflicts and commit the changes.” 

Если решим зафиксировать свои изменения, то увидим сообщение, которое гласит:

“Please resolve all conflicted files, commit, and then try syncing again.” 

GitHub Desktop отображает восклицательный знак рядом с файлами с конфликтами слияния. Откройте файл конфликта и найдите маркеры конфликта ( >>>>>> ). Например, такие:

>>>>>> c163ead57f6793678dd41b5efeef372d9bd81035 

В командной строке можно запустить git status , чтобы увидеть, какие файлы имеют конфликты.) Содержимое в HEAD показывает локальные изменения. Содержание ниже ======= показывает изменения, внесенные в другом месте.

Устраняем все конфликты, изменив содержимое маркеров, а затем удалив маркеры. Например, обновите содержимое до этого:

This is an edit I made locally. 

Теперь нужно снова добавить файл в Git. В GitHub Desktop внесем изменения в обновленные файлы. Кликаем Push origin. Обновления на локальном компьютере отправляются на удаленный компьютер без каких-либо конфликтов.

Заключение

Чем больше использовать GitHub, тем больше опыта работы с нужными рабочими процессами. Git — это мощная платформа для совместной работы, в которой есть множество команд, рабочих процессов и функций, которые можно использовать для различных сценариев. Несмотря на разнообразие команд и рабочих процессов Git, наиболее используемые сценарии ограничены по объему и доступны для изучения без особых усилий. Довольно скоро такие рабочие процессы станут автоматическими.

Используемые в этом занятии команды в интерфейсе GitHub Desktop можно попробовать и в командной строке. Возможно, что командная строка понравится больше. Но GitHub Desktop может стать хорошей отправной точкой.