Как поделиться репозиторием на github

Доступ к приватному репозиторию на Github для других участников

У меня есть репозиторий на Github, он приватный. И есть например друг, который хочет его просмотреть, но не редактировать. Как ему предоставить доступ без добавления в команду?

Заходите в настройки репозитория, там есть Collaborators — там и добавляйте друга. К приветному репозиторию вы можете добавить до 3 человек.

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

Заходите в настройки репозитория

1. Settings
2. Repositories
3. Manage access
4. Invite a collaborator
5. Скидывайте ссылку тому, кому дали доступ или приглашения придет на email

Всё ещё ищете ответ? Посмотрите другие вопросы с метками git github или задайте свой вопрос.

Site design / logo © 2022 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2022.6.10.42345

Нажимая «Принять все файлы cookie», вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

6.3 GitHub — Сопровождение проекта

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

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

Давайте создадим новый репозиторий для распространения кода нашего проекта. В панели управления справа нажмите кнопку «New repository» или воспользуйтесь кнопкой + на панели инструментов, рядом с вашим именем пользователя как показано на рисунке Выпадающее меню «New repository».

Это приведёт к открытию формы «New repository»:

Всё, что в действительности нужно сделать, так это указать название проекта, все остальные поля опциональны. Сейчас, просто нажмите кнопку «Create Repository» и ваш новый репозиторий с названием <пользователь>/<имя_проекта> готов.

Так как в репозитории ещё нет кода, GitHub отобразит инструкции о том, как создать совершенно новый репозиторий или подключить существующий Git проект. Здесь мы не будем этого делать; если вам нужно освежить память, смотрите главу Основы Git.

Теперь ваш проект хостится на GitHub и вы можете предоставить ссылку на него любому желающему. Все проекты на GitHub доступны как по HTTP https://github.com/<user>/<project_name> , так по SSH git@github.com:<user>/<project_name> . Git может получать и отправлять изменения по обоим указанным ссылкам, при этом производится контроль доступа на основании учётных данных пользователя, осуществляющего подключение.

Обычно, для общедоступного проекта предпочтительнее использовать HTTPS ссылки, так как это не требует наличия GitHub аккаунта для клонирования репозитория. При этом, для использования SSH ссылки у пользователя должен быть GitHub аккаунт и его SSH ключ должен быть добавлен в ваш проект. Так же HTTPS ссылка полностью совпадает с URL адресом, который пользователи могут вставить в браузер для просмотра вашего репозитория.

Добавление участников

Если вы работаете с другими людьми, которым вы хотите предоставить доступ для отправки коммитов, то вам следует добавить их как «участников». Если Бен, Джефф и Льюис зарегистрировались на GitHub и вы хотите разрешить им делать «push» в ваш репозиторий, то добавьте их в свой проект. Это предоставит им «push» доступ; это означает, что они будут иметь права доступа как на чтение, так и на запись в проект и Git репозиторий.

Перейдите по ссылке «Settings» в нижней части панели справа.

Затем выберите «Collaborators» в меню слева. Напишите имя пользователя в поле для ввода и нажмите кнопку «Add collaborator». Так вы можете добавить неограниченное количество пользователей. Чтобы отозвать доступ, просто нажмите «X» справа от имени пользователя.

Управление запросами на слияние

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

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

Для последующих примеров предположим, что вы «tonychacon» и создали новый проект для Arduino с названием «fade».

Email уведомления

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

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

Если вы видите строку с текстом git pull <url> patch-1 , то это самый простой способ слить удалённую ветку без добавления удалённого репозитория. Это кратко описывалось в Извлечение удалённых веток. Если хотите, то можно сначала переключиться в тематическую ветку и только потом выполнить эту команду для изменений запроса слияния.

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

Взаимодействие по запросу слияния

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

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

Когда вы готовы слить код, вы можете стянуть его себе и слить локально, слить используя команду git pull <url> <branch> , которую мы видели ранее, или добавив ответвлённый репозиторий как удалённый получить и слить изменения.

Если слияние тривиально, то можно просто нажать кнопку «Merge» на сайте GitHub. Это всегда приводит с созданию коммита слияния, даже если доступно слияние перемоткой вперёд. Это значит, что в любом случае создаётся коммит слияния, как только вы нажимаете кнопку «Merge». Как можно увидеть на Кнопка Merge и инструкции по ручному слиянию запроса, GitHub отображает информацию об этом при вызове подсказки.

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

Ссылки на запрос слияния

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

Фактически, GitHub представляет ветки запросов слияния как псевдо ветки на сервере. По умолчанию, они не копируются при клонировании, а существуют в замаскированном виде и вы можете легко получить доступ к ним.

В качестве примера мы используем низкоуровневую команду ls-remote (часто упоминается как «plumbing» команда, более подробно о ней будет рассказано в Сантехника и Фарфор). Обычно, эта команда не используется в повседневных Git операциях, но сейчас поможет нам увидеть какие ссылки присутствуют на сервере.

Если выполнить её относительно использованного ранее репозитория «blink», мы получим список всех веток, тегов и прочих ссылок в репозитории.

Аналогично, если вы, находясь в своём репозитории, выполните команду git ls-remote origin или укажете любой другой удалённый репозиторий, то результат будет схожим.

Если репозиторий находится на GitHub и существуют открытые запросы слияния, то эти ссылки будут отображены с префиксами refs/pull/ . По сути это ветки, но так как они находятся не в refs/heads/ , то они не копируются при клонировании или получении изменений с сервера — процесс получения изменений игнорирует их по умолчанию.

Для каждого запроса слияния существует две ссылки, одна из которых записана в /head и указывает на последний коммит в ветке запроса на слияние. Таким образом, если кто-то открывает запрос на слияние в наш репозиторий из своей ветки bug-fix , которая указывает на коммит a5a775 , то в нашем репозитории не будет ветки bug-fix (так как она находится в форке), при этом у нас появится pull/<pr#>/head , которая указывает на a5a775 . Это означает, что мы можем стянуть все ветки запросов слияния одной командой не добавляя набор удалённых репозиториев.

Теперь можно получить ссылки напрямую.

Эта команда указывает Git: «Подключись к origin репозиторию и скачай ссылку refs/pull/958/head ». Git с радостью слушается и выкачивает всё необходимое для построения указанной ссылки, а так же устанавливает указатель на коммит в .git/FETCH_HEAD . Далее, вы можете слить изменения в нужную ветку при помощи команды git merge FETCH_HEAD , однако сообщение коммита слияния будет выглядеть немного странно. Так же это становится утомительным, если вы просматриваете много запросов на слияние.

Существует способ получать все запросы слияния и поддерживать их в актуальном состоянии при подключении к удалённому репозиторию. Откройте файл .git/config в текстовом редакторе и обратите внимание на секцию удалённого репозитория origin . Она должна выглядеть как-то так:

Строка, начинающаяся с fetch = , является спецификацией ссылок («refspec»). Это способ сопоставить названия в удалённом репозитории и названиями в локальном каталоге .git . Конкретно эта строка говорит Git: «все объекты удалённого репозитория из refs/heads должны сохраняться локально в refs/remotes/origin ». Вы можете изменить это поведение добавив ещё одну строку спецификации:

Последняя строка говорит Git: «Все ссылки, похожие на refs/pull/123/head , должны быть сохранены локально как refs/remotes/origin/pr/123 ». Теперь, если сохранить файл и выполнить команду git fetch , вы получите:

Все запросы слияния из удалённого репозитория представлены в локальном репозитории как ветки слежения; они только для чтения и обновляются каждый раз при выполнении git fetch . Таким образом, локальное тестирование кода запроса слияния становится очень простым:

Особо внимательные из вас заметили head в конце спецификации, относящейся к удалённому репозиторию. Так же на стороне GitHub существует ссылка refs/pull/#/merge , которая представляет коммит, формируемый при нажатии кнопки «merge» на сайте. Это позволяет вам протестировать слияние перед нажатием этой кнопки.

Запросы слияния на запросы слияния

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

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

При открытии запроса на слияние вверху страницы вы увидите меню для выбора целевой и исходной веток. Если нажать кнопку Edit справа, то станет доступным выбор не только исходной ветки, а ещё и форка.

Здесь можно указать вашу новую ветку для слияния с другим запросом слияния или другим форком проекта.

Упоминания и уведомления

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

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

Так же можно упомянуть пользователя, не указанного в выпадающем списке, но с помощью автодополнения это можно сделать быстрее.

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

Если кто-то будет упомянут в запросе слияния или проблеме, то он автоматически «подписывается» и будет получать уведомления о последующей активности. Вы так же будете подписаны на некоторые уведомления если просто откроете запрос слияния или проблему, станете отслеживать репозиторий или если оставите комментарий. Для прекращения отправки вам уведомлений нажмите кнопку «Unsubscribe».

Страница уведомлений

Когда мы говорим «уведомления» в контексте GitHub, мы имеем ввиду способ, которым GitHub пытается связаться с вами в случае возникновения каких-либо событий, настроить который можно несколькими способами. Для просмотра настроек уведомлений перейдите на закладку «Notification center» на странице настроек.

Доступны два вида уведомлений: посредствам «Email» и «Web». Вы можете выбрать один, ни одного или оба, если активно участвуете в событиях отслеживаемых репозиториев.

Web уведомления

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

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

Эти инструменты очень полезны при обработке большого числа уведомлений. Продвинутые пользователи GitHub полностью отключают email уведомления и пользуются этой страницей.

Email уведомления

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

GitHub включает много дополнительных метаданных в заголовки каждого письма, что полезно при настройке различных фильтров и правил сортировки.

Например, если взглянуть на заголовки письма, отправленного Тони в примере Email уведомление о новом запросе слияния, то можно увидеть следующее:

Здесь можно увидеть несколько интересных вещей. Если вы хотите выделить или перенаправить письма конкретного проекта или запроса на слияние, то информация, содержащаяся в заголовке Message-ID , предоставляет вам соответствующие сведения в формате <пользователь>/<проект>/<тип>/<идентификатор> . Для задачи вместо «pull» будет указано «issues».

Заголовки List-Post и List-Unsubscribe , при наличии у вас почтового клиента, который их понимает, позволяют легко написать в список рассылки или отписаться от неё. Это то же самое, что и нажать кнопку «mute» в веб версии уведомлений или «Unsubscribe» на странице задачи или запроса на слияние.

Если включены оба типа уведомлений и ваш почтовый клиент отображает картинки, то при просмотре email версии уведомления, веб версия так же будет отмечена как прочитанная.

Особенные файлы

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

README

Первый — это файл README , он может быть в любом формате, который GitHub в состоянии распознать. Например, это может быть README , README.md , README.asciidoc и так далее. Если GitHub увидит такой файл в вашем исходном коде, то отобразит его на заглавной странице проекта.

Большинство команд используют его для поддержания актуальной информации о проекте для новичков. Как правило, он включает следующее:

Для чего предназначен проект

Инструкции по конфигурации и установке

Правила участия в проекте

В этот файл можно встраивать изображения или ссылки для простоты восприятия информации.

CONTRIBUTING

Следующий файл — это CONTRIBUTING . Если в вашем репозитории будет файл CONTRIBUTING с любым расширением, то GitHub будет показывать ссылку на него при создании любого запроса на слияние.

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

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

Для одного проекта не так уж и много администраторских действий, но есть несколько стоящих внимания.

Изменение основной ветки

Если вы используете в качестве основной другую ветку, отличную от «master», и хотите, чтобы пользователи открывали запросы на слияние к ней, то это можно изменить в настройках репозитория на закладке «Options».

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

Передача проекта

Если вы хотите передать проект другому пользователю или организации на GitHub, то это можно сделать нажатием кнопки «Transfer ownership» в настройках репозитория на закладке «Options».

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

Это действие приведёт не только к передаче репозитория со всеми его подписчиками и звёздами, но и добавит перенаправление с вашего URL на новый. Кроме этого, изменятся ссылки для клонирования и получения изменений из Git, а не только для веб запросов.

Как организовать сотрудничество на GitHub

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

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

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

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

Начните с малого

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

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

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

Если вы получили сообщение, в котором имеется посильная для вас задача, то можете взять ее в работу, а после окончания, послать автору так называемый pull request , или запрос на включение сделанных изменений (о том, как это сделать, мы поговорим чуть ниже).

Изучите экосистему проекта

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

Например, GitHub стандартизовал файл CONTRIBUTING.md (ознакомьтесь для примера с этим документом ). Подобные инструкции поддерживаются людьми, которые обслуживают базы кодов.

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

Теперь, когда вы являетесь частью экосистемы проекта, как же вам все-таки внести изменения?

Использование Pull-Request для внесения изменений

Рабочая среда для внесения изменений в код, сначала может показаться сложной .

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

• Ответвлять выбранный репозиторий в ваш аккаунт;
• Копировать репозиторий на локальную машину;
• Выбирать ветку ( topic branch ) и вносить в неё изменения;
• Переносить изменения из других веток в свою;
• Использовать различные инструменты GitHub, чтобы создавать pull request’ы через обсуждения;
• Применять полученные изменения;
• Pull request сливается с проектом (как правило с основной веткой – master branch ), а topic branch удаляется из репозитария.

Внутри рабочей среды, вы можете увидеть множество отличий между разными проектами. Например, различия в соглашениях о названии тем. Некоторые проекты могут использовать соглашения типа bug_345 , где 345 это идентификатор (ID #) GitHub issue .

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