Inviting users to join your organization
You can invite anyone to become a member of your organization using their username or email address for GitHub.com.
Organization owners can invite users to join an organization.
Сведения о приглашениях организации
Когда вы приглашаете кого-то стать членом вашей организации, он получает сообщение электронной почты со ссылкой на приглашение. Чтобы присоединиться к организации, приглашенный щелкает ссылку приглашения в сообщении электронной почты.
Для приглашения можно использовать имя пользователя GitHub или адрес электронной почты пользователя.
Примечание: Если вы используете адрес электронной почты для приглашения, приглашенный сможет принять приглашение только в том случае, если адрес электронной почты совпадает с проверенным адресом электронной почты, связанным с личной учетной записью приглашенного в GitHub. Дополнительные сведения см. в разделе Verifying your email address.
Если личная учетная запись приглашенного помечена, приглашенный не сможет принять новые или ожидающие приглашения на присоединение к организациям.
Если у вашей организации есть платная подписка для каждого пользователя, неиспользуемая лицензия должна быть доступна, прежде чем вы сможете пригласить нового участника присоединиться к организации или восстановить бывшего участника организации. Дополнительные сведения см. в разделе About per-user pricing.
Если приглашение не принимается в течение семи дней, срок действия ожидающего приглашения истекает автоматически. После истечения срока действия GitHub больше не будет выставлять счета за ожидающие приглашения.
Если вашей организации требуется, чтобы участники использовали двухфакторную проверку подлинности, то перед тем, как принять приглашение, пользователям необходимо включить двухфакторную проверку подлинности. Дополнительные сведения см. в разделах Requiring two-factor authentication in your organization и Защита учетной записи с помощью двухфакторной проверки подлинности (2FA).
Организации, которые используют GitHub Enterprise Cloud можете реализовать SCIM для добавления, управления и удаления доступа участников организации к GitHub.com с помощью поставщика удостоверений. Дополнительные сведения см. в разделе About SCIM for organizationsв документации по GitHub Enterprise Cloud.
Отправка пользователям приглашений присоединиться к вашей организации
В правом верхнем углу GitHub.com щелкните фотографию профиля, а затем щелкните Ваши организации.
2. Щелкните название своей организации.
1. Под названием организации щелкните
Люди.
На вкладке «Люди» нажмите кнопку Пригласить участника.
1. Введите имя пользователя, ФИО или адрес электронной почты для того пользователя, которого вы хотите пригласить, и нажмите кнопку Пригласить.
1. Если приглашенный пользователь был участником организации в течение последних трех месяцев, укажите, следует ли восстановить его привилегии или начать заново, а затем нажмите кнопку Пригласить и восстановить или Пригласить и начать заново.
1. Если приглашенный пользователь никогда не был участником организации или, если вы очистили его привилегии, выберите для него роль в организации.
1. При необходимости добавьте пользователя в команды в организации.
1. Щелкните Отправить приглашение. 1. Приглашенный человек получит электронное письмо с приглашением в организацию. Чтобы стать членом организации, человек должен принять это приглашение. Можно изменить или отменить приглашение в любое время до того, как его примет пользователь.
Повторная попытка или отмена просроченных приглашений
Срок действия приглашений истекает через 7 дней. Вы можете повторять или отменять приглашения с истекшим сроком действия по одному или массово. В этом представлении также можно найти неудачные приглашения внешним участникам совместной работы.
В правом верхнем углу GitHub.com щелкните фотографию профиля, а затем щелкните Ваши организации.
2. Щелкните название своей организации.
1. Под названием организации щелкните
Люди.
Люди 1. Чтобы просмотреть все просроченные и неудачные приглашения, щелкните Неудачные приглашения в разделе «Разрешения организации» слева.
Чтобы повторить или отменить одно приглашение, щелкните
рядом с предупреждением об истечении срока действия и выберите Повторить приглашение или Отменить приглашение.
Чтобы подтвердить, нажмите кнопку Повторить приглашение или Отменить приглашение во всплывающем окне.
При необходимости, чтобы повторить или отменить несколько приглашений одновременно, установите флажки рядом с приглашениями. Щелкните раскрывающийся список в верхней части списка и выберите Повторить приглашения или Отменить приглашения.
При необходимости, чтобы повторить или отменить все приглашения на странице, установите флажок в верхней части списка и нажмите кнопку Повторить приглашения или Отменить приглашения.
Первоначальные настройки GIT
После инициализации локального репозитория полезно задать некоторые настройки. Они задаются в командной строке Git Bash и хранятся в трех файлах настроек: системных, пользовательских и конкретного репозитория.
Имя и Email
Без этих настроек вы просто не сможете работать, GIT их запрашивает в самом начале в принудительном порядке.
В истории снимков всегда можно просмотреть информацию о каждом пользователе, вносившем изменения: какое у него имя и email. Без настроек имени и email вы просто не сможете выполнять команду commit. Эти данные чисто информативные, они не служат для авторизации, но, тем не менее, они важны.
Задать email для всех своих репозиториев:
Посмотреть текущий email:
Вы не обязаны задавать в конфигурации тот же email, который вы использовали для регистрации на GitHub. Как уже говорилось, эти данные не используются для авторизации. Но все же GitHub автоматически связывает этот email из конфигурации с аккаунтом на GitHub (если он есть в каком-то аккаунте) и подписывает на сайте GitHub пользователя, вносившего изменения. Если же задан несуществующий email, то связи с пользователем GitHub не будет (имя автора снимка на сайте GitHub не будет ссылкой на его аккунт):
Для аутентификации же email и пароль потребуется вводить при отправке данных в удаленный репозиторий (команда push), если обмен данным происходит через HTTPS-протокол. В этом случае откроется окно браузера, в котором надо ввести данные уже от реального GitHub-аккаунта.
Если же обмен данными происходит через SSH-протокол, то для аутентификации обычно используются SSH-ключи, так что имя и пароль тут роли не играют.
Запомнить учетные данные
Это замечание касается работы через HTTPS-протокол.
Чтобы при отправке изменений на GitHub каждый раз не вводить имя и пароль, имеет смысл перед выполнением команды push попросить запомнить ваши данные:
Потом выполнить отправку с указанием имени и пароля:
И уже в следующий раз вводить имя пароль не придется.
Где физически хранится конфигурация
Как уже говорилось, конфигурация хранится в трех файлах. Дело в том, что ее можно задать на уровне системы, на уровне пользователя и на уровне репозитория. Для каждого уровня свой файл. Каждая более узкая конфигурация перекрывает предыдущую. То есть пользовательские настройки перекрывают системные, а настройки конкретного репозитория перекрывают ваши общие настройки пользователя. Вот эти файлы для Windows (хотя лезть в них напрямую возможно не понадобится):
- Системная конфигурация: C:\Program Files\Git\mingw64\etc\gitconfig Задается из командной строки с параметром —system
- Пользовательская конфигурация: C:\Users\Имя\.gitconfig Задается из командной строки с параметром —global
- Конфигурация репозитория: C:\…\hello\.git\config Задается без параметров Просто выполняете команду git config в нужном репозитории. Например, задать имя в текущем репозитории:
Файл .gitignore
Этот файл почти наверняка придется создать в репозитории. Впрочем, его сразу предлагается включить в проект автоматически при создании проекта на GitHub.
В нем задается список неотслеживаемых файлов, которые не надо добавлять в репозиторий. Обычно это скомпилированные, исполняемые файлы, файлы логов и прочие служебные файлы, которым не место в репозитории.
Файл .gitignore обычно хранится в папке репозитория (и желательно его отправить в общий репозиторий на GitHub, чтобы все могли им воспользоваться — если вы его создавали локально).
Содержимое .gitignore
Например, для проекта на Java исключим скомпилированные файлы с расширением .class и файлы с расширением .log:
Примеры .gitignore для каждого языка хранятся тут — поищите, скорее всего не придется составлять его самостоятельно, а только отредактировать под свои нужды.
Что еще надо знать о .gitignore:
- Он не влияет на уже отслеживаемые файлы, только предотвращает попадание новых.
- Может быть несколько файлов .gitignore: в папке, подпапке и т.д. Каждый следующий уровень перекрывает предыдущий.
- Можно создать и глобальный .gitignore, который действует на все ваши репозитории, но этого обычно не требуется
- Шаблоны файлов задают в столбик. Все правила есть в документации.
Чтобы другой пользователь мог вносить изменения в ваш репозиторий, надо дать ему право на запись. Рассмотрим, как сделать это.
Предоставление прав на запись в репозиторий GitHub
Хотя скачивать публичный репозиторий могут все, право на запись вы даете только избранным.
Чтобы пригласить пользователя:
- В настройках репозитория щелкните вкладку Collaborators и введите email или имя пользователя GitHub.
- Добавьте его — ему придет письмо с приглашением участвовать. Если он примет приглашение, то сможет отправлять изменения в ваш репозиторий.
Добавить комментарий Отменить ответ
Прошу прощения: на комментарии временно не отвечаю.
Как принять участие в работе Open Source проектов на GitHub. Краткое руководство для начинающих
На GitHub размещены миллионы Open Source проектов, но для начинающих разработчиков бывает достаточно сложно поначалу разобраться в принципах их работы, а также в интерфейсе сайта. Это краткое руководство поможет участвовать в проектах с открытым кодом, которые размещаются на GitHub.
Адаптированный перевод статьи The beginner’s guide to contributing to a GitHub project. Здесь приведены только общие рекомендации по работе с Open Source из визуального интерфейса GitHub. Обязательно ознакомьтесь с README выбранного вами проекта для уточнения деталей.
Перевод был сделан для платформы курсов по программированию Хекслет
Шаг 0: Выберите проект
На эту тему очень много статей. Мы будем считать, что вы уже выбрали проект и решились на свой первый шаг. Для примера используется работа над реальным PR в проект Хекслет Sicp.
Шаг 1: Создайте рабочую копию на своем компьютере
Прежде всего, вам нужен локальный форк проекта, поэтому нажмите кнопку «Fork» в GitHub.
Это создаст копию репозитория в вашем аккаунте на GitHub. При переходе в вашу копию проекта вы увидите, откуда он был форкнут:
Теперь вам нужна локальная копия, найдите «SSH clone URL» — справа, вверху. Как настроить ssh-доступ к GitHub вы можете узнать на Хекслет в беплатном курсе Введение в Git
Используйте эту ссылку для клонирования проекта на ваш компьютер с помощью терминала. Если вы не знаете, как им пользоваться — на Хекслете есть большой курс по базовым командам в командной строке.
Результат будет выглядеть примерно так:
Перейдите в директорию нового проекта:
Теперь необходимо установить связь локальной копии с оригинальным проектом, чтобы вы могли получать изменения основного проекта и вносить их в свою локальную копию. Сначала перейдите по ссылке в оригинальный репозиторий — она помечена как «forked from» в верхней части страницы GitHub. Это вернет вас на главную страницу проекта на GitHub, где вы сможете найти «SSH clone URL» и использовать его для создания новой связи, которую мы назовем upstream.
Теперь ваша локальная копия проекта связана с двумя репозиториями на GitHub:
origin, который указывает на ваш форк проекта на GitHub. Вы можете читать его, и писать в этот репозиторий.
upstream, который указывает на GitHub-репозиторий основного проекта. Этот репозиторий можно только читать.
Шаг 2: Заставьте его работать на вашей машине
Теперь, когда у вас есть исходный код, запустите его на своем компьютере. Надеюсь, в файле README или INSTALL этих проектов будет документация, как это сделать.
Если у вас все работает, но документация неясна, то улучшение этого раздела должно стать вашим первым PR в проекте. Это одновременно и самый простой и полезный способ войти в проект!
Шаг 3: Сделайте что-нибудь полезное
Это самый приятный этап — внести свой вклад в проект. Начните лучше c исправления ошибки, которая вас раздражает. Либо найдите подходящую в трекере проблем проекта — «Issues». Если вы не уверенны, с чего начать, многие проекты используют ярлык «good first issue» (или его разновидность), чтобы указать, что эту проблему может решить даже новичок в проекте.
Теперь, когда вы выбрали проблему, воспроизведите ее на своей локальной версии проекта. Как только вы воспроизвели проблему, изучите код, чтобы понять, где она возникла. Как только вы нашли проблему в коде, можно переходить к ее устранению.
Ветвление
Важное правило — размещать каждую часть разработки в отдельной ветке. Изучите, какая модель ветвления используется в проекте. Если в документации бранч-стратегия не описана, посмотрите, как называются уже существующие ветки. Вы можете назвать свою ветку как угодно, но важно, чтобы она была осмысленной. Названия веток типа «feature», «bugfix», «hotfix», «update» с указанием на то, что меняется — это лучший вариант.
В нашем примере мы исправляем README.md, поэтому мы создадим ветку readme-update:
В первую очередь мы убеждаемся, что находимся на master-ветке. Затем команда git pull синхронизирует нашу локальную копию с основной веткой проекта, а команда git push синхронизирует ее с нашим форкнутым проектом на GitHub. Наконец, мы создаем новую ветку readme-update.
Теперь вы можете заняться устранением проблемы.
Если в проекте есть тесты, запустите их, чтобы убедиться, что вы ничего не сломали. Вы также можете добавить новый тест, чтобы показать, что ваше изменение устраняет первоначальную проблему.
Убедитесь, что вы исправляете только то, над чем работаете. Не поддавайтесь искушению исправить другие вещи, которые вы видите по пути, включая проблемы форматирования, так как ваш PR, скорее всего, будет отклонен.
Убедитесь, что вы коммитите логичными блоками. Каждый коммит должен быть обоснованным. Прочитайте статью Как правильно составлять описания коммитов и почему это важно.
Шаг 4: Создайте Pull Request
Чтобы создать PR, вам нужно отправить ветку в ваш форк на GitHub, а затем нажать несколько кнопок на GitHub.
Чтобы отправить новую ветку:
В результате будет создана ветка в вашем проекте на GitHub. Флаг -u связывает эту ветку с удаленной, так что в будущем вы сможете просто набрать git push origin в терминале.
Вернитесь в браузер и перейдите к вашему форку проекта (в нашем примере это будет выглядеть вот так, и вы увидите, что ваша новая ветка появилась в верхней части с удобной кнопкой «Compare & pull request»:
Нажмите эту кнопку!
Если вы видите выделенную надпись, как показано ниже:
Нажмите на ссылку, которая приведет вас к файлу CONTRIBUTING проекта, и прочитайте его! Он содержит ценную информацию, как работать с кодовой базой проекта, и поможет вам добиться одобрения вашего вклада.
На этой странице убедитесь, что «base repository» и «base» указывает на правильный репозиторий и ветку. Затем дайте хорошее, краткое название вашему запросу и объясните, почему вы его создали в поле описания. Добавьте соответствующие номера проблем, если они у вас есть.
Если вы прокрутите страницу немного вниз, вы увидите diff с вашими изменениями. Дважды проверьте, что он содержит то, что вы ожидаете.
Как только вы будете уверены, нажмите кнопку «Create pull request» и все — готово.
Шаг 5: Проверка разработчиками проекта
Чтобы ваши изменения были приняты в проект, разработчики должны проанализировать вашу работу. После этого они либо запросят изменения, либо объединят ее с основной веткой (либо отклонят их).
Итоги
Главные этапы работы в Open Source:
Форкни проект и склонируй его на свой компьютер.
Установи связь с основным репозиторием проекта (upstream remote) и синхронизируй с ним локальную копию.
Создавай локальный бранч для каждого логического блока работы.
Внеси изменения, создавай хорошие описания коммитов и читай файл CONTRIBUTING, если он есть.
Синхронизируй изменения со свом форком (origin remote).
Создай Pull Request на GitHub.
Отвечай на все замечания, полученные в ходе код-ревью.
Дополнение от переводчика
Оригинальная статья была написана в 2015 году. С тех пор вышла GitHub cli, и в git появились новые команды. Теперь эти шаги можно сделать ещё проще.
Как принять приглашение в репозиторий github
Мы продолжаем изучать систему контроля версий git. Сегодня разбираемся, как организовать совместную работу над проектом с вашими коллегами.
Git pull
Подключить новых участников к вашему репозиторию можно в меню Settings → Collaborators → Add People.
Мы можем добавлять других участников по их email или никнеймам. Когда они примут наше приглашение, они смогут вносить изменения в проект.
Сымитируем компьютер другого человека, создав вторую папку на нашем компьютере. Назовем ее «Второй участник». Открываем терминал по адресу папки, копируем ссылку на репозиторий на git hub.
Клонируем репозиторий по ссылке: git clone <ссылка на репозиторий>.
Проверим, как называется появившаяся папка с репозиторием: ls.
Заходим в нее: cd git_tutorial.
Включаем отображение веток в терминале: source
/.zchrc. Подробнее про отображение веток мы рассказывали в прошлом уроке.
Представим, что второй участник решил внести изменения. Он открыл файл в редакторе и добавил в начало кода импорт библиотеки datetime: from datetime import datetime. А последней строкой настроил вывод даты: print(«Today: «, datetime.today().strftime(‘%d/%m/%Y’))
Он коммитит изменения в терминале: git commit -a -m «Add datetime».
Заливает их на Github: git push.
Представим, что мы не знаем, что такие изменения были внесены, и продолжаем работать над проектом локально. Открываем проект в редакторе, добавляем одну строку: print(«Our project: Git_Tutorial»).
Открываем терминал по адресу нашей основной папки Git_Tutorial, в которой начинали работать над проектом. Коммитим изменения: git commit -a -m «Project name».
Пытаемся передать изменения на удаленный репозиторий: git push. Не получается. Git пишет, что версия проекта на нашем компьютере не совпадает с версией на удаленном репозитории. Так получилось, потому что другой участник проекта уже внес какие-то изменения.
Чтобы синхронизировать локальную версию с удаленной, git предлагает команду git pull. Применяем ее: git pull.
Видим сообщение о конфликте в файле test.py.
Чтобы разрешить конфликт, переходим в редактор. Зеленым подсвечены наши изменения, синим — изменения, которые добавил в проект кто-то другой.
VSCode предлагает несколько вариантов, в каком виде сохранить код. В нашей ситуации нам подходит принять все изменения. Выбираем accept both changes. Сохраняем изменения в редакторе.
Коммитим изменения в терминале: git commit -a -m «Add project name». Отправляем на GitHub: git push.
Issues
Когда мы работаем в команде, удобно, когда каждый участник понимает, что происходит с кодом и кто какие изменения собирается вносить. Обсуждать развитие проекта, указывать на ошибки в коде, предлагать улучшения удобно во вкладке issues.
Создадим вкладку issue, чтобы обсуждать изменения в проекте с другими участниками. Нажимаем на зеленую кнопку, пишем название: delete input. Добавляем описание: предлагаю убрать input и переписать первую строку вывода, чтобы не вводить имя каждый раз. Здесь используется тот же язык markdown, как и в файле с описанием проекта README.
В описании можем ссылаться на конкретных людей и на конкретные коммиты, для этого нужно использовать их хэш-код. Можно сослаться и на куски кода. Зайдем в наш файл test.py и выберем строку с запросом информации с клавиатуры, который нам кажется неудобным. Нажмем на три точки рядом с выделенными строками, копируем permalink. Вставим ссылку в issue.
Посмотрим в режиме предпросмотре, как выглядит наш Issue. Если все устраивает, можем нажать submit.
Assignees — на кого назначаем вопрос. Можем выбрать любого участника проекта. В нашем проекте пока только мы, поэтому задача назначится на нас. Если вы назначили задачу на кого-то другого, он увидит уведомление об этом на своей странице Git Hub.
Label — тема нашего issue. Выберем bug. Labels можно настроить под себя.
Project и milestones — проекты и вехи. В рамках одного большого репозитория может быть несколько проектов и вех. Разные issue можно привязывать к этим вехам и проектам. Сейчас мы этот шаг пропускаем.
Pull Requests
В командной работе удобно объединять изменения не на локальном репозитории каждого участника, а на удаленном. Для этого существует функция Pull Request, то есть запрос на изменения. Работа выстраивается так: хотим добавить изменения — создаем в проекте на нашем компьютере ветку, в ветке вносим изменения, коммитим их, отправляем запрос на принятие этих изменений на сервер.
Предложенные изменения можно обсудить с другими участниками проекта в комментариях. Если с изменениями все согласны, запрос принимается.
Представим, что и мы решили исправить код, как написано в Issue. Откроем терминал. Создадим ветку для изменений del_input и перейдем в нее: git checkout -b del_input.
Перейдем в редактор и удалим input, изменим приветствие. Сохраним изменения.
Вернемся в терминал и закоммитим изменения: git commit -a -m «Delete input». Отправим изменения на сервер. Так как мы отправляем изменения не с основной ветки, обязательно прописать название удаленного репозиторий (origin) и название ветки, с которой отправляем изменения: git push -u origin del_input. Ветка с изменениями появилась на GitHub.
Внесем еще одно изменение. Вернемся в основную ветку: git checkout main. Создадим новую ветку update_test: git checkout -b update_test.
Перейдем в редактор и внесем новые изменения, сохраним их.
Вернемся в терминал и закоммитим изменения: git commit -a -m «Update test».
Отправим изменения на сервер: git push -u origin update_test.
Как только в удаленном репозитории появляется больше одной ветки, Git Hub предлагает объединить изменения из разных веток с помощью функции Pull Request.
Нажимаем compare and pull request. Base — куда мы переносим изменения, compare — откуда. Сначала заберем изменения из ветки del_input в main. Git Hub сам проверяет можно ли сделать слияние без конфликтов и помечает их галочкой. Если видим галочку, значит можно слить ветки без конфликтов.
Можем добавить какое-то описание к слиянию веток, reviewers — участники команды, которым мы даем доступ к этому pull request. Они могут просматривать его и комментировать. В Assignees можем указать, кому именно адресуем запрос на изменения.
Сейчас мы это пропустим и нажмем create pull request.
Нажав на сообщение о коммите, мы можем посмотреть, какие именно изменения предлагаются. Если у нас есть права на подтверждение pull request, мы можем слить две ветки сразу. Сольем две ветки: нажимаем merge pull request.
Теперь код попал в основную ветку. Ветку, которую мы создавали для изменений можно удалить.
Мы можем не сливать ветки сразу, а дождаться обсуждения с другими участниками проекта. Тогда Pull request будет висеть в соответствующей вкладке.
Попробуем теперь добавить ветку update_test. Нажимаем compare and pull request.
Ветки автоматически не сливаются, возник конфликт. Все равно создаем запрос на изменения. Решить конфликт можно на странице GitHub. Нажимаем resolve conflict.
Приводим код к нужному виду. Нажимаем mark as resolved → commit merge. Теперь ветки можно слить. Все изменения добавятся в основную ветку.
Если возникают ошибки, попробуйте найти решение в интернете. Часто достаточно вбить код ошибки в поисковик и уже в одной из первых ссылок будет решение. Если все же не получается найти ответ, пишите нам в чате в Telegram.