.gif)
TriXXXster
Опытный user
- Регистрация
- 17 Ноя 2018
- Сообщения
- 67
- Реакции
- 1
GitHub это сайт, где размещаются миллиарды строк кода. Это сайт, ежедневно собирающий миллионы разработчиков для сотрудничества и решения проблем с open source-программами.
Короче говоря, это платформа для разработчиков ПО и построена она на основе Git.
Разработчику не избежать в своей работе ежедневного использования GitHub или какого-нибудь другого инструмента на основе Git. С помощью подобных сервисов вы можете размещать в сети собственный код, а также принимать участие в работе с чужими проектами. В данной статье поясняются некоторые ключевые вопросы, касающиеся GitHub, и рассказывается, как использовать его функционал для улучшения своей работы.
Почему GitHub?
Поскольку вы уже знаете, что такое GitHub, вам может быть интересно, зачем вам лично им пользоваться.
Ведь этим проектом, в конечном итоге, рулит частная компания (статья написана до того, как этой частной компанией стал Microsoft, — прим. перев.), получающая доход от размещения чужого кода. Так есть ли причины использовать именно его, а не похожие платформы, например BitBucket или GitLab?
Кроме личных предпочтений и резонов технического плана, есть веский довод в пользу использования GitHub: им пользуются все, а значит, сетевой эффект огромен.
Большинство кодовых баз со временем перешли с других систем контроля версий на Git из-за его удобства. А GitHub, так уж исторически сложилось, вложил много сил в удовлетворение нужд open source-сообщества.
Поэтому сегодня, какую бы библиотеку вы ни искали, чаще всего вы найдете ее на GitHub.
Кроме open source-проектов многие разработчики размещают на GitHub приватные репозитории. Они делают это из-за удобства платформы.
Рассмотрим важные вещи, касающиеся GitHub, которые нужно знать разработчику.
GitHub Issues
GitHub issues это один из популярнейших баг-трекеров (систем отслеживания багов) в мире.
С его помощью собственники репозиториев могут организовывать, размечать и привязывать проблемы к меткам.
Если вы откроете issue (вопрос по проблеме) в чьем-то проекте, то он останется открытым, пока вы сами его не закроете (например, если вам удалось разобраться с этой проблемой), или пока собственник репозитория его не закроет.
Иногда вы получаете определенный ответ, в других случаях вопрос (с проставленными метками относительно его категории) будет оставаться открытым. Разработчик может вернуться к этому вопросу позже, чтобы исправить проблему или усовершенствовать свою кодовую базу на основе вашего отзыва.
По большей части разработчики не получают денег за поддержку своего кода, выпущенного на GitHub, так что не стоит ожидать немедленных ответов. Однако некоторые репозитории с открытым кодом публикуются компаниями, которые предоставляют услуги, основанные на этом коде, предлагают его коммерческие версии с большим функционалом или используют архитектуру на основе плагинов. И поэтому у них есть штатные разработчики, занимающиеся работой с open source-проектами.
Social coding (социальное программирование)
Несколько лет назад логотип GitHub содержал пометку «social coding». Что это означало и действует ли это до сих пор? Определенно действует.
Подписка
На GitHub вы можете подписаться на определенного разработчика или репозиторий. Для этого нужно пройти в профайл пользователя и кликнуть «follow» или нажать кнопку «watch» на репозитории.
В обоих случаях вы будете видеть активность по этим темам на своей панели инструментов. Подписка на пользователя или репозиторий отличается от подписки в Twitter. Здесь вы будете видеть, что люди делают, а не что они говорят.
Звезды
Одно из важных свойств GitHub это возможность дать звезду репозиторию. Это действие помещает его в список репозиториев, которые вы отметили звездами («starred repositories»). Благодаря этому вы можете отслеживать проекты, которыми заинтересовались, и находить похожие проекты.
Это также один из самых важных рейтинговых механизмов. Чем больше звезд у репозитория, тем он популярнее и в целом важнее. Это приводит к тому, что репозиторий становится более заметен в результатах поиска.
Крупные проекты могут набирать десятки тысяч звезд.
На GitHub также есть страница с трендамиhttps://vk.com/away.php?to=https://github.com/trending&cc_key=, куда попадают репозитории, получившие больше всего звезд за ограниченное количество времени (например, сегодня, на этой неделе, в этом месяце).
Попадание на страницу трендов тоже может повлечь за собой сетевой эффект, например, в виде упоминания на других сайтах. Это происходит просто потому, что вы стали более заметны.
Fork (ответвление)
Последний заметный сетевой показатель проекта это количество ответвлений (форков).
Это ключ к работе GitHub, поскольку форк это основа пул-реквеста (Pull Request, PR) – предложения внесения изменений. Любой человек может сделать форк вашего репозитория, внести какие-то изменения, а затем создать пул-реквест, чтобы попросить вас смерджить, слить воедино эти изменения.
Иногда человек, сделавший форк, может так никогда и не попросить вас мерджить что-нибудь. Он может сделать форк просто потому что ему понравился ваш код и он решил добавить что-нибудь поверх него. Ему не нужно, чтобы эти изменения коснулись оригинального репозитория. Также пользователь мог исправить баги, с которыми столкнулся и которые проявились только у него.
Популярный значит лучший
В общем, это все основные показатели популярности проекта. Помимо них полезными сведениями являются также дата последнего коммита и степень участия автора в отслеживании проблем. Основываясь на этих показателях, вы можете определить, стоит ли полагаться на данную библиотеку или программу.
Пул-реквесты (Pull requests)
В предыдущем разделе уже говорилось о том, что такое пул-реквест. Повторим. Человек может сделать форк вашего репозитория, внести изменения, а затем создать пул-реквест (запрос), чтобы попросить вас включить эти изменения в свой репозиторий (смерджить).
В проекте могут быть сотни PR. Обычно, чем популярнее проект, тем больше пул-реквестов в нем будет. Вот пример React:
Когда человек делает пул-реквест, он просматривается основными лицами, занимающимися поддержкой этого проекта.
Количество времени, которое потребуется тому, кто занимается поддержкой проекта, на рассмотрение вашего пул-реквеста, может варьироваться. Оно зависит от масштаба вашего запроса: количества изменений, количества вещей, на которых отразятся эти изменения, сложности затрагиваемого кода. Человек должен убедиться, что предлагаемые вами изменения совместимы с этим проектом.
У проекта может быть четкое расписание изменений, которые должны быть представлены. Люди, занимающиеся его поддержкой, возможно, хотят придерживаться простоты, а вы в своем пул-реквесте предлагаете сложную архитектуру.
Таким образом, пул-реквест не всегда может быть принят быстро, и вообще нет гарантий, что он будет принят.
В приведенном примере React есть пул-реквест, сделанный еще полтора года назад. Это случается во всех проектах. Это нормально и для этого могут быть свои причины (из упомянутых выше).
Управление проектами (менеджмент проектов)
Кроме раздела issues, где разработчики получают обратную связь от пользователей, интерфейс GitHub предоставляет и другой функционал, предназначенный для менеджмента проектов.
Например, Projects (Проекты). Это новинка в экосистеме и довольно редко используется, но это доска Kanban, которая помогает упорядочивать возникшие проблемы и необходимые работы.
Wiki представляет собой документацию для пользователей. Один из самых впечатляющих вариантов использования Wiki, которые мне доводилось видеть, это Go Programming Language GitHub Wikihttps://vk.com/away.php?to=https://github.com/golang/go/wiki&cc_key= – справка по языку Go.
Еще одним вспомогательным инструментом для менеджмента проектов является система отметок этапов (milestones). Это часть раздела issues. Вы можете привязать вашу проблему к определенной метке (например, номеру релиза), что сужает круг поисков.
Раз уж речь зашла о релизах, GitHub усовершенствовал функционал тегов Git, введя релизы (releases).
Тег Git это указатель на определенный коммит. Если все сделано последовательно, то это помогает вам откатиться на предыдущую версию вашего кода, не ссылаясь на конкретные коммиты.
Релиз GitHub основывается на тегах Git и представляет собой полный релиз вашего кода, вместе с Zip-файлами, примечаниями и бинарными цифровыми объектами, которые могут представлять полностью рабочую версию конечного продукта вашего кода.
Теги Git могут создаваться программными средствами (например, с использованием командной строки программы git). Но GitHub-релиз создается вручную с помощью пользовательского интерфейса GitHub. В общем, вы говорите GitHub создать новый релиз и указываете, какие теги вы хотите применить к этому релизу.
Сравнение коммитов
GitHub предлагает много инструментов для работы с вашим кодом. Сравнение одной ветки с другой это одна из самых важных вещей, которые вам могут понадобиться. Или вы можете захотеть сравнить последний коммит с той версией, которую вы используете на данный момент, чтобы увидеть, какие изменения были внесены.
GitHub дает вам возможность делать это с помощью compare view (просмотра изменений). Просто добавьте /compare в конце адреса, после названия репозитория.
Например, https://github.com/facebook/react/comparehttps://vk.com/away.php?to=https://github.com/facebook/react/compare&cc_key=
В этом примере я сравнил React v15.x с v16.0.0-rc, последней версией на момент написания этой статьи, чтобы посмотреть, что изменилось:
С помощью этой функции вы можете видеть коммиты, сделанные между двумя релизами (или теги, или ссылки на коммиты), и существующую разницу, если число изменений меньше разумного количества.
Вебхуки и сервисы
GitHub предоставляет много вспомогательных функций для процесса разработки, например, вебхуки и сервисы.
Вебхуки (Webhooks)
Вебхуки позволяют пинговать внешние сервисы, когда в репозитории происходят определенные события, например, когда пушится код, делается форк или создается/удаляется тег.
Когда происходит событие, GitHub отсылает запрос POST на указанный нами URL.
Распространенным вариантом использования этой функции является пингование удаленного сервера для доставки последнего кода с GitHub, когда мы пушим обновление с нашего локального компьютера.
Мы делаем пуш на GitHub, GitHub сообщает об этом серверу, а сервер забирает его с GitHub.
Сервисы
Сервисы GitHub, а также новые GitHub-приложения, являются сторонними сборками, которые улучшают опыт разработчика или предоставляют какие-то услуги.
Например, вы можете настроить test runner, чтобы тесты запускались автоматически каждый раз, как вы запушите какие-то новые коммиты (используется TravisCIhttps://vk.com/away.php?to=https://travis-ci.org/&cc_key=).
Вы можете настроить непрерывную интеграцию с использованием CircleCIhttps://vk.com/away.php?to=https://circleci.com/&cc_key=.
Можно создать интеграцию Codeclimatehttps://vk.com/away.php?to=https://codeclimate.com/&cc_key= для анализа кода и предоставления отчетов о «техническом долге» и покрытии тестами.
Выводы
GitHub это потрясающий инструмент и сервис, настоящая жемчужина в сегодняшнем наборе инструментов разработчика. Это руководство поможет вам начать его использовать, но, конечно, не может заменить настоящего опыта работы над open source-проектами на GitHub.
Перевод статьи Флавио Копеса «A developer’s introduction to GitHub».
Короче говоря, это платформа для разработчиков ПО и построена она на основе Git.
Разработчику не избежать в своей работе ежедневного использования GitHub или какого-нибудь другого инструмента на основе Git. С помощью подобных сервисов вы можете размещать в сети собственный код, а также принимать участие в работе с чужими проектами. В данной статье поясняются некоторые ключевые вопросы, касающиеся GitHub, и рассказывается, как использовать его функционал для улучшения своей работы.
Почему GitHub?
Поскольку вы уже знаете, что такое GitHub, вам может быть интересно, зачем вам лично им пользоваться.
Ведь этим проектом, в конечном итоге, рулит частная компания (статья написана до того, как этой частной компанией стал Microsoft, — прим. перев.), получающая доход от размещения чужого кода. Так есть ли причины использовать именно его, а не похожие платформы, например BitBucket или GitLab?
Кроме личных предпочтений и резонов технического плана, есть веский довод в пользу использования GitHub: им пользуются все, а значит, сетевой эффект огромен.
Большинство кодовых баз со временем перешли с других систем контроля версий на Git из-за его удобства. А GitHub, так уж исторически сложилось, вложил много сил в удовлетворение нужд open source-сообщества.
Поэтому сегодня, какую бы библиотеку вы ни искали, чаще всего вы найдете ее на GitHub.
Кроме open source-проектов многие разработчики размещают на GitHub приватные репозитории. Они делают это из-за удобства платформы.
Рассмотрим важные вещи, касающиеся GitHub, которые нужно знать разработчику.
GitHub Issues
GitHub issues это один из популярнейших баг-трекеров (систем отслеживания багов) в мире.
С его помощью собственники репозиториев могут организовывать, размечать и привязывать проблемы к меткам.
Если вы откроете issue (вопрос по проблеме) в чьем-то проекте, то он останется открытым, пока вы сами его не закроете (например, если вам удалось разобраться с этой проблемой), или пока собственник репозитория его не закроет.
Иногда вы получаете определенный ответ, в других случаях вопрос (с проставленными метками относительно его категории) будет оставаться открытым. Разработчик может вернуться к этому вопросу позже, чтобы исправить проблему или усовершенствовать свою кодовую базу на основе вашего отзыва.
По большей части разработчики не получают денег за поддержку своего кода, выпущенного на GitHub, так что не стоит ожидать немедленных ответов. Однако некоторые репозитории с открытым кодом публикуются компаниями, которые предоставляют услуги, основанные на этом коде, предлагают его коммерческие версии с большим функционалом или используют архитектуру на основе плагинов. И поэтому у них есть штатные разработчики, занимающиеся работой с open source-проектами.
Social coding (социальное программирование)
Несколько лет назад логотип GitHub содержал пометку «social coding». Что это означало и действует ли это до сих пор? Определенно действует.
Подписка
На GitHub вы можете подписаться на определенного разработчика или репозиторий. Для этого нужно пройти в профайл пользователя и кликнуть «follow» или нажать кнопку «watch» на репозитории.
В обоих случаях вы будете видеть активность по этим темам на своей панели инструментов. Подписка на пользователя или репозиторий отличается от подписки в Twitter. Здесь вы будете видеть, что люди делают, а не что они говорят.
Звезды
Одно из важных свойств GitHub это возможность дать звезду репозиторию. Это действие помещает его в список репозиториев, которые вы отметили звездами («starred repositories»). Благодаря этому вы можете отслеживать проекты, которыми заинтересовались, и находить похожие проекты.
Это также один из самых важных рейтинговых механизмов. Чем больше звезд у репозитория, тем он популярнее и в целом важнее. Это приводит к тому, что репозиторий становится более заметен в результатах поиска.
Крупные проекты могут набирать десятки тысяч звезд.
На GitHub также есть страница с трендамиhttps://vk.com/away.php?to=https://github.com/trending&cc_key=, куда попадают репозитории, получившие больше всего звезд за ограниченное количество времени (например, сегодня, на этой неделе, в этом месяце).
Попадание на страницу трендов тоже может повлечь за собой сетевой эффект, например, в виде упоминания на других сайтах. Это происходит просто потому, что вы стали более заметны.
Fork (ответвление)
Последний заметный сетевой показатель проекта это количество ответвлений (форков).
Это ключ к работе GitHub, поскольку форк это основа пул-реквеста (Pull Request, PR) – предложения внесения изменений. Любой человек может сделать форк вашего репозитория, внести какие-то изменения, а затем создать пул-реквест, чтобы попросить вас смерджить, слить воедино эти изменения.
Иногда человек, сделавший форк, может так никогда и не попросить вас мерджить что-нибудь. Он может сделать форк просто потому что ему понравился ваш код и он решил добавить что-нибудь поверх него. Ему не нужно, чтобы эти изменения коснулись оригинального репозитория. Также пользователь мог исправить баги, с которыми столкнулся и которые проявились только у него.
Популярный значит лучший
В общем, это все основные показатели популярности проекта. Помимо них полезными сведениями являются также дата последнего коммита и степень участия автора в отслеживании проблем. Основываясь на этих показателях, вы можете определить, стоит ли полагаться на данную библиотеку или программу.
Пул-реквесты (Pull requests)
В предыдущем разделе уже говорилось о том, что такое пул-реквест. Повторим. Человек может сделать форк вашего репозитория, внести изменения, а затем создать пул-реквест (запрос), чтобы попросить вас включить эти изменения в свой репозиторий (смерджить).
В проекте могут быть сотни PR. Обычно, чем популярнее проект, тем больше пул-реквестов в нем будет. Вот пример React:
Когда человек делает пул-реквест, он просматривается основными лицами, занимающимися поддержкой этого проекта.
Количество времени, которое потребуется тому, кто занимается поддержкой проекта, на рассмотрение вашего пул-реквеста, может варьироваться. Оно зависит от масштаба вашего запроса: количества изменений, количества вещей, на которых отразятся эти изменения, сложности затрагиваемого кода. Человек должен убедиться, что предлагаемые вами изменения совместимы с этим проектом.
У проекта может быть четкое расписание изменений, которые должны быть представлены. Люди, занимающиеся его поддержкой, возможно, хотят придерживаться простоты, а вы в своем пул-реквесте предлагаете сложную архитектуру.
Таким образом, пул-реквест не всегда может быть принят быстро, и вообще нет гарантий, что он будет принят.
В приведенном примере React есть пул-реквест, сделанный еще полтора года назад. Это случается во всех проектах. Это нормально и для этого могут быть свои причины (из упомянутых выше).
Управление проектами (менеджмент проектов)
Кроме раздела issues, где разработчики получают обратную связь от пользователей, интерфейс GitHub предоставляет и другой функционал, предназначенный для менеджмента проектов.
Например, Projects (Проекты). Это новинка в экосистеме и довольно редко используется, но это доска Kanban, которая помогает упорядочивать возникшие проблемы и необходимые работы.
Wiki представляет собой документацию для пользователей. Один из самых впечатляющих вариантов использования Wiki, которые мне доводилось видеть, это Go Programming Language GitHub Wikihttps://vk.com/away.php?to=https://github.com/golang/go/wiki&cc_key= – справка по языку Go.
Еще одним вспомогательным инструментом для менеджмента проектов является система отметок этапов (milestones). Это часть раздела issues. Вы можете привязать вашу проблему к определенной метке (например, номеру релиза), что сужает круг поисков.
Раз уж речь зашла о релизах, GitHub усовершенствовал функционал тегов Git, введя релизы (releases).
Тег Git это указатель на определенный коммит. Если все сделано последовательно, то это помогает вам откатиться на предыдущую версию вашего кода, не ссылаясь на конкретные коммиты.
Релиз GitHub основывается на тегах Git и представляет собой полный релиз вашего кода, вместе с Zip-файлами, примечаниями и бинарными цифровыми объектами, которые могут представлять полностью рабочую версию конечного продукта вашего кода.
Теги Git могут создаваться программными средствами (например, с использованием командной строки программы git). Но GitHub-релиз создается вручную с помощью пользовательского интерфейса GitHub. В общем, вы говорите GitHub создать новый релиз и указываете, какие теги вы хотите применить к этому релизу.
Сравнение коммитов
GitHub предлагает много инструментов для работы с вашим кодом. Сравнение одной ветки с другой это одна из самых важных вещей, которые вам могут понадобиться. Или вы можете захотеть сравнить последний коммит с той версией, которую вы используете на данный момент, чтобы увидеть, какие изменения были внесены.
GitHub дает вам возможность делать это с помощью compare view (просмотра изменений). Просто добавьте /compare в конце адреса, после названия репозитория.
Например, https://github.com/facebook/react/comparehttps://vk.com/away.php?to=https://github.com/facebook/react/compare&cc_key=
В этом примере я сравнил React v15.x с v16.0.0-rc, последней версией на момент написания этой статьи, чтобы посмотреть, что изменилось:
С помощью этой функции вы можете видеть коммиты, сделанные между двумя релизами (или теги, или ссылки на коммиты), и существующую разницу, если число изменений меньше разумного количества.
Вебхуки и сервисы
GitHub предоставляет много вспомогательных функций для процесса разработки, например, вебхуки и сервисы.
Вебхуки (Webhooks)
Вебхуки позволяют пинговать внешние сервисы, когда в репозитории происходят определенные события, например, когда пушится код, делается форк или создается/удаляется тег.
Когда происходит событие, GitHub отсылает запрос POST на указанный нами URL.
Распространенным вариантом использования этой функции является пингование удаленного сервера для доставки последнего кода с GitHub, когда мы пушим обновление с нашего локального компьютера.
Мы делаем пуш на GitHub, GitHub сообщает об этом серверу, а сервер забирает его с GitHub.
Сервисы
Сервисы GitHub, а также новые GitHub-приложения, являются сторонними сборками, которые улучшают опыт разработчика или предоставляют какие-то услуги.
Например, вы можете настроить test runner, чтобы тесты запускались автоматически каждый раз, как вы запушите какие-то новые коммиты (используется TravisCIhttps://vk.com/away.php?to=https://travis-ci.org/&cc_key=).
Вы можете настроить непрерывную интеграцию с использованием CircleCIhttps://vk.com/away.php?to=https://circleci.com/&cc_key=.
Можно создать интеграцию Codeclimatehttps://vk.com/away.php?to=https://codeclimate.com/&cc_key= для анализа кода и предоставления отчетов о «техническом долге» и покрытии тестами.
Выводы
GitHub это потрясающий инструмент и сервис, настоящая жемчужина в сегодняшнем наборе инструментов разработчика. Это руководство поможет вам начать его использовать, но, конечно, не может заменить настоящего опыта работы над open source-проектами на GitHub.
Перевод статьи Флавио Копеса «A developer’s introduction to GitHub».
