Как открыть доступ к репозиторию github
Настройка приватного Git-репозитория
Приватный git-репозиторий – отличный способ скрыть код в процессе разработки. Открытый исходный код, как правило, стремится к статус-кво, но иногда у разработчика есть необходимость запретить свободный доступ к коду ( к примеру, при разработке платного мобильного приложения). Имейте в виду, открытый код может быть прочитан любым пользователем, который знает URL-адрес, используемый для клона.
Одной из основных проблем для многих пользователей является веб-интерфейс репозитория. GitHub на удивление хорошо справляется с этой проблемой. Например, можно использовать приложения Gitosis, GitList или Goblet. Данный вопрос в этом руководстве не рассматривается, но пользователи, привыкшие к работе с графическим интерфейсом, могут установить одно из вышеперечисленных приложений сразу после установки Git-репозитория.
Данное руководство описывает настройку полноценного приватного Git-репозитория при помощи SSH-аутентификации. Как уже говорилось, оно не охватывает использование веб-интерфейса, а лишь объясняет установку Git и настройку доступа к нему.
Для приведения примеров руководство использует хост git.server.com; не забудьте заменить данный хост доменом вашего VPS.
Создание пары ключей SSH
Для начала нужно сгенерировать пару ключей SSH. В системах Mac или Linux для этого достаточно просто ввести следующие команды в терминал (замените адрес электронной почты в коде своим реальным адресом):
Настоятельно рекомендуется установить пароль на файлы ключей, поскольку это обеспечивает дополнительный уровень безопасности. В операционных системах Windows есть отдельные инструменты для генерации пары ключей, например, PuTTY Gen. Но эта программа запрещена в некоторых странах, а потому она идет с оговоркой о необходимости согласовать ее использование с местным законодательством. Уточнив этот момент, можно войти на VPS, создать пару ключей, и скачать id_rsa и id_rsa.pub.
Затем виртуальный выделенный сервер потребует отдельного пользователя для Git. Как правило, для простоты работы такого пользователя называют Git, что и будет сделано в данном руководстве. Но, конечно, для него можно выбрать абсолютно любое имя.
Создание пользователя и установка Git
Войдите на виртуальный выделенный сервер как root*:
*Примечание: некоторые пользователи предпочитают не использовать root для выполнения рутинных задач. В таком случае используется учетная запись с привилегиями sudo.
Создайте нового пользователя (как уже было сказано, необязательно называть его Git) для управления репозиторием.
Затем создайте пароль для пользователя git:
Теперь можно приступать к установке Git; для этого выполните:
apt-get install git
Внесение SSH-ключа в список доступа
На данный момент нужно войти в систему как пользователь git. Используйте эту команду, чтобы перейти к нему:
Примечание: дважды использованный символ «&» объединяет команды; таким образом, система выполняет сначала первую, а затем вторую команду (без необходимости вводить их по отдельности). Тильда в начале пути (
) говорит системе использовать домашний каталог; то есть, в данном случае символ «
» указывает на /home/git/.
Теперь используйте команду cat, которая выведет содержимое файла в командной строке. Также нужно использовать модификатор «>>» (двойная угловая скобка), чтобы иметь возможность работать с полученным результатом, а не просто вывести его на экран. Будьте внимательны: модификатор «>» (одинарная угловая скобка) полностью перепишет содержимое второго указанного файла, а «>>» позволит добавить в него данные. В большинстве случаев рекомендуется использовать «>>», поскольку удалить внесенные изменения всегда проще, чем восстанавливать файл.
Каждый ключ нужно вносить в отдельную строку этого файла. Чтобы добавить только что созданный ключ, введите следующую команду, внеся в нее свои данные:
Теперь можно увидеть внесенный ключ в файле, запустив команду cat на файл authorized_keys:
Чтобы добавить в список доступа другие ключи, используйте их файлы id_rsa.pub и внесите их в файл authorized_keys, как было показано выше.
Создание локального репозитория git
Чтобы создать папку для пустого репозитория Git, введите:
Готово! Пустой git-репозиторий готов к работе.
Использование git-репозитория с локального компьютера
В Linux или Mac OS необходимо изменить URL существующего удаленного репозитория. При наличии локального репозитория, который нужно толкнуть на сервер, используйте эту команду:
git remote set-url origin git@git.server.com:new-project.git
Если это новый репозиторий, используйте:
git init && git remote add origin git@git.server.com:new-project.git
Теперь можно добавлять, закачивать и даже клонировать проект с полной уверенностью в том, что он недоступен другим пользователям.
Но что если проект разрабатывается в команде, и другие разработчики также должны иметь доступ к репозиторию? Дл этого существует простой и эффективный способ: создайте папку с именем каждого пользователя; в домашней папке списка пользователей Git наберите:
Затем, указывая удаленный репозиторий, выполните команду:
Совместная разработка в команде на GitHub
GitHub стал краеугольным камнем для всего программного обеспечения с открытым исходным кодом. Разработчики любят его, сотрудничают с ним и постоянно создают новые великолепные проекты с помощью него. Помимо хостинга вашего кода, главная привлекательность GitHub заключается в использовании его в качестве инструмента совместной работы. В этом уроке давайте рассмотрим некоторые из наиболее полезных функций GitHub, особенно полезных для работы в командах, что делает его еще более эффективным, продуктивным и, самое главное, забавным!
Github разработка в команде
В этом руководстве предполагается, что вы уже знакомы с Git, распределенной системой управления версиями с открытым исходным кодом, созданной Линусом Торвальдсом в 2005 году. Если вам нужна ревизия или поиск в Git, посетите наш предыдущий курс скринкастов или даже несколько статей на эту тему. Кроме того, у вас уже должна быть учетная запись Github, а также некоторые базовые функции, такие как создание репозитория и внесение изменений в Github. Если нет, обратитесь к предыдущим учебникам.
В мире разработки при создании своего проекта работа в команде будет неизбежной. В этом руководстве по совместной разработке на Github мы изучим некоторые из наиболее распространенных инструментов, которые нам обычно нужны при работе с командами разработчиков программного обеспечения. Обсуждаемые инструменты:
Предпочитаете скринкаст?
Если вы предпочитаете скринкаст, то прыгайте чуть ниже, чтобы просмотреть его, а этот учебник используйте в качестве сопутствующих заметок:
Инструмент 1 : Добавление членов команды
Как правило, существует два способа настройки Github для совместной работы:
Organizations
Если вы контролируете несколько команд и хотите установить разные уровни доступа для каждой команды с различными членами и добавить каждого участника в разные репозитории, то организация будет для вас наилучшим вариантом. Любая учетная запись пользователя Github уже может создавать бесплатные организации для репозиториев с открытым исходным кодом. Чтобы создать организацию, просто перейдите на страницу настроек своей организации:
Соавторы
Коллабораторы (соавторы) используются для предоставления возможности «читать + писать» в один репозиторий, принадлежащий личной учетной записи. Чтобы добавить Collaborators (другие личные учетные записи Github), перейдите на страницу https://github.com/[username]/[repo-name]/settings/collaboration :
Инструмент 2: Pull Requests
Давайте теперь рассмотрим основные шаги для pull request.
Инициирование pull request
В Github есть две модели для pull request:
Здесь мы видим рабочий процесс между двумя пользователями ( repo-owner и forked-repo-owner ) для модели Fork and Pull:
Слияние пул реквеста
Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:
Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.
Инструмент 3: Отслеживание ошибок
Давайте рассмотрим некоторые особенности проблем:
Инструмент 4: Аналитика
Понятно, что мы можем тесно связать наш список задач и обновления с нашими кодами.
Графики
Графики предоставляют подробную аналитику, такую как:
Network
Инструмент 5: Управление проектами
Github и Trello
Trello обеспечивает простой, визуальный способ управления задачами. Используя Agile Software Development, карточки Trello могут эмулировать простую виртуальную Kanban Board. В качестве примера мы автоматически создадим карточку Trello всякий раз, когда будет появляться новый пул реквест с помощью Github Service Hooks. Давайте пройдем через все шаги!
Github и Pivotal Tracker
С примерами Trello и Pivotal Tracker ясно, что мы можем тесно связать наш список задач и обновления с нашими коммитами. Это огромная экономия времени при работе в команде, и это повышает точность при связывании задач с точными фиксациями. Хорошей новостью является то, что если вы уже используете другие инструменты управления проектами, такие как Asana, Basecamp и другие, вы также можете создать Service Hooks аналогичным образом. Если для вашего текущего инструмента управления проектами нет существующих сервисных хуков, вы даже можете их создать сами!
Инструмент 6: Непрерывная интеграция
Непрерывная интеграция (CI) является важной частью всех проектов разработки программного обеспечения, с которыми работают команды разработчиков. CI гарантирует, что, когда разработчик выкатывает свой код, автоматическая сборка (включая тесты) быстро обнаруживает ошибки интеграции. Это определенно уменьшает ошибки интеграции и делает быструю итерацию намного более эффективной. В этом примере мы увидим, как можно использовать Travis CI вместе с Github для CI для обнаружения ошибок, а также для рекомендаций слияния, когда проходят все тесты.
Настройка Travis CI
Мы будем использовать простой проект «hello world» для node.js вместе с grunt.js в качестве инструмента сборки для настройки Travis CI проекта. Вот файлы, находящиеся в проекте:
Travis CI и пул реквесты
Раньше, без какого-либо CI в процессе пул реквеста, этапы выполнялись примерно так: 1) создание запроса (2) слияние (3), тестируем все ли работает. Когда Travis CI подключится к пул реквесам, мы сможем инвертировать шаги 2 и 3, что еще больше ускорит принятие решений о том, следует ли сливать изменения, так как Travis даст нам статус билда для каждого пул реквеста. Давайте посмотрим, как это сделать.
Travis CI с Github чрезвычайно полезен для команд из-за автоматических сборок и немедленного уведомления. Это, безусловно, делает цикл исправления ошибок намного короче. Если вы используете Jenkins, еще один популярный инструмент CI, то вы тоже можете настроить сервисные хуки Github.
Инструмент 7: Обзор кода
С каждой фиксацией изменений Github позволяет использовать чистый интерфейс для общих комментариев или даже конкретных комментариев к отдельной строчке кода. Возможность делать комментарии или задавать вопросы по каждой отдельной строке кода очень полезна при проведении обзоров строка за строкой. Чтобы просмотреть встроенные комментарии, установите флажок в верхней части каждой фиксации.
Давайте рассмотрим некоторые шаблоны URL-адресов, которые могут быть использованы, чтобы помочь нам в обзоре кода, быстро предоставив нам различия между фиксациями:
Инструмент 8 : документация
В этом разделе мы рассмотрим два метода создания документации:
Github Wiki
В каждом репозитории может быть создана Github Wiki, и это может оказаться очень удобно иметь в одном репозитории как исходный код, так и документацию для него. Чтобы создать Wiki, просто перейдите на вкладку Wiki в главном заголовке, и вы готовы к созданию страниц с информацией. Сама Wiki имеет собственное управление версиями, и данные могут быть клонированы на наш локальный компьютер для обновлений или даже автономного доступа.
Затем добавьте wiki-подмодуль git в основной репозиторий кода:
Теперь Wiki будет выглядеть как подмодуль в основном проекте с исходным кодом.
Github Hubot
Если коротко, Hubot может сделать процесс ведения документации гораздо приятнее, добавляя уведомление командных обсуждений о важных коммитах.
Итак давайте начнем с настройки Hubot, размещенным на Heroku, и ботом с интерфейсом чата Campfire! Для обоих и Heroku и Campfire есть бесплатные версии, с которым можно начать.
Ознакомьтесь с другими скриптами Hubot, связанными с Github, или если вы хотите написать один, есть крутой учебник по этому поводу! Короче говоря, Hubot может значительно добавить веселья в документировании и уведомлении командных дискуссий о важных коммитах, проблемах и действиях, происходящих с нашими репозиториями на Github. Попробуйте его!
В качестве заключительной заметки о командной работе на Github, вот несколько советов по производительности:
Использование Github не для разработки
Большинство думает использовать Github только для программных проектов. В конце концов, Github был создан специально для создания кода. Но есть некоторые классные репозитории Github, которые используются для проектов, не связанных с кодом, и они были одинаково великолепны для сотрудничества и обсуждения. Поскольку эти проекты также доступны с открытым исходным кодом, и каждый может внести свой вклад, быстро исправлять ошибки, легко сообщать об ошибках и эффективно сотрудничать с единомышленниками. Просто ради интереса, вот некоторые из них:
И интересно, что думает об этом команда Github?
«Мы кайфуем от использования GitHub»
Дополнительные ресурсы
Получайте больше удовольствия от совместной работы!
Таким образом, это был набор инструментов для совместной работы в Github. Большинство из них служат быстрыми аналитическими инструментами или даже автоматизацией, что помогает сэкономить время при работе с двумя или несколькими товарищами по команде. У вас есть больше советов Github для команд? Давайте поделимся ниже!