Как развернуть проект из github

Клонирование репозитория

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

1. On GitHub.com, navigate to the main page of the repository.
2. 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 

1. On GitHub.com, navigate to the main page of the repository.
2. 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.

1. On GitHub.com, navigate to the main page of the repository.
2. 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

Развертывание с GitHub на сервер

GitHub, равно как и система контроля версий Git, на которой он основан, это фантастические инструменты для организации работы и взаимодействия в проектах, независимо от того, связаны эти проекты с кодом или нет.

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

Я разделил все эти способы по типам используемых инструментов: отдельно инструменты для автоматического тестирования и отдельно проверяющие развертывание на сервере.

Зачем это нужно?

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

Недостатки автоматизации

Основная проблема с автоматическим развертыванием изменений это и есть автоматическое развертывание изменений. У вас должна быть уверенность в своей команде и в написанном коде. Именно поэтому автоматическое развертывание обычно совмещается с автоматическим тестированием и это отразилось на представленных ниже инструментах.

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

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

Хуки Git

В Git есть набор встроенных хуков (или перехватчиков), которые могут быть использованы для автоматизации и обычно они являются первой остановкой для выполнения каких-либо задач после действий Git. Хуки делятся на серверные и клиентские.

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

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

Хук pre-commit

Клиентский хук запускается до любого другого хука и до коммита любых изменений. Это лучшее место для добавления тестов и прочих проверок вашего кода.

Добавим простой код JavaScript (в котором мы заранее сделали ошибку) в наш небольшой проект :

document.onload = function() < alert("Hello World") >; 

Мы будем использовать JSHint для выявления ошибок в JavaScript (инструкция по установке JSHint).

Переименуем файл hooks/pre-commit.sample (этот файл расположен в скрытом каталоге .git вашего проекта) в hooks/pre-commit и изменим содержимое этого файла на следующее:

#!/bin/sh jshint index.js 

Попытаемся сделать коммит изменений:

git commit -m "adding Javascript file" 

И получим следующее сообщение об ошибке:

index.js: line 5, col 25, Missing semicolon. 1 error 

Добавим недостающую точку с запятой и попытаемся еще раз. Коммит пройдет без каких-либо проблем.

Хук post-receive

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

У меня есть существующий сайт, состоящий из index.html и нескольких страниц еще, которые мы будем использовать в следующих примерах. Вы можете создать свой сайт или использовать пример из демо-репозитория.

Клонируйте репозиторий, используя флаг —bare , чтобы в репозитории была только информация из системы контроля версий, а не наш код:

git clone --bare https://github.com/sitepoint-editors/GitHub-Auto-Deploy.git GitHub-Auto-Deploy.git 

Теперь создадим хук:

cd GitHub-Auto-Deploy.git/hooks vi post-receive 

Добавим в файл с хуком следующие строчки:

#!/bin/sh git --work-tree=/var/www/html --git-dir=/var/repo/GitHub-Auto-Deploy.git checkout -f 

Примечание: указаны рабочие каталоги в Ubuntu, в вашей системе они могут отличаться.

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

Нам надо сделать наш хук выполняемым:

chmod +x post-receive 

На своей локальной машине, клонируйте репозиторий в обычном режиме, используя инструмент по своему выбору и добавьте новый удаленный сервер (не забудьте добавить настройки своего сервера).

git remote add prod ssh://user@domain.com/var/repo/GitHub-Auto-Deploy.git 

Для развертывания на рабочий сервер вместо репозитория введите:

git push prod master 

Если вы посмотрите теперь в каталог var/www/html , то вы найдете там автоматически скопированный файл index.html .

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

Один из вариантов это использование команд rsync или scp в хуке post-receive на GitHub. Другой вариант, особенно, если ваше приложение нуждается в процессе сборки перед запуском (Github ограничивает доступные команды) — это использование хука post-receive для запуска скриптов на сервере приложения, проверяющего код на GitHub (с опцией -f ) и запускающему остальные необходимые команды. Как видите, все стало несколько сложнее, нам пора перейти к следующему набору инструментов.

Автоматическое развертывание непосредственно с GitHub

На GitHub есть документация об автоматизации развертывания на платформы интеграции, некоторые из которых также являются хостинг-провайдерами.

Буду честным, большая часть изученной мной документации оказалась некорректной, неточной или бесполезной, поэтому я добавлю ссылки на документацию нескольких популярных хостинг-провайдеров, а для остальных я предлагаю вам использовать post-receive или методы непрерывной интеграции:

Сервисы непрерывной интеграции

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

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

Рассмотрим самые популярные из них.

Jenkins

Для использования вам надо настроить свой сервер с Jenkins, это даст вам полный контроль над ним, но заставит тратить время на поддержку. К счастью, Jenkins поддерживает многие платформы, в том числе Docker, если вы хотите для начала поэкспериментировать.

Большая часть функциональности Jenkins достигнута за счет плагинов, а благодаря сложившемуся за долгие годы open-source сообществу этих плагинов много. Например, есть плагины для Git, GitHub и Twitter.

Jenkins требует долгой настройки и временами совмещение всех имеющихся инструкций для создания подходящего рабочего процесса требует изучения.

Travis

Инструкции по интеграции с Travis, имеющиеся на GitHub, на данный момент устарели. Но решается это просто: для этого есть документация на сайте Travis.

Travis не требует какой-либо настройки сервера или хостинга, поэтому он подойдет тем, кто не хочет тратить на это время. Тем не менее, расширение его за пределы дефолтных настроек потребует дополнительного конфигурирования. Например, Tweeting требует доступ к веб-хукам.

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

Другие коммерческие сервисы

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

• https://buddy.works/
• https://www.atlassian.com/software/bamboo/
• https://www.jetbrains.com/teamcity/
• https://codeship.com/
• https://circleci.com/
• https://saucelabs.com/
• https://about.gitlab.com/gitlab-ci/
• http://deploybot.com/

Заключение

Надеюсь, это краткое введение разъяснит вам отдельные вопросы, касающиеся работы развертывания. Мы определенно прошли долгий путь со времен отправки файлов на сервер с помощью FTP.

Развертывание локального репозитория Git в Службе приложений Azure

В этом руководстве показано, как развернуть в службе приложений Azure собственное приложение из репозитория Git на локальном компьютере.

Необходимые компоненты

Выполните следующие шаги для изучения данного руководства.

• Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу.
• Установите Git.
• Обеспечьте локальный репозиторий Git кодом, который вы хотите развернуть. Чтобы скачать пример репозитория, выполните следующую команду в локальном окне терминала.

git clone https://github.com/Azure-Samples/nodejs-docs-hello-world.git 

Подготовка репозитория

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

Параметры выполнения	Файлы в корневом каталоге
ASP.NET (только для Windows)	\*.SLN-файлы, \*.CSPROJ-файлы или default.aspx
ASP.NET Core	\*.SLN-файлы или \*.CSPROJ-файлы
PHP	index.php
Ruby (только для Linux)	Gemfile
Node.js	server.js, app.js или package.json со сценарием запуска
Python	PY-файлы, requirements.txt или runtime.txt
HTML	default.htm, default.html, default.asp, index.htm, index.html или iisstart.htm
веб-задания;	/run. в папке App_Data/jobs/continuous для непрерывных веб-заданий App_Data/jobs/triggered для активируемых веб-заданий. См. сведения в документации по веб-заданиям Kudu.
Функции	Ознакомьтесь с разделом Непрерывное развертывание для Функций Azure.

Чтобы настроить развертывание, добавьте в корень репозитория DEPLOYMENT-файл. См. сведения о настройке развертываний и настраиваемом скрипте развертывания.

Если вы используете Visual Studio, позвольте Visual Studio создать репозиторий для вас. Ваш проект будет немедленно готов к развертыванию через Git.

Настойка пользователя развертывания

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

Создание приложения с поддержкой Git

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

Запустите az webapp create с —deployment-local-git параметром. Например:

az webapp create --resource-group --plan --name --runtime "" --deployment-local-git 

Выходные данные содержат URL-адрес следующего вида: https://@.scm.azurewebsites.net/.git . Используйте этот URL-адрес для развертывания приложения на следующем шаге.

Выполните команду New-AzWebApp из корня репозитория Git. Например:

New-AzWebApp -Name

При запуске этого командлета из каталога, который является репозиторием Git, он автоматически создает удаленный репозиторий Git для вашего приложения Службы приложений с именем azure .

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

Настройка существующего приложения

Если вы еще не создали приложение, см. статью Создание приложения с поддержкой Git.

az webapp deployment source config-local-git --name --resource-group

Выходные данные содержат URL-адрес следующего вида: https://@.scm.azurewebsites.net/.git . Используйте этот URL-адрес для развертывания приложения на следующем шаге.

Этот URL-адрес содержит имя пользователя для развертывания области пользователя. При желании вместо этого можно использовать учетные данные области приложения .

Настройте scmType приложения, выполнив командлет Set-AzResource .

$PropertiesObject = @ < scmType = "LocalGit"; >Set-AzResource -PropertyObject $PropertiesObject -ResourceGroupName ` -ResourceType Microsoft.Web/sites/config -ResourceName /web ` -ApiVersion 2015-08-01 -Force 

1. На порталеAzure перейдите на страницу вашего приложения.
2. В меню слева выберите параметры Настройки центра развертывания. Выберите Локальный git в источнике, а затем нажмите кнопку Сохранить.
3. В разделе Local Git скопируйте Git clone URL для последующего использования. Этот URL не содержит никаких учетных данных.

Развертывание веб-приложения

1. В локальном окне терминала измените каталог на корень репозитория Git и добавьте удаленный Git с помощью URL-адреса, полученного из приложения. Если выбранный метод не предоставляет URL-адрес, используйте https://.scm.azurewebsites.net/.git с именем приложения в .

git remote add azure

Изменение ветви развертывания

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

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

git push azure main:master 

az webapp config appsettings set --name --resource-group --settings DEPLOYMENT_BRANCH='main' git push azure main 

Устранение неполадок с развертыванием

При использовании Git для публикации в приложении службы приложений в Azure могут отобразиться следующие распространенные сообщения об ошибках.

Сообщение	Причина	Решение
Unable to access ‘[siteURL]’: Failed to connect to [scmAddress]	Приложение не работает и не запущено.	запуск приложения на портале Azure. Развертывание Git недоступно, когда веб-приложение остановлено.
Couldn’t resolve host ‘hostname’	Неверные сведения об адресе удаленного ресурса Azure.	используйте команду git remote -v , чтобы вывести список всех удаленных репозиториев с соответствующими URL-адресами. Проверьте правильность URL-адреса удаленного репозитория «azure». При необходимости удалите и повторно создайте этот удаленный репозиторий, используя правильный URL-адрес.
No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as ‘main’.	Вы не указали ветвь в процессе git push или не задали push.default значение в .gitconfig .	Выполните команду git push еще раз, указав главную ветвь: git push azure main .
Error — Changes committed to remote repository but deployment to website failed.	Вы отправили локальную ветвь, которая не соответствует ветви развертывания приложения в Azure.	Убедитесь, что текущая ветвь — master . Чтобы изменить ветвь по умолчанию, используйте параметр приложения DEPLOYMENT_BRANCH (см. раздел Изменение ветви развертывания).
src refspec [branchname] does not match any.	Предпринята попытка принудительной отправки в удаленную ветвь Azure, отличную от Main.	Выполните команду git push еще раз, указав главную ветвь: git push azure main .
RPC failed; result=22, HTTP code = 5xx.	эта ошибка может возникнуть при попытке отправить большой репозиторий Git по протоколу HTTPS.	Измените конфигурацию Git на локальном компьютере, чтобы увеличить postBuffer . Например: git config —global http.postBuffer 524288000 .
Error — Changes committed to remote repository but your web app not updated.	Вы развернули приложение Node.js, содержащее файл package.json, в котором указаны дополнительные необходимые модули.	Проверьте npm ERR! сообщения об ошибках, предшествовавшие этой ошибке, для получения дополнительных сведений о сбое. Ниже перечислены известные причины этой ошибки и соответствующие npm ERR! сообщения.

Неправильно сформированный пакет файлов json: npm ERR! Couldn’t read dependencies.

Дополнительные ресурсы

• Сервер сборки службы приложений (документация по проекту Kudu)
• Непрерывное развертывание в Службе приложений Azure
• Пример. Создание веб-приложения и развертывание кода из локального репозитория Git (Azure CLI)
• Пример. Создание веб-приложения и развертывание кода из локального репозитория Git (PowerShell)

Как развернуть проект из github

Table of contents
Как я могу установить git-репозиторий?
Как я могу установить git-репозиторий?

Установка и управление репозиториями git с помощью функции автоматического развёртывания в hPanel

Обновлено больше недели назад
Table of contents

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

Развёртывание

Git-репозиторий, такой как GitHub, можно использовать для развёртывания и установки вашего сайта. Если Вы хотите развернуть репозиторий Git, просто зайдите в панель управления хостингом и перейдите в Хостинг → Управлять → GIT:

В поле Создать новый репозиторий Вы можете настроить параметры развёртывания. Убедитесь, что Вы выбрали правильный Адрес репозитория и Ветку, иначе развёртывание не удастся. Оставьте поле Каталог пустым, и сайт будет развёрнут в корневой папке Вашей учётной записи (/public_html).

Обратите внимание: Каталог пути установки не должен содержать никаких файлов или папок, иначе развёртывание не удастся.

Как только Вы добавите новый репозиторий в учётную запись, вы увидите блок Управление репозиториями с четырьмя кнопками.

Развёртывает уже созданный репозиторий.

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

Показывает выходные данные последней сборки.
Удаляет выбранный репозиторий.

Как использовать webhook URL?

Вы можете использовать webhook URL для автоматического развёртывания, чтобы объединить выбранную ветку git. Webhook URL будет предоставлен Вам, как только Вы нажмёте кнопку автоматического развёртывания.

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

Во время установки Вам будут предоставлены внешние ссылки о том, как создать webhook URL. Эта функция полезна, например, если файл composer.json существует, composer update также будет запускаться автоматически.