Github как добавить человека в проект
Перейти к содержимому

Github как добавить человека в проект

  • автор:

Приглашение участников совместной работы в личный репозиторий

Вы можете пригласить пользователей стать участников совместной работы в личном репозитории.

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

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

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

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

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

Приглашение участника совместной работы в личный репозиторий

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

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

Запросите имя пользователя, которого вы приглашаете в качестве участника совместной работы. Если у пользователя еще нет имени пользователя, они могут зарегистрироваться для получения GitHub. Дополнительные сведения см. в разделе Регистрация новой учетной записи GitHub. 1. На GitHub.com перейдите на главную страницу репозитория.

Под именем репозитория щелкните

Параметры. Если вкладка «Параметры» не отображается, выберите раскрывающееся меню

и нажмите кнопку Параметры.

Снимок экрана: заголовок репозитория с вкладками. Вкладка "Параметры" выделена темно-оранжевым контуром.

В разделе «Доступ» боковой панели щелкните

Участники совместной работы.

Щелкните Добавить людей.

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

Нажмите кнопку Добавить ИМЯ в РЕПОЗИТОРИЙ.

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

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

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

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

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

Раздел «Your repositories»

Выпадающее меню «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 уведомление о новом запросе слияния.

Email уведомление о запросе слияния

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

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

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

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

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

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

Email ответ

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

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

Кнопка Merge

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

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

Если у вас много запросов слияния и вы не хотите добавлять пачку удалённых репозиториев или постоянно делать однократный «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 заключается в использовании его в качестве инструмента совместной работы. В этом уроке давайте рассмотрим некоторые из наиболее полезных функций GitHub, особенно полезных для работы в командах, что делает его еще более эффективным, продуктивным и, самое главное, забавным!

Github разработка в команде

Одна вещь, которую я считаю очень полезной, — это интеграция Github Wiki в основной проект исходного кода.

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

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

  1. Добавление членов команды — организация и соавторы
  2. Pull Requests — Отправка и слияние
  3. Отслеживание ошибок — issues Github
  4. Аналитика — Графики и сети
  5. Управление проектами — Trello & Pivotal Tracker
  6. Непрерывная интеграция — Travis CI
  7. Ревью кода — комментарии к строкам и URL-запросы
  8. Документация — Wiki & Hubot

Предпочитаете скринкаст?

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

Инструмент 1 : Добавление членов команды

Как правило, существует два способа настройки Github для совместной работы:

  1. Организации. Владелец организации может создавать множество команд с разными уровнями доступа для различных репозиториев
  2. Сотрудники. Владелец репозитория может добавлять коллабораторов с доступом Read + Write для одного репозитория

Organizations

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

Совместная разработка в команде на GitHub.

Чтобы получить доступ к странице команд для вашей Организации, вы можете просто перейти на http://github.com/organizations/[organization-name]/teams , чтобы просмотреть их или даже посетить https://github.com/organizations/[organization-name]/teams/new Для создания новых команд с тремя уровнями доступа, такими как:

  1. Pull Only: выборка и слияние с другим репозиторием или локальной копией. Доступ только для чтения.
  2. Push and Pull: (1) наряду с обновлением удаленного репозитория. Читайте + Запись.
  3. Push, Pull & Administrative: (1), (2) наряду с правами на информацию о выставлении счетов, созданием команд, а также удаление аккаунтов организации. Чтение + запись + доступ администратора

Совместная разработка в команде на GitHub.

Соавторы

Коллабораторы (соавторы) используются для предоставления возможности «читать + писать» в один репозиторий, принадлежащий личной учетной записи. Чтобы добавить Collaborators (другие личные учетные записи Github), перейдите на страницу https://github.com/[username]/[repo-name]/settings/collaboration :

Совместная разработка в команде на GitHub.

После этого каждый соавтор увидит изменение статуса доступа на странице репозитория. После того, как у нас есть доступ на запись к репозиторию, мы можем сделать git clone , поработать над изменениями, сделать git pull для извлечения и слияния любых изменений в удаленном репозитории и, в конечном счете, git push , для обновления удаленного репозитория с собственными изменениями:

Совместная разработка в команде на GitHub.

Инструмент 2: Pull Requests

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

Давайте теперь рассмотрим основные шаги для pull request .

Инициирование pull request

В Github есть две модели для pull request :

  1. Модель Fork & Pull — используется в общедоступном репозитории, на который у вас нет push-доступа
  2. Share Repository Model — используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется.

Здесь мы видим рабочий процесс между двумя пользователями ( repo-owner и forked-repo-owner ) для модели Fork and Pull:

    Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github:

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Слияние пул реквеста

Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:

    Слияние непосредственно на Github: если мы делаем слияние непосредственно на Github, то убедитесь, что нет конфликтов, и реквест готов к объединению в ведущую ветку. Владелец оригинального хранилища может просто щелкнуть зеленую кнопку «Слить запрос», чтобы сделать это:

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github , который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow , который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.

Инструмент 3: Отслеживание ошибок

Pull Requests — отличный способ внести свой вклад в репозиторий сделав его форк.

В Github центр для отслеживания ошибок — это issues. Несмотря на то, что они в основном предназначены для отслеживания ошибок, также полезно использовать «Issues» следующими способами:

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

Давайте рассмотрим некоторые особенности проблем:

  1. Labels: цветные категории для каждого issue. Они полезны для фильтрации.
  2. Milestones: они относятся к категориям, которые могут быть связаны с каждым issue, и полезны для определения того, какие проблемы необходимо обрабатывать для следующего релиза. Кроме того, поскольку этапы связаны с проблемами, то автоматически обновляется индикатор выполнения при закрытии каждой связанной проблемы.
  3. Search: Автокомплит поиска для issues и milestones

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Инструмент 4: Аналитика

Понятно, что мы можем тесно связать наш список задач и обновления с нашими кодами.

Есть два инструмента, которые дают представление о репозитории — Graphs and Network. Графики Github отображает соавторов и их коммиты, в то время как Github Network обеспечивает визуализацию для каждого участника. Эти аналитики и графики становятся очень мощными, особенно при работе в командах.

Графики

Графики предоставляют подробную аналитику, такую как:

  • Contributors: кто был соавтором? И сколько строк кода они добавляли или удаляли?
  • Commit Activity: В какие недели произошли фиксации в прошлом году?
  • Code Frequency: сколько строк кода было зафиксировано на протяжении всего жизненного цикла проекта?
  • Punchcard: В какое время дня обычно совершаются коммиты?

Совместная разработка в команде на GitHub.

Network

Github Network — это мощный инструмент, который позволяет вам видеть, как коммитит каждый участник и как они связаны друг с другом. Когда мы смотрим на визуализатор целиком, мы видим каждую фиксацию в каждой ветви каждого репозитория, принадлежащего сети. Очень круто!

Совместная разработка в команде на GitHub.

Инструмент 5: Управление проектами

В то время как issues Github имеют возможности управления проектами с помощью Issues и Milestones, некоторые команды могут предпочесть другой инструмент из-за других функций или существующего рабочего процесса. В этом разделе мы увидим, как мы можем связать Github с двумя другими популярными инструментами управления проектами — Trello и Pivotal Tracker . С помощью сервисов Github мы можем автоматизировать задачу обновления с помощью коммитов, проблем и многих других действий. Эта автоматизация помогает не только экономить время, но и повышает точность обновлений для любой команды разработчиков программного обеспечения.

Github и Trello

Trello обеспечивает простой, визуальный способ управления задачами. Используя Agile Software Development , карточки Trello могут эмулировать простую виртуальную Kanban Board . В качестве примера мы автоматически создадим карточку Trello всякий раз, когда будет появляться новый пул реквест с помощью Github Service Hooks. Давайте пройдем через все шаги!

    Откройте свой аккаунт в Trello, если у вас его еще нет, и создайте новую доску Trello.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Github и Pivotal Tracker

Pivotal Tracker — еще один легкий гибкий инструмент управления проектами, в котором планирование на основе истории позволяет команде легко взаимодействовать, мгновенно реагируя на различные изменения и прогресс проекта. Основываясь на текущем прогрессе команды, он также может создавать диаграммы для анализа скорости команды, итераций разработки, релизов и прочего. В этом кратком примере мы автоматически доставим историю, связав ее с коммитом на Github!

    Создайте новый проект в Pivotal Tracker с новой Story которая должна быть сделана.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

С примерами Trello и Pivotal Tracker ясно, что мы можем тесно связать наш список задач и обновления с нашими коммитами. Это огромная экономия времени при работе в команде, и это повышает точность при связывании задач с точными фиксациями. Хорошей новостью является то, что если вы уже используете другие инструменты управления проектами, такие как Asana , Basecamp и другие, вы также можете создать Service Hooks аналогичным образом. Если для вашего текущего инструмента управления проектами нет существующих сервисных хуков, вы даже можете их создать сами !

Инструмент 6: Непрерывная интеграция

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

Настройка Travis CI

Мы будем использовать простой проект «hello world» для node.js вместе с grunt.js в качестве инструмента сборки для настройки Travis CI проекта. Вот файлы, находящиеся в проекте:

  1. Файл hello.js — это проект nodejs. Здесь мы намеренно не будем оставлять точку с запятой, чтобы грант не смог собрать билд:
  2. package.json определяет зависимости:
  3. Инструмент сборки gruntjs имеет для простоты только одну задачу (линтинг) :
  4. .travis.yml — это файл конфигурации Travis, который заставит Travis запускать наши тесты:
  5. Затем войдите в Travis со своей учетной записью Github и включите привязку репозитория под вкладкой репозитория.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Travis CI и пул реквесты

Раньше, без какого-либо CI в процессе пул реквеста, этапы выполнялись примерно так: 1) создание запроса (2) слияние (3), тестируем все ли работает. Когда Travis CI подключится к пул реквесам, мы сможем инвертировать шаги 2 и 3, что еще больше ускорит принятие решений о том, следует ли сливать изменения, так как Travis даст нам статус билда для каждого пул реквеста. Давайте посмотрим, как это сделать.

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

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Travis CI с Github чрезвычайно полезен для команд из-за автоматических сборок и немедленного уведомления. Это, безусловно, делает цикл исправления ошибок намного короче. Если вы используете Jenkins , еще один популярный инструмент CI, то вы тоже можете настроить сервисные хуки Github.

Инструмент 7: Обзор кода

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

Совместная разработка в команде на GitHub.

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

    Compare branches / tags / SHA1: используйте шаблон URL https://github.com/[username]/[repo-name]/compare/[starting-SHA1]. [ending-SHA1] . Вы можете сделать то же самое с веткой или тегами.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Инструмент 8 : документация

В этом разделе мы рассмотрим два метода создания документации:

  1. Формальная документация: Github Wiki для создания документации для исходного кода
  2. Неофициальная документация: Github Hubot документирует обсуждения между членами команды и автоматизирует поиск информации, взаимодействуя с бот-чатом!
  3. Упоминания, ярлыки и эмози

Github Wiki

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

Совместная разработка в команде на GitHub.

Одна вещь, которую я нахожу очень полезной, — это интеграция Github Wiki в основной проект исходного кода, так что мне не нужно поддерживать два отдельных проекта git. Для этого я добавляю Wiki git repo как субмодуль из ветки master. Если вы используете Travis CI или любой другой CI, убедитесь, что инструмент сборки игнорирует подмодуль wiki . Для файла Travis CI .travis.yml добавьте следующее:

Затем добавьте wiki-подмодуль git в основной репозиторий кода:

Теперь Wiki будет выглядеть как подмодуль в основном проекте с исходным кодом.

Совместная разработка в команде на GitHub.

Github Hubot

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

Hubot — это просто бот-чат, который может получать информацию или предоставлять уведомление при подключении к Github коммитам, issues или активности. В команде, которая стремится значительно сократить количество встреч или даже полностью устранить их, Hubot с интерфейсом чата среди членов команды помогает документировать каждую отдельную дискуссию. Это, безусловно, способствует гибкому графику работы, так как никто не должен присутствовать одновременно для обсуждения. Предупреждение: Hubot ужасно вызывает привыкание!

Итак давайте начнем с настройки Hubot, размещенным на Heroku , и ботом с интерфейсом чата Campfire ! Для обоих и Heroku и Campfire есть бесплатные версии, с которым можно начать.

  1. Мы воспользуемся версией Hubot от Github»s Campfire . Если вы хотите, вы можете выбрать адаптеры для других чатов , таких как Skype, IRC, Gtalk и т.д.
  2. Откройте новую учетную запись Campfire только для Hubot, и эта учетная запись создаст новую комнату для чата, в которую все остальные будут приглашены позже.
  3. Разверните Hubot на Heroku с помощью этой инструкции , приведенной на Hubot Wiki. Не волнуйтесь, если URL-адрес приложения heroku дает сообщение Can not GET / , поскольку по умолчанию еще нечего делать .
  4. С учетной записью Hubot Campfire пригласите себя. Теперь войдите в свою учетную запись Campfire и выполните команду Hubot help . Эта команда предоставит вам все доступные команды для hubot.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Совместная разработка в команде на GitHub.

Ознакомьтесь с другими скриптами Hubot, связанными с Github , или если вы хотите написать один, есть крутой учебник по этому поводу ! Короче говоря, Hubot может значительно добавить веселья в документировании и уведомлении командных дискуссий о важных коммитах, проблемах и действиях, происходящих с нашими репозиториями на Github. Попробуйте его!

В качестве заключительной заметки о командной работе на Github, вот несколько советов по производительности:

  1. Упоминания. В любой текстовой области мы можем указать другого пользователя github с @user , и пользователь получит уведомление о комментарии
  2. Клавиши быстрого доступа — нажмите [shift] +? Для доступа к клавишам быстрого доступа Github на любой странице.
  3. Emoji — Используйте список Emoji , Github textareas также поддерживает вставку этих значков. Попробуйте их и повеселитесь со своими товарищами по команде!

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

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

  • Исправления для дома: отслеживание проблем в качестве инструмента мониторинга
  • Книги: Маленькая книга по MongoDB , Основы Backbone
  • Тексты песен: JSConfEU Тексты песен
  • Найти друга: boyfriend_require
  • Наставничество: Wiki
  • Геномические данные: эпидемия Ash Dieback
  • Блоги: CSS Wizardry

И интересно, что думает об этом команда Github ?

«Мы кайфуем от использования GitHub»

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

  • Социальная разработка на GitHub , исследовательская работа Университета Карнеги-Меллона
  • Как Github использует Github для создания Github Зак Холман
  • Секреты Git и Github Зак Холман
  • Новые возможности в Github из блога Github
  • Github Help: пул реквесты , форки репозитория
  • Возможности Github для совместной работы
  • Учебники Nettuts +: Git и Github
  • Повелитель файлов: как Github приручил бесплатное программное обеспечение (и многое другое) Wired

Получайте больше удовольствия от совместной работы!

Таким образом, это был набор инструментов для совместной работы в Github. Большинство из них служат быстрыми аналитическими инструментами или даже автоматизацией, что помогает сэкономить время при работе с двумя или несколькими товарищами по команде. У вас есть больше советов Github для команд? Давайте поделимся ниже!

Add another user to project owners in Github

How can I add another user to project such that the project shows under his name in his Github account too? I don’t want a fork. Two users should host same project in their accounts and this should allow both users to collaborate in the project.

5 Answers 5

You can only add collaborators to your repository. It cannot be «co-owned».

But when someone is added as collaborator to a repo, that repo will be listed in the Your Repositories section ( but the username will be the owner username only)

The only way for doing what you want is to fork the repo and collaborate through pull requests.

Note that you can create an organization ( https://github.com/account/organizations/new ) and achieve a bit of what you want.

Go to repository administration, then to Collaborators section and write Github user name in field.

Repositories-> Click on repository you want to add collaborators-> Click on Settings -> on your left, click on ‘Collaborators’, which is right below ‘Options’ -> search for the person you want to add -> finally click on ‘Add Collaborator’

As it has been said, normally you can only add collaborators to your repository. They would be able to push, but they would not be visible as owners.

If publicity is what you want, create a separate GitHub Organization for your project, and add your partner as co-owner.

Here is an example of how it might look like: https://github.com/lua-nucleo/

To add another user to a github.com repository:

  • Select Settings->Collaborators under the online repository directory.

Here is an example:

enter image description here

Asher's user avatar

This can be managed for repos that are within an organization. From within such repo, go to Settings -> Collaborators and teams, then choose "Add people". Then choose the desired role, in this case "admin".

enter image description here

Note that repos that are not within an organization don’t have these options. In that case, you can go to Settings -> Collaborators, then choose "Add people". In that case, you can only add them as collaborators, not admins. enter image description here

atineoSE's user avatar

    The Overflow Blog
Linked
Related
Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.31.43551

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *