TriXXXster
New member
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 также есть, куда попадают репозитории, получившие больше всего звезд за ограниченное количество времени (например, сегодня, на этой неделе, в этом месяце).
Попадание на страницу трендов тоже может повлечь за собой сетевой эффект, например, в виде упоминания на других сайтах. Это происходит просто потому, что вы стали более заметны.
Fork (ответвление)
Последний заметный сетевой показатель проекта это количество ответвлений (форков).
Это ключ к работе GitHub, поскольку форк это основа пул-реквеста (Pull Request, PR) – предложения внесения изменений. Любой человек может сделать форк вашего репозитория, внести какие-то изменения, а затем создать пул-реквест, чтобы попросить вас смерджить, слить воедино эти изменения.
Иногда человек, сделавший форк, может так никогда и не попросить вас мерджить что-нибудь. Он может сделать форк просто потому что ему понравился ваш код и он решил добавить что-нибудь поверх него. Ему не нужно, чтобы эти изменения коснулись оригинального репозитория. Также пользователь мог исправить баги, с которыми столкнулся и которые проявились только у него.
Популярный значит лучший
В общем, это все основные показатели популярности проекта. Помимо них полезными сведениями являются также дата последнего коммита и степень участия автора в отслеживании проблем. Основываясь на этих показателях, вы можете определить, стоит ли полагаться на данную библиотеку или программу.
Пул-реквесты (Pull requests)
В предыдущем разделе уже говорилось о том, что такое пул-реквест. Повторим. Человек может сделать форк вашего репозитория, внести изменения, а затем создать пул-реквест (запрос), чтобы попросить вас включить эти изменения в свой репозиторий (смерджить).
В проекте могут быть сотни PR. Обычно, чем популярнее проект, тем больше пул-реквестов в нем будет. Вот пример React:
Когда человек делает пул-реквест, он просматривается основными лицами, занимающимися поддержкой этого проекта.
Количество времени, которое потребуется тому, кто занимается поддержкой проекта, на рассмотрение вашего пул-реквеста, может варьироваться. Оно зависит от масштаба вашего запроса: количества изменений, количества вещей, на которых отразятся эти изменения, сложности затрагиваемого кода. Человек должен убедиться, что предлагаемые вами изменения совместимы с этим проектом.
У проекта может быть четкое расписание изменений, которые должны быть представлены. Люди, занимающиеся его поддержкой, возможно, хотят придерживаться простоты, а вы в своем пул-реквесте предлагаете сложную архитектуру.
Таким образом, пул-реквест не всегда может быть принят быстро, и вообще нет гарантий, что он будет принят.
В приведенном примере React есть пул-реквест, сделанный еще полтора года назад. Это случается вовсехпроектах. Это нормально и для этого могут быть свои причины (из упомянутых выше).
Управление проектами (менеджмент проектов)
Кроме раздела issues, где разработчики получают обратную связь от пользователей, интерфейс GitHub предоставляет и другой функционал, предназначенный для менеджмента проектов.
Например,Projects(Проекты). Это новинка в экосистеме и довольно редко используется, но это доска Kanban, которая помогает упорядочивать возникшие проблемы и необходимые работы.
Wikiпредставляет собой документацию для пользователей. Один из самых впечатляющих вариантов использования Wiki, которые мне доводилось видеть, это– справка по языку Go.
Еще одним вспомогательным инструментом для менеджмента проектов является система отметок этапов (milestones). Это часть раздела issues. Вы можете привязать вашу проблему к определенной метке (например, номеру релиза), что сужает круг поисков.
Раз уж речь зашла о релизах, GitHub усовершенствовал функционал тегов Git, введя релизы (releases).
Тег Git это указатель на определенный коммит. Если все сделано последовательно, то это помогает вам откатиться на предыдущую версию вашего кода, не ссылаясь на конкретные коммиты.
Релиз GitHub основывается на тегах Git и представляет собой полный релиз вашего кода, вместе с Zip-файлами, примечаниями и бинарными цифровыми объектами, которые могут представлять полностью рабочую версию конечного продукта вашего кода.
Теги Git могут создаваться программными средствами (например, с использованием командной строки программы git). Но GitHub-релиз создается вручную с помощью пользовательского интерфейса GitHub. В общем, вы говорите GitHub создать новый релиз и указываете, какие теги вы хотите применить к этому релизу.
Сравнение коммитов
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 также есть, куда попадают репозитории, получившие больше всего звезд за ограниченное количество времени (например, сегодня, на этой неделе, в этом месяце).
Попадание на страницу трендов тоже может повлечь за собой сетевой эффект, например, в виде упоминания на других сайтах. Это происходит просто потому, что вы стали более заметны.
Fork (ответвление)
Последний заметный сетевой показатель проекта это количество ответвлений (форков).
Это ключ к работе GitHub, поскольку форк это основа пул-реквеста (Pull Request, PR) – предложения внесения изменений. Любой человек может сделать форк вашего репозитория, внести какие-то изменения, а затем создать пул-реквест, чтобы попросить вас смерджить, слить воедино эти изменения.
Иногда человек, сделавший форк, может так никогда и не попросить вас мерджить что-нибудь. Он может сделать форк просто потому что ему понравился ваш код и он решил добавить что-нибудь поверх него. Ему не нужно, чтобы эти изменения коснулись оригинального репозитория. Также пользователь мог исправить баги, с которыми столкнулся и которые проявились только у него.
Популярный значит лучший
В общем, это все основные показатели популярности проекта. Помимо них полезными сведениями являются также дата последнего коммита и степень участия автора в отслеживании проблем. Основываясь на этих показателях, вы можете определить, стоит ли полагаться на данную библиотеку или программу.
Пул-реквесты (Pull requests)
В предыдущем разделе уже говорилось о том, что такое пул-реквест. Повторим. Человек может сделать форк вашего репозитория, внести изменения, а затем создать пул-реквест (запрос), чтобы попросить вас включить эти изменения в свой репозиторий (смерджить).
В проекте могут быть сотни PR. Обычно, чем популярнее проект, тем больше пул-реквестов в нем будет. Вот пример React:
Когда человек делает пул-реквест, он просматривается основными лицами, занимающимися поддержкой этого проекта.
Количество времени, которое потребуется тому, кто занимается поддержкой проекта, на рассмотрение вашего пул-реквеста, может варьироваться. Оно зависит от масштаба вашего запроса: количества изменений, количества вещей, на которых отразятся эти изменения, сложности затрагиваемого кода. Человек должен убедиться, что предлагаемые вами изменения совместимы с этим проектом.
У проекта может быть четкое расписание изменений, которые должны быть представлены. Люди, занимающиеся его поддержкой, возможно, хотят придерживаться простоты, а вы в своем пул-реквесте предлагаете сложную архитектуру.
Таким образом, пул-реквест не всегда может быть принят быстро, и вообще нет гарантий, что он будет принят.
В приведенном примере React есть пул-реквест, сделанный еще полтора года назад. Это случается вовсехпроектах. Это нормально и для этого могут быть свои причины (из упомянутых выше).
Управление проектами (менеджмент проектов)
Кроме раздела issues, где разработчики получают обратную связь от пользователей, интерфейс GitHub предоставляет и другой функционал, предназначенный для менеджмента проектов.
Например,Projects(Проекты). Это новинка в экосистеме и довольно редко используется, но это доска Kanban, которая помогает упорядочивать возникшие проблемы и необходимые работы.
Wikiпредставляет собой документацию для пользователей. Один из самых впечатляющих вариантов использования Wiki, которые мне доводилось видеть, это– справка по языку Go.
Еще одним вспомогательным инструментом для менеджмента проектов является система отметок этапов (milestones). Это часть раздела issues. Вы можете привязать вашу проблему к определенной метке (например, номеру релиза), что сужает круг поисков.
Раз уж речь зашла о релизах, GitHub усовершенствовал функционал тегов Git, введя релизы (releases).
Тег Git это указатель на определенный коммит. Если все сделано последовательно, то это помогает вам откатиться на предыдущую версию вашего кода, не ссылаясь на конкретные коммиты.
Релиз GitHub основывается на тегах Git и представляет собой полный релиз вашего кода, вместе с Zip-файлами, примечаниями и бинарными цифровыми объектами, которые могут представлять полностью рабочую версию конечного продукта вашего кода.
Теги Git могут создаваться программными средствами (например, с использованием командной строки программы git). Но GitHub-релиз создается вручную с помощью пользовательского интерфейса GitHub. В общем, вы говорите GitHub создать новый релиз и указываете, какие теги вы хотите применить к этому релизу.
Сравнение коммитов
GitHub предлагает много инструментов для работы с вашим кодом. Сравнение одной ветки с другой это одна из самых важных вещей, которые вам могут понадобиться.