Как добавить ревьюера в гитхабе

Как оформить профиль на GitHub так, чтобы он работал при поиске работы

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

Я уже более 15 лет управляю процессами создания продуктов — от гипотез до устойчивых продаж. Последние два года вместе с fellow kottans помогаю новичкам и свитчерам приобретать новые технические скиллы в разработке, развивать soft skills и находить первую работу в IT. Часто вижу у людей проблемы с презентацией своих навыков и личных проектов, в частности профиля и репозиториев на GitHub, поэтому и решил написать этот материал.

Сразу договоримся о контексте: речь будет идти о настройке профиля на GitHub для поиска работы.

Нужно ли это

Чаще всего от кандидата на позицию разработчика ожидают определённого уровня технических знаний. Новичкам особенно тяжело: практики мало, опыта прохождения технических интервью тоже не хватает или совсем нет. А ещё прескрининг. Код кандидата, написанный до интервью, может стать конкурентным преимуществом. Тестовые задания дают не только для того, чтобы проверить умение писать алгоритмы и оперировать структурами данных, но и чтобы увидеть подходы к решению задачи, структуру проекта и код. Любой код, доступный на этапе прескрининга, может стать предметом изучения интервьюеров ещё до первой встречи. И кто знает, возможно, вам дадут меньше тестовых заданий или вовсе обойдутся без них. А тесты — это же всегда стресс, сказывающийся на качестве работы.

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

Существуют различные взгляды на открытые портфолио проектов на облачных VCS (GitHub, GitLab и подобных). Многие опытные разработчики считают, что на профиль никто не смотрит (см. Простое решение). Для некоторых тим- и техлидов увидеть code style и способ организации кода в проекте (особенно в отношении кандидата-джуна) лучше, чем услышать 1000 слов на собеседовании. Правильное оформление профиля и двух-трёх наиболее показательных репозиториев на GitHub поможет обойти конкурентов. А когда по итогам цикла собеседований остаётся несколько равноценных кандидатов, то каждый бит информации может оказаться решающим — в том числе и проекты на GitHub.

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

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

Если профиль пустой, возникает закономерный вопрос: зачем в резюме добавлена ссылка на GitHub-профиль и почему в списке проектов — пусто? Ответ «Ну, если надо, то добавлю» — плохой.

Начнём с проектов.

Что показать, если показать нечего

Никто (sic!) не ожидает увидеть уникальный проект на 100500 строк кода. Оценивать, скорее всего, будут уровень владения шаблонами проектирования, стиль кода, способность написать минимальную документацию, навыки работы с Git. Почему это всё важно? Потому что это о коммуникации. Это то, чего будут ожидать от сотрудника, помимо написания собственно кода. Код пишется в первую очередь для других людей.

Разумеется, могут оценить и уровень владения технологиями. Одно дело — прочитать в резюме «CSS3 — средний» или услышать ответ на вопрос «А что ты умеешь в JavaScript?». И совершенно другое — увидеть в репозитории хорошо читаемый код, отражающий действительные технические навыки.

Оговорка для педантов: ясно, что обмануть можно и там, и там. Но в этой статье речь не об этом классе проблем.

Выберите два-три проекта, которые наилучшим образом отражают ваши навыки. Учебные тоже годятся (быстро допили незаконченные). Или добавьте одну-две простых игры типа крестики-нолики, Frogger или Memory Game. Все новички делают что-нибудь такое, но не все завершают и показывают. Не ищите оригинальности — это всё ради демонстрации навыков и умений. Демо не обязательно должны быть сложными, с анимациями, встроенным видео и миллионом визуальных эффектов. Достаточно одной фишки.

Вот отличный пример работы студентки курса по фронтенду, а теперь разработчицы в MacPaw Mary Fedirko — погодное радио (нажми кнопку ON). В этом проекте она продемонстрировала творческий подход не только к написанию «очередного JS-фреймворка», но и к дизайну и внешнему представлению в целом. Нестандартный вид учебного проекта — это и дополнительная мотивация в процессе выполнения (делать подобные интерфейсы в разы интереснее), и повышение вероятности того, что на такой проект работодатель обратит внимание.

Было бы здорово, если бы кто-то сделал ревью вашего кода.

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

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

Еще один совет: лучше учебные репы, чем ноль реп. При прочих равных условиях кандидат с даже «примитивными» проектами выигрывает у кандидата с отсутствующими общедоступными следами деятельности. Репозитории можно удалять, архивировать и сделать приватными — так профиль со временем будет становиться всё более профессиональным.

Оформляем репозиторий

Цель оформления репозитория — показать товар «лицом». В этом контексте проигрывают те, кто оформляет проект в стиле «сами разберитесь, как моё приложение запустить, чтобы увидеть, как оно работает». Потому что это всё может быть очевидно для автора, но не для стороннего наблюдателя.

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

Краткое описание и ссылка на публикацию

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

Начать просто — нажмите кнопку Edit.

В вебе выглядит так:

Источник: kottans stats by Igor Kurkov

Из Description, кстати, формируется содержание тега страницы проекта, if you know what I mean.

Документация

Чаще всего README . md содержит одну только строку: # project-name.

Что должно быть в README . md:

• О чём проект? Например: «A movies database web application», «Rick and Morty universe REST server».
• Зачем этот проект? Например: «I mastered CSS animations, CSS Grid, CSS Flexbox» (пункты, разумеется, оформить отдельными буллет-поинтами).
• Ссылка на демо (да-да, ещё раз повторить то, что уже есть в описании — overcommunication не грех).
• Инструкции по сборке и запуску проекта. Это вот всё git clone … , yarn build … и прочее — как во взрослых проектах.
• Структура проекта, архитектура приложения, API — это тоже показывает навыки, необходимые разработчику.

Пишите всё это в синтаксисе markdown. Так мы демонстрируем владение ещё одним полезным навыком.

Цель этого не только дать читателю хорошее представление о проекте, но ещё показать отношение к документированию (не любить писать документацию можно будет потом) и базовые навыки подготовки документации. Смотрите, например, учебный проект с использованием The Movie Database API.

Источник: Movie Database by Vlad Vorobiov

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

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

Вот так README.md может выглядеть, когда опубликован:

Источник: Git course. Проект на GitHub

Продвинутые техники

Скриншоты, скринкасты

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

А скринкаст в виде гифки сделает демо ещё более наглядным. Пример: описание задачи в курсе по фронтенду. Гифку лучше захостить за пределами GitHub, допустим, на imgur.

Чем сделать такую гифку? Например, oCam for Windows. Можно записать скринкаст с помощью QuickTime для Mac или встроенными средствами Windows 10 (Win+G) и затем сконвертировать с помощью MOV to GIF или MP4 to GIF.

Для записи работы в терминале хорошо подходит asciinema.

Topics

На будущее: topics помогают проекту появиться в поисковых запросах. Какие ключевые слова вписывать? Начните с используемых в проекте технологий: JavaScript, ReactJS, Python, Java, C#, Laravel, PHP, REST, MongoDB, Node, PostgreSQL, SPA, web app, AMP, CSS, HTML. Добавьте два-три ключевых слова о самом проекте: game, casual game, database, movies, weather, demo, educational, tutorial. GitHub ещё что-нибудь подскажет из своего списка.

Источник: React patterns, demo by Vitalii Ovcharenko

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

Промежуточный summary

На хорошо оформленный репозиторий можно дать прямую ссылку в резюме. Указывайте ее прямо в разделе Skills или Education — где релевантно. Это должна быть ссылка не такого вида github.com/username/repo, а аккуратная и лаконичная, хоть и выглядящая немного «по-инженерному», например: react-patterns project. Тут реальный путь скрыт за описанием проекта. Щёлкать по линкам уж все умеют, а читабельность заметно лучше.

Оформляем профиль

Титульная страница профиля на GitHub позволяет быстро оценить активность пользователя. Для ее оформления также можно использовать альтернативную визуализацию (на примере профиля Bohdan Kovalchuk) — прямо берите и вставляйте в резюме чарты.

Но давайте сравним два профиля на GitHub.

Источник: профиль на Github by Aleksey Ivanov

Чем отличается второй:

• не рандомная аватарка;
• есть имя (если профиль — ваше резюме, то чего стесняться?);
• статус явно говорит о том, что Алексей открыт к предложениям о работе;
• коротко описаны скиллы (Front-end, React, NodeJS);
• есть ссылка на профиль в LinkedIn;
• есть 6 отобранных проектов, с которых заинтересованный посетитель и начнёт изучение портфолио.

Зайдите в свой профиль сейчас, нажмите Customize your pins и добавьте хотя бы самых показательных проекты. Затем в настройках профиля заполните всё, что возможно.

Делаем личное портфолио на GitHub

Знаете ли вы, что проект вида username.github.io после публикации доступен, собственно, под таким именем? Вот пример личного сайта-портфолио (проект на гитхабе, Ruslan Sakevych):

Код

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

Стиль кода

Мы уже говорили, что код пишется для других людей? Ещё раз повторим: код пишется для других людей. Это значит, что код должен быть читаемым. Соблюдение стиля кода, принятого в вашем технологическом стеке, адекватный нейминг переменных, классов, функций, модулей и файлов — это всё важно в работе. Если человек этому не следует даже в самых маленьких своих проектах, где он царь и бог, вряд ли можно ожидать, что он будет это хорошо делать в других. Вероятность есть, конечно, но по опыту — очень низкая.

Так что «причешите» код, который планируете показывать. Линтеры вам в помощь (заодно научитесь настраивать, если ещё не умеете). Можно, не стесняясь, брать преднастроенные проекты — Open Source. Например, ESLInt-Prettier-Husky boilerplate для JS фронтенда или EodData CLient (Python, Aleksey Ivanov). Для вашего стека придётся поискать или поспрашивать кого-нибудь.

Коммиты

Комментарии коммитов тоже пишутся для других людей. Комментарии вида «added file», «fixed», «add code» и подобные (осторожно, вредные советы!) говорят о недостаточно хорошо развитых навыках изложения мысли и нелюбви к людям, которые будут читать ваш код. Самое время приобретать правильный навык. И лучше немного помучаться над текстами коммитов в учебных или пет-проектах, чем потом выслушивать от старших по званию коллег ворчливые замечания или вообще не найти желающих сделать код ревью.

Вот один из примеров читабельной истории коммитов: frontend project lvl1 by Sergey Shramko.

Простое решение

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

Итого

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

Свидетельства «очевидцев» из числа моих знакомых разработчиков-новичков:

Евгений, Front-end Developer: «У меня спрашивали про самый интересный проект: что делает, почему так, логику и связи модулей. Ещё открывали другой проект и по нему тоже задавали вопросы. Я уже пару месяцев как трудоустроился. По моему мнению, что сработало: 1. Множество тестовых задач с других собесов, часть из которых опубликовал на гитхабе; 2. Собственные нетипичные и работающие микропроекты».

Лена, Front-end Developer: «Задавали вопросы по моим проектам на нескольких собеседованиях. Смотрели портфолио. На одном просили прокомментировать самый интересный проект из примеров на гитхабе».

А у вас когда-нибудь смотрели портфолио? Помогало ли портфолио при поиске работы?

Что ещё почитать по связанным темам

• Что портит резюме разработчика
• Резюме ІТ-спеціаліста: розбір типових помилок з точки зору HR
• Что писать в резюме, если нет опыта работы
• Что написать в резюме, если нет опыта работы
• Что написать в резюме junior программисту без опыта работы? — Блог Виктора Зинченко
• Идеальное резюме Junior’а: как найти лучшую работу в сфере информационных технологий
• 3 tools to visualize your GitHub profile
• Инструменты для построения онлайн резюме
• DataArt запустил бесплатный сервис улучшения резюме CV Duck
• A Guide to Creating and Hosting a Personal Website on GitHub

Credits

Спасибо команде kottans и персонально Christina Landvytovych, Oleksandr Lapshyn за поддержку и contribution в материалы статьи.

В качестве иллюстраций здесь используются проекты разработчиков, которые так или иначе имеют отношение к комьюнити kottans. Если вам какой-то из проектов понравится, не пожалейте поставить ⭐ на GitHub — вам обязательно воздастся 🙂

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

�� Подобається Сподобалось 7

До обраного В обраному 43

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

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

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

About collaboration in a personal repository

To collaborate with users in a repository that belongs to your personal account on GitHub.com, you can invite the users as collaborators.

If you want to grant more granular access to the repository, you can create a repository within an organization. For more information, see «Access permissions on GitHub.»

Private forks inherit the permissions structure of the upstream repository. This helps owners of private repositories maintain control over their code. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. Only team permissions (not individual permissions) are inherited by private forks.

Inviting a collaborator to a personal repository

You can send an invitation to collaborate in your repository directly to someone on GitHub.com, or to the person’s email address

GitHub limits the number of people who can be invited to a repository within a 24-hour period. If you exceed this limit, either wait 24 hours or create an organization to collaborate with more people. For more information, see «Creating a new organization from scratch.»

1. Ask for the username of the person you’re inviting as a collaborator. If they don’t have a username yet, they can sign up for GitHub. For more information, see «Signing up for a new GitHub account.»
2. On GitHub.com, navigate to the main page of the repository.
3. Under your repository name, click

Settings. If you cannot see the «Settings» tab, select the

dropdown menu, then click Settings.

Further reading

• «Permission levels for a personal account repository»
• «Removing a collaborator from a personal repository»
• «Removing yourself from a collaborator’s repository»
• «Organizing members into teams»

GitHub Code Owners: повышаем эффективность код‑ревью

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

В недавнем обновлении GitHub появилась возможность указать, кто из разработчиков должен проверить код, если были затронуты какие-то определённые файлы. Помимо отдельных разработчиков, в качестве ревьюеров можно назначать команды участников (например @codex-team/frontend). Настраивается все с помощью простого файла.

Как работает файл настройки ревьюеров

Чтобы назначить ответственных, создайте файл CODEOWNERS в корне проекта (или в папке .github/) в следующем формате:

# Линии, начинающиеся с ‘#’ — это комментарии. # Каждая линия — это шаблон файлов, сопровождаемый одним # или несколькими участниками. # Следующие участники будут выбраны ревьюерами по-умолчанию # для всех файлов репозитория. * @specc @talyguryn # Порядок важен. Последний подходящий шаблон имеет высший приоритет. # Если пул-реквест содержит JavaScript файлы, следующие # участники будут назначены ревьюерами. *.js @gohabereg @codex-team/frontend # Вы можете использовать email-адреса. docs/* [email protected]

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

Дополнительный уровень безопасности

В настройках защищенных веток появился пункт «Require review from Code Owners». При его активации будет требоваться одобрение «владельцев кода» для внесения изменений в эту ветку.

Подробнее можно почитать в официальном описании нововведения. А мы продолжим делиться своим опытом и рассматривать новые полезные инструменты.

If you like this article, share a link with your friends

Read more

We talk about interesting technologies and share our experience of using them.

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

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

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

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

Рисунок 109. Раздел «Your repositories»

Рисунок 110. Выпадающее меню «New repository»

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

Рисунок 111. Форма «new repository»

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

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

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

Примечание

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

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

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

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

Рисунок 112. Ссылка на настройки репозитория

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

Рисунок 113. Участники проекта

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

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

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

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

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

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

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

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

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

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

$ curl https://github.com/tonychacon/fade/pull/1.patch | git am

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

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

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

Рисунок 115. Ответы на письма включены в диалог

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

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

Рисунок 116. Кнопка Merge и инструкции по ручному слиянию запроса

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

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

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

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

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

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

$ git ls-remote https://github.com/schacon/blink 10d539600d86723087810ec636870a504f4fee4d HEAD 10d539600d86723087810ec636870a504f4fee4d refs/heads/master 6a83107c62950be9453aac297bb0193fd743cd6e refs/pull/1/head afe83c2d1a70674c9505cc1d8b7d380d5e076ed3 refs/pull/1/merge 3c8d735ee16296c242be7a9742ebfbc2665adec1 refs/pull/2/head 15c9f4f80973a2758462ab2066b6ad9fe8dcf03d refs/pull/2/merge a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head 31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge

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

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

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

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

$ git fetch origin refs/pull/958/head From https://github.com/libgit2/libgit2 * branch refs/pull/958/head -> FETCH_HEAD

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

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

[remote "origin"] url = https://github.com/libgit2/libgit2 fetch = +refs/heads/*:refs/remotes/origin/*

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

[remote "origin"] url = https://github.com/libgit2/libgit2.git fetch = +refs/heads/*:refs/remotes/origin/* fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

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

$ git fetch # … * [new ref] refs/pull/1/head -> origin/pr/1 * [new ref] refs/pull/2/head -> origin/pr/2 * [new ref] refs/pull/4/head -> origin/pr/4 # …

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

$ git checkout pr/2 Checking out files: 100% (3769/3769), done. Branch pr/2 set up to track remote branch pr/2 from origin. Switched to a new branch 'pr/2'

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

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

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

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

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

Рисунок 117. Ручное изменение форка и ветки для запроса слияния

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

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

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

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

Рисунок 118. Напишите @ для упоминания кого-либо

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

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

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

Рисунок 119. Отказ от подписки на проблему или запрос слияния

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

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

Рисунок 120. Настройки центра уведомлений

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

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

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

Рисунок 121. Центр уведомлений

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

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

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

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

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

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

To: tonychacon/fade Message-ID: Subject: [fade] Wait longer to see the dimming effect better (#1) X-GitHub-Recipient: tonychacon List-ID: tonychacon/fade List-Archive: https://github.com/tonychacon/fade List-Post: List-Unsubscribe: . X-GitHub-Recipient-Address: tchacon@example.com

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

Рисунок 122. Создание запроса на слияние при наличии файла CONTRIBUTING

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

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

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

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

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

Рисунок 123. Изменение основной ветки проекта

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

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

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

Рисунок 124. Передача проекта другому пользователю или организации на GitHub

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

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