Github — Как найти Open Source для начинающих


Содержание

Как организовать сотрудничество на GitHub

Если вы еще не в курсе, GitHub это очень эффективный способ организации совместной работы над проектами.

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

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

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

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

Не бойтесь начать с малого : вместо того, чтобы пытаться исправить большие ошибки ( баги ) или переписать целый модуль, попробуйте найти недостатки в документации или ошибки кроссплатформенности, или даже простые синтаксические и грамматические ошибки ( пример на GitHub от пользователя mzgol).

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

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

Изучите экосистему проекта

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

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

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

Теперь, когда вы являетесь частью экосистемы проекта, как же вам все-таки внести изменения?

Использование Pull-Request для внесения изменений

Рабочая среда для внесения изменений в код, сначала может показаться сложной .

Первое, что следует уяснить, это важность следования стандартам и соглашениям, принятым в проекте, над которым вы работаете (что уже обсуждалось выше). Стандартная рабочая среда на GitHub достаточно проста и позволяет:

  • Ответвлять выбранный репозиторий в ваш аккаунт;
  • Копировать репозиторий на локальную машину;
  • Выбирать ветку ( topic branch ) и вносить в неё изменения;
  • Переносить изменения из других веток в свою;
  • Использовать различные инструменты GitHub, чтобы создавать pull request’ы через обсуждения;
  • Применять полученные изменения;
  • Pull request сливается с проектом (как правило с основной веткой – master branch ), а topic branch удаляется из репозитария.

Внутри рабочей среды, вы можете увидеть множество отличий между разными проектами. Например, различия в соглашениях о названии тем. Некоторые проекты могут использовать соглашения типа bug_345 , где 345 это идентификатор (ID #) GitHub issue .

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

Шаг 1: Ответвление (Forking)

Ответвление репозитария на GitHub.com

Шаг 2: Клонирование

Клонировать репозитарий можно, используя URL-адрес, показанный на сайдбаре справа:

Шаг 3: Добавление Upstream Remote

Внесите изменения в клонированную директорию и тогда вы сможете добавить upstream remote , то есть указать удаленный репозиторий, с которым будет происходить слияние локальных правок:

Теперь вы сможете вносить изменения локально и синхронизировать их с удаленным репозиторием:

Шаг 4: Выбор ветки (Topic Branch)

Перед внесением изменений, выберите ветку:

Шаг 5: Создание правок

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

Шаг 6: Внесение правок

Далее, необходимо внести изменения, сделанные в ветке вашего проекта:

Шаг 7: Создание Pull Request’а

Наконец, вы можете создать pull request . Для этого, перейдите в вашу ветку репозитария. Там вы увидите надпись « Недавно измененные вами ветки » ( your recently pushed branches ), и если это так, можно выбрать « Сравнить и сделать Pull Request » ( Compare and Pull Request ).

В противном случае, вы можете выбрать вашу ветку из выпадающего списка и нажать « Pull Request » или « Compare » в верхней правой части секции репозитария.

Создание pull request через кнопку « Compare and Pull Request ».

Создание pull request посредством выпадающего списка веток

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

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

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

Как написал работник Github Зак Холман ( Zach Holman ) в документе « How GitHub Uses GitHub to Build GitHub », pull request это обсуждение. Именно в таком ключе они и должны восприниматься; вместо ожидания мгновенного принятия вашей правки, следует ждать её обсуждения.

GitHub Issues + Pull Requests = Дзен управления проектом

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

У Issues много отличных встроенных возможностей, но одна из наиболее важных, это интеграция с pull request’ами . Пользователь может сослаться на issue в своем коммите, просто добавив туда его цифровой ID.

Этот коммит автоматически пометит issue №3 как закрытый, когда соответствующий pull request будет принят. Данный способ автоматизации делает GitHub прекрасным инструментом для управления процессом разработки.

Поиск других способов взаимодействия

Зачастую, большие open-source проекты имеют преимущество при совместной работе над ними нескольких людей.

Не заблуждайтесь думая, что единственным способом внести вклад в проект является использование pull request’ов .

Например, такой проект, как Ruby on Rails , был известен своим сообществом; оно отвечало на вопросы на форумах и IRC-чатах, чтобы помочь повысить осведомленность об этом фреймворке, а также помочь направить его развитие путем обсуждения идей и найденных ошибок.

Такие способы взаимодействия обычно представлены форумами и чатами. Но не только: это могут быть почтовые рассылки, аудио- и видеоконференции, которые могут помочь определить направление развития проекта и создать живое, продуктивное сообщество вокруг проекта. Без такого сообщества, pull request’ы не эффективны.

Все зависит от отношения

Запомните, что проекты с открытым кодом возглавляются людьми, для которых преумножение и распространение знаний является самым важным. Участие в таких проектах будет более эффективным, если вы будете иметь правильное отношение, смысл которого заключен в следующем вопросе: « Чем я могу помочь? », который отличается от отношения « Помогу, чем смогу ».

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

Заключение

Если вы заинтересовались разработкой open-source проектов, то это прекрасно! Если вы решились принять участие в одном из них, то не забудьте о правильном отношении и принципе « начни с малого ». Это приблизит вас к моменту, когда вы увидите свое имя в только что присоединенном к проекту pull request’е .

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

Потенциал GitHub и мир open-source продолжают свой рост каждый день; начните сотрудничать с другими разработчиками и станьте частью этого мира!

Данная публикация представляет собой перевод статьи « How to Collaborate On GitHub » , подготовленной дружной командой проекта Интернет-технологии.ру

Как присоединиться к opensource-разработке? [закрыт]

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

Закрыт по причине того, что не по теме участниками LEQADA, Vladimir Glinskikh, Aslan Kussein, torokhkun, xaja 6 ноя ’15 в 5:32 .

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

  • «Вопросы-опросники запрещены на Stack Overflow на русском. Для получения ответа, перефразируйте ваш вопрос так, чтобы на него можно было дать однозначно правильный ответ.» – LEQADA, Vladimir Glinskikh, Aslan Kussein, torokhkun, xaja

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

3 ответа 3

Для того, чтобы стать полноценным участником опен-сорсного проекта надо получить статус коммиттера. Путь к получению статуса коммиттера довольно долгий и муторный. Рекомендованный способ это:

  1. Сначала стать контрибутором (то есть человеком вносящим какой-то вклад). Обычно это написание какой-нить статейки в wiki проекта. Лучше всего начать с перевода какого-то раздела документации на русский :)
  2. Полезно на этом этапе выкачать бинарники проекта, погонять и найти баг. Далее надо сделать баг-репорт. У каждого проекта своя система отслеживания багов: часто это что-то вроде Bugzilla или какие-нибудь новомодные веб системы.
  3. Далее подробно изучаем стиль кодирования принятый в проекте. Обычно руководители проектов оч. придирчивы к стилю кодирования. Шаг влево-шаг вправо расстрел на месте
  4. Изучаем список багов проекта. Выбираем целевой баг который вы будет фиксить. Лучше всего взять какой-нибудь легонький бажочек не критический и не дай бог new feature — корифеи проекта все равно растерзают по каким-нибудь идейным соображениям
  5. Делаем чекаут исходников прожекта (обычно это SVN или Git) — естественно надо изучить целевой VCS — особливо место где рассказывается про транк и ветки репозитория
  6. Фиксим баг и выкладываем его либо в виде отдельной ветки в VCS (если это дозволяется правилами проекта) или создаем patch файлик который постится в специальное место проекта.
  7. Если все пройдет удачно то с энной попытки ваш коммит будет принят и внедрен в trunk (основной ствол разработки) проекта.
  8. Несколько таких успешных багфиксов и можно уже подавать заявку на получение статуса коммиттера.

Как использовать GitHub для поиска разработчиков

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

Начнем с азов: что такое Github?

Github – крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Количество пользователей на GitHub превышает 32 миллиона в месяц.

Это место, где разработчики могут хранить свой код, делиться им с другими и заниматься совместной разработкой в open source (например, Ruby on Rails).

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

Проще говоря, выкладывание кода на Github фактически равноценно выкладыванию фотографий или других материалов в Facebook и Instagram.

Найм на Github: чему можно научиться?

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

Профиль разработчика на Github – кладезь информации.

С первого взгляда можно увидеть ник кандидата, текущего работодателя, местоположение и email, но если копнуть чуть глубже:

Вебсайты

Сюда включены блоги, проекты и прочие ссылки, которые кандидаты решили выставить (отличная возможность узнать больше об их работах и интересах!)

Подписчики


Количество подписчиков разработчика на Github – хороший показатель его уровня и репутации среди разработчиков открытого ПО.

2-10 подписчиков – хорошо, 11-25 – очень хорошо, 26-75 – прекрасно, а те, у кого больше 75 подписчиков – просто звёзды (осторожно, таких людей очень сложно нанять!)

Вклад

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

Посмотрите, встречаются ли ключевые слова, относящиеся к языкам программирования, которые использует человек (к примеру, можно увидеть слово “rails”, если человек делал вклад в проект Ruby on Rails).

Репозитории

Раздел репозиториев содержит открытые проекты, которые разработчик выкладывает на Github, а также проекты, которые были скопированы (“форкнуты”).

Для измерения популярности проектов разработчика необходимо проверить, сколько людей отметили или “форкнули” их (форк или отметка показывает, что другие разработчики считают его ценным).

“Форк” репозитория создаёт его копию. Это позволяет тому, кто форкнул, изменять изначальный код и использовать его в своих проектах.

Понятие свободного доступа к идеям и коду – сама суть сайтов свободного программного обеспечения вроде Github (если код был создан для частного использования, на сайте его не выкладывают).

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

Пошаговое руководство поиска:

1. Создайте учётную запись

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

2. Проведите поиск

При поиске на Github нужно учитывать 3 основных параметра.

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

Язык: какие именно навыки кандидата вам необходимы?

Местоположение: если вы не ищете человека на удалённую работу, местоположение – важный параметр поиска.

Вот несколько примеров, как можно совместить эти условия в поиске:

language:ruby on rails location:moscow followers:5..10

language:javascript location:moscow followers:

Как продвигать компанию и искать разработчиков при помощи open source. Опыт белорусов из топа GitHub

Андрей Грабовский, сооснователь Epicmax, рассказал на Medium о своём опыте продвижения компании при помощи open source проектов. Один из проектов его команды, помогающий ускорить разработку веб-приложений за счёт готовых компонентов, попал в топ GitHub в августе 2020 года, а другой, набор загрузочных анимаций для веб-разработчиков, в декабре. Приводим его свежие выводы и предысторию.

Привлечение новых клиентов — одна из сложнейших задач для небольших аутсорсинговых компаний. И решить её можно различными способами. Одни работают с несколькими постоянными клиентами и не особо стремятся расширяться. Другие заваливают Upwork предложениями в надежде заполучить перспективный проект. Третьи создают отдел продаж, который изо дня в день занимается холодными звонками и email-рассылкой. Но из тысячи лидов до подписания контракта доходят, как известно, лишь единицы.

Есть и другой способ. Сложный, рискованный, но поистине увлекательный и вдохновляющий.

Предыстория

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

Одна из компаний, на которую я работал, достаточно долго находилась в состоянии застоя. Многие разработчики оставались не задействованы во внешних проектах. Мы часами рассылали предложения на Upwork, но почти впустую. И тогда мы решили создать шаблон админ-панели на ThemeForest. Разработка шла туго, версий было создано бесчисленное множество, и ни одна из них не прошла проверку (даже на wrapbootstrap).

Но мы не сдались и пошли другим путём. Больше года назад мы сделали проект полностью некоммерческим и залили исходный код на GitHub. Проект получил более 7000 звёзд. Потом выпустили ряд других успешных open-source продуктов, и что самое важное, компания преодолела кризис и начала стремительно развиваться. Было больше не нужно искать новых клиентов: они стали сами приходить к нам.

В конце 2020 года я ушёл из той компании, а летом 2020-го открыл свою. Здесь я собираюсь применять те тактики продвижения open-source продуктов, которым научился на предыдущем месте.

Цукерберг рекомендует:  C++ - помогите переписать с языка python на C++

Схема продвижения проектов на GitHub

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

1. Польза. Людям нравятся продукты, которые решают их проблемы и упрощают жизнь.

2. Популярность. Иногда много шумихи поднимается вокруг не особо полезных, но зато хорошо «раскрученных» или просто очень модных технологических новинок.

3. Дизайн. Некоторые продукты как две капли воды похожи на сотни других, но выигрывают за счёт более привлекательного интерфейса.

Допустим, у вас есть качественный продукт. Теперь нужно завоевать внимание пользователей. Но как?

Для начала, написать броский readme-файл.

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

Итак, у вас есть потрясающий продукт и отличный readme.

А сейчас самое главное

Страницу трендовых продуктов на GitHub просматривают тысячи пользователей в день. Если туда попал ваш продукт, то у него есть все шансы на успех. Но для этого он должен набрать по крайней мере 130 звёзд (необходимое количество ежедневно меняется), чем больше, тем лучше. Цель — достичь вершины списка и продержаться там как можно дольше.

Несколько советов, которые помогут вам попасть в список:

1. Подумайте, какие ресурсы лучше задействовать для продвижения. Reddit, Hackernews и им подобные — весьма полезные инструменты, но не забывайте, что на любом ресурсе есть свои (обычно неформальные) правила публикации.

2. Попросите помощи у друзей. Чем больше друзей поставят звёздочку вашему проекту, тем быстрее он попадёт в топ.

3. Выберите правильный день. Помните, что на выходных посещаемость GitHub падает. Наиболее благоприятные для запуска проекта дни недели — понедельник, вторник и среда. Но в зависимости от ресурса это могут быть другие дни.

4. Выберите правильное время. Ваши друзья и остальные пользователи Reddit (или любой другой платформы) могут находиться в разных часовых поясах — это тоже нужно учитывать.

5. Постоянная обратная связь. Обязательно отвечайте на все вопросы и постоянно поддерживайте связь с аудиторией. Чем активнее вы будете общаться с пользователями, тем проще вам будет их удержать.

И последнее

Популярный open-source репозиторий позволит вам достичь больших высот. Не останавливайтесь на достигнутом! Ресурс ProductHunt даёт возможность сделать продукт более доступным клиенту. Нужно, чтобы продукт заметило как можно больше людей, а «сарафанное радио» сделает своё дело. Включите проект в своё портфолио — вы ведь соглашение о конфиденциальности не подписывали!

Один из наших проектов вышел на 4-е место в топе за 23 часа. Это лучшее подтверждение того, что описанные техники на самом деле работают.

Полгода спустя

Итак, спустя полгода на счету команды уже есть два успешных open source продукта, и мы хотим поделиться своими выводами.

Когда шесть месяцев назад мы создавали Epicmax, у нас практически ничего не было. Ничего, кроме незаконченной админ-панели, которой занимались, в общем-то, просто в своё удовольствие, и годного профиля на UpWork, а денег едва бы хватило на месячную зарплату. Так себе ситуация, прямо скажем.Но мы были уверены, что всё изменится, как только наш шаблон станет полноценным open source продуктом, и решили полностью сосредоточиться на нём. Тогда в команде было пять человек, и если бы за месяц мы не допилили админку и не нашли клиентов, то пришлось бы бросить её и идти работать на крупные компании — не очень радужная перспектива.

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

К началу августа мы доделали Vuestic. Все жутко устали, но были счастливы. Потом был релиз, дела пошли в гору. Vuestic занял 4 место в тренде и собрал много положительных отзывов — и за них мы очень благодарны.

Как нам помог Vuestic

Как я уже писал, для компаний по разработке сайтов качественный open source продукт — гораздо более эффективный инструмент для привлечения клиентов, чем тонны холодных мейлов или предложений на апворке. Хотя мне по-прежнему приходится этим заниматься. И меня это по-прежнему бесит.

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

Да и найти хороших разработчиков стало намного легче. Мы живём в Беларуси, и сфера ИT здесь занимает особое место. Почти все остальные отрасли в упадке, но разработчики софта процветают. Молодым компаниям, естественно, очень непросто заполучить хороших специалистов. Сначала никто не хотел с нами работать (оно и понятно: нам было ещё нечего предложить). Но теперь наш профиль на GitHub говорит сам за себя. В декабре к нам присоединился один разработчик, и привлекли его именно наши open source проекты.

В поисках нового open source продукта

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

К концу осени мы отдохнули и решили возобновить работу, но взяться за что-нибудь попроще админки. Просмотрели кучу статей и репозиториев на GitHub, и у нас появилась идея: коллекция клёвых спиннеров, которые будут доступны и просто в виде куска html/css кода, и как адаптируемые компоненты vue.js. На GitHub много подобных библиотек. Мы хотели, чтобы наши отличались простотой использования. Хотите опробовать спиннер в своём приложении, просто скопируйте код – и всё!

В середине декабря мы запустили Epic Spinners. Люди его заметили, он попал в топ на GitHub и за месяц получил более 1200 звёзд. Мы очень радовались, но всё же немного устали.

Что дальше?

Январь 2020. Мы начинали без каких-либо ресурсов и имели один незаконченный проект. Нас всё ещё пятеро, но теперь мы популярны на GitHub, у нас два отличных открытых продукта и пара довольных клиентов. Мы полны сил и готовы двигаться вперёд. Мы верим в open source проекты. У нас нет чётких планов, но мы уверены, что 2020 год будет наполнен знаменательными достижениями, которыми мы будем гордиться.

Начинаем работу github

Сразу скажу, что эта «статья» больше для новичков чем для старожил и я буду рад если дадут дельный совет.

Намедни, недавно решил отвлечься от основной работы и всё таки примкнуть к open source сообществу и написать свой велосипед и заодно разобраться с тем как работать

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

Нам нужно установить git. Мануал курить отсюда

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

Потом необходимо создать репозиторий

После успешного создания репозитория вам выдадут адрес репозитория. Сохраните его.

Учтите что мы создали пустой репозиторий без файлов.

Далее заходите в терминал (*nix системы) или в коммандную строку Windows.

Переходите в директорию где бы вы хотели клонировать наш репозиторий к себе локально.

А потом выполняйте команду

и создайте там пустой файл. Мы создадим файл README.md — это файл описания нашего проекта

И добавим его в отслеживание git`ом введя команду в терминале

Теперь этот файл у нас будет отслеживатся git`ом и его изменения будут фиксироваться с помощью git`a

Далее нам нужно наш локальный репозиторий «подружить» с нашим удаленным.

Во втором скриншоте мы видели адрес нашего репозитория на github, скопируйте его и выполните команду

Адрес репозитория, само собой, меняйте на свой.


Что-бы удостовериться что вы правильно «соединили» локальный репозиторий с удаленным введите команду

Теперь нам нужно закоммитить (проще говоря — зафиксировать) наши изменения (добавление файла README.md в репозиторий).

А теперь все изменения нам нужно залить на удаленный репозиторий

У вас должно запросить логин и пароль к github как на скрине выше (при вводе пароля будет казаться что вы ничего не вводите — но это всё вранье)

Теперь давайте перейдем в наш репозиторий через браузер и посмотрим — есть ли там наш файл

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

Спасибо всем кто заинтерисовался.

Если будет интересно то в следующий раз опишу как сделать так чтобы composer видел ваш githubовский репозиторий.

P. S. Конструктивная критикая, советы приветствуются

Как принять участие в движении Open Source

Перевод статьи «How to Contribute to Open Source Project».

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

Сообщество open source дает начинающим разработчикам потрясающую возможность показать себя. Участвуя в различных проектах, разработчики могут улучшать свои навыки, а также находить вдохновение и получать поддержку единомышленников. Но самое главное, они могут доказать, что способны создавать фантастические вещи для других людей.

В этой статье мы разберем, зачем вообще разработчикам участвовать в движении open source, как это сделать и какие проекты стоит выбирать. Статья предназначена для начинающих разработчиков, желающих влиться в сообщество.

Зачем разработчику принимать участие в проектах с открытым исходным кодом?

Давайте посмотрим, что может мотивировать программиста поучаствовать в опенсорсном проекте.

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

Во-вторых, open source дает вам хороший старт. Новички могут начать с малого — исправления мелких багов или написания части документации. Принимая участие в опенсорсных проектах, начинающие разработчики будут учиться писать чистый код (т. е., читаемый и поддерживаемый). Когда разработчики понимают, что их код будет выставлен на всеобщее обозрение, они больше фокусируются на том, чтобы этот код было легко понять и поддерживать.

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

В-третьих, вы получаете возможность стать частью активного сообщества, познакомиться с единомышленниками, найти поддержку. Кроме того, если вы фрилансер и при этом активно участвуете в open source, вы повышаете свои шансы быть замеченным потенциальными заказчиками (работодателями).

Вывод: основные причины, по которым разработчики принимают участие в открытых проектах, это желание быть замеченным, стремление отточить свои навыки и стать частью сообщества. А теперь давайте разберем, на что следует обратить внимание, прежде чем начать активно вливаться в движение open source.

Что следует учесть начинающему контрибутору

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

Язык программирования

Самая важная технология, лежащая в основе любой программы, это язык программирования. Самыми популярными языками на GitHub (платформе для хостинга проектов и совместной работы над ними) являются JavaScript, Python, Java, Ruby и PHP. На этих языках вы найдете множество проектов на любой вкус и цвет.

Поскольку мы в RubyGarage любим Ruby и его экосистему, нам хотелось бы поделиться несколькими вариантами проектов на этом языке (подходящими для начинающих):

  • Sinatra — библиотека на основе Ruby, помогающая создавать приложения без Rails;
  • Hanami — современный веб-фреймворк, созданный на Ruby;
  • Chef — фреймворк на основе Ruby, используемый для автоматизации работы с сервером;
  • Jruby — второй по популярности интерпретатор Ruby.

Во всех этих проектах пригодится ваша помощь.

Тип проекта

Выбрав язык, следует определиться, над проектом какого типа вы хотели бы работать. На GitHub проекты разбиты по категориям в папках под названием Showcases. Вот несколько примеров Showcases: «безопасность», «виртуальная реальность», «текстовые редакторы», «препроцессоры CSS». Просто выберите тему, которая вас интересует.

Но мы бы посоветовали уделить особое внимание проектам, которые будут использоваться более широкой аудиторией. Таким образом вы сможете протестировать ваш код на настоящей большой аудитории. Например, Showcase «Emoji» содержит 25 репозиториев, что говорит о его популярности.

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

Размер проекта

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

Есть еще маленький совет: обращайте внимание на пометки в проектах. Некоторые задачи бывают помечены словами «первый проект», «для начинающих», «легко» и т. д. На Github также есть специальный список проектов, подходящих для начинающих.

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

Как принять участие в проекте с открытым исходным кодом

Говоря о свободном ПО, мы не можем не затронуть тему GitHub и прочих инструментов. Давайте рассмотрим, что такое GitHub и как он может помочь вам принять участие в опенсорсных проектах.

Познакомьтесь с GitHub

GitHub это самая популярная платформа для сотрудничества над проектами с открытым исходным кодом, так что, вероятно, именно ее вы будете использовать, исследуя мир open source. Для начала вам нужно создать себе аккаунт и прочесть руководство, которое поможет вам начать пользоваться платформой. На GitHub можно участвовать в проектах, поднимая какие-то вопросы или отправляя туда свой код. Чтобы поднять какую-то тему (Submitting issues), вы отсылаете сообщение об ошибке в приложении и свои предложения по поводу того, как ее исправить. Если вы хотите написать код для проекта, вы отсылаете пул-реквест с вашими исправлениями и улучшениями.

Изучите основы

Для работы с GitHub нужно уметь пользоваться Git — одним из самых популярных инструментов контроля версий. Поскольку разработчики постоянно вносят изменения в свой код, им нужна система для управления этими изменениями в центральном репозитории. Благодаря такой системе каждый, связанный с процессом разработки проекта, сможет скачать код и внести изменения.

Что касается работы с инструментами контроля версий, необходимым навыком также является умение клонировать репозиторий и отсылать пул-реквесты. Последние информируют мейнтейнеров проекта (людей, занимающихся поддержкой кодовой базы этого проекта) о предлагаемых изменениях в коде. Мейнтейнеры могут проверить эти изменения, открыть их обсуждение и принять для дальнейшего коммита.

Вступите в сообщество

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

Пригодятся все навыки

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

Способы стать контрибутором проекта с открытым исходным кодом

Давайте рассмотрим основные пути к участию в проектах.

1. Создайте собственный проект с открытым кодом

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

Задумывая проект, следует ответить (себе) на ряд вопросов:

  • Какие навыки понадобятся вам для работы над этим проектом?
  • Сколько времени вы собираетесь ему посвятить?
  • Какие проблемы решает ваша программа?
  • Как много потенциальных пользователей у вашего будущего продукта?

2. Создайте свободную альтернативу коммерческому ПО

Современные коммерческие проекты активно используют опенсорсные решения. Многие компании основывают свои проекты на свободных инструментах. С учетом того, что разнообразных программ сейчас достаточно много, нет нужды изобретать велосипед. Вы можете поиграться со свободным ПО, способным заменить похожее, но несвободное. Или же можно создать свою улучшенную версию какой-то программы.

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

3. Станьте контрибутором (участником) уже существующих проектов open source

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

Цукерберг рекомендует:  Первый серьезный яп - Трудный выбор между яп

Самые «горячие» проекты можно найти по ссылке «Trending». А чтобы сделать поиск более релевантным, используйте развернутый поиск: выберите язык, на котором вы хотели бы писать код, и отметьте критерий «best match». Это расставит проекты в порядке релевантности, с учетом количества форков (их число указывает на активность обновления проекта) и звезд (если применять термины Facebook, то звезды это лайки). В большинстве проектов есть известные проблемы, помеченные метками «баг», «обсуждение», «безопасность», «рефакторинг» и другими метками, указывающими на уровень сложности: «легко», «средней сложности», «сложно».

Заключение

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

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

Как стать участником опенсорс-проекта, даже если не умеешь писать код?

Содержание статьи

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

Анестезиолог Кон Коливас разработал собственную версию планировщика задач для ядра Linux, потому что существующая реализация была адаптирована под серверные задачи и плохо справлялась с пользовательскими.

Алексей Кузнецов, который по воле случая превратился в Linux-хакера, сменил свою профессию с физика-теоретика на системного программиста.

ИТ-журналист Петр Семилетов параллельно с основной работой уже десять лет разрабатывает свой текстовый редактор Tea с открытым исходным кодом.

Леся Новасельская, получившая специальность патологоанатома, участвует в тестировании проекта c открытым исходным кодом.

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

Согласно опросу сайта opensource.com, основное препятствие для участия в открытом проекте — желающие просто не знают, как к нему присоединиться. Мы предлагаем несколько универсальных способов решения этой проблемы.

Пиши новый код

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

Для каждого проекта характерны свои технические процессы, поэтому узнай о них побольше, прежде чем предлагать свой вариант. Например, в проекте PostgreSQL жестко регламентированы все процессы: изменения в коде отправляются в виде патча в рассылке основным разработчикам, которые тщательно изучают все изменения. С другой стороны, есть и иные типы проектов, как, например, Parrot, где программисты могут коммитить в основной репозиторий. Если в проекте используется GitHub, возможно, процессы поставлены через pull request, то есть через запросы на включение сделанных изменений. В общем, нет двух одинаковых проектов.

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

Приоритизируй баги

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

Например, у проекта OpenVZ есть полностью открытая система работы с дефектами — bugs.openvz.org, где собраны все известные (исправленные и неисправленные) проблемы за все время существования проекта (без малого десять лет). Баг-трекер — один из механизмов коммуникации между разработчиками и пользователями. Постоянная работа с текущими запросами дает отличную возможность внести свой вклад в проект. Для работы с системой могут понадобиться специальные права доступа, которые тебе предоставит менеджер проекта, следуя принципам меритократии.

Тестируй промежуточные версии

Опрос в Интернациональном клубе тестировщиков ПО показал, что интерес к тестированию ПО с открытым исходным кодом у профессиональных тестировщиков есть. Многие хотели бы поучаствовать в таких проектах, но не знают, с чего начать. В свою очередь, в любом проекте, даже коммерческом, всегда не хватает тестировщиков. Обнаружение и сортировка багов может значительно сэкономить разработчикам время на поиск проблемы. Если пользователь пишет: «Программа не работает, когда я делаю такие-то шаги», не поленись разобраться в том, чем вызвана эта проблема. Проблема повторяется? Ты можешь воспроизвести ее, сделав ряд конкретных шагов? Сузить круг подозреваемых до конкретного браузера или дистрибутива? Даже если ты не знаешь истинную причину проблемы, информация об уже проделанной тобой работе поможет разработчикам справиться с ней. Независимо от того, что тебе удалось выяснить, добавь свои комментарии к багу, чтобы все могли с ними ознакомиться.

По своему опыту могу сказать, что у открытых проектов вечно не хватает ресурсов, чтобы хорошо протестировать новую функциональность. Поэтому перед тем, как добавлять серьезные изменения в основную ветку репозитория исходного кода, проект старается привлечь как можно больше людей для тестирования. Такая практика так и называется — призыв к тестированию (call for testing). У владельцев проекта никогда не будет столько аппаратных и программных конфигураций, сколько у сообщества. Например, разработчики проекта OpenBSD анонсируют появление новой функциональности в новостях, чтобы привлечь к ней внимание тестировщиков и пользователей. То же самое делает и проект OpenVZ.


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

Пиши тесты

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

Исправляй баги и добавляй новые функции

Патч с исправлением проблемы или добавляющий необходимые тебе функции — это своего рода классический способ вовлечения в открытый проект (с этого началось вообще все движение за свободное ПО). Этот способ рекомендует и известный мейнтейнер сообщества Linux Джеймс Боттомли (он же — технический директор отдела серверной виртуализации компании Odin) тем, кто хочет принять участие в Linux-проекте, но не знает как. Обычно он приводит в пример случай, когда ему понадобилось изменить функциональность SIP-клиента в Android. Обнаружив, что такая возможность отсутствует, он сделал патч и отправил в проект SIPdroid.

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

Помогай поддерживать инфраструктуру проекта

Тебе интересна область DevOps? Это направление сейчас очень популярно. Хороших инженеров DevOps в России очень трудно найти, мы это знаем на собственном опыте. Получить опыт можно в проектах, в которых ведется открытая разработка инфраструктуры. Это такие проекты, как Wikipedia и Fedora Linux. OpenVZ только делает в этом направлении первые шаги.

Настройка процесса непрерывной интеграции для компонентов проекта, пакетирование компонентов для Linux-дистрибутивов, автоматическая настройка окружения разработчика — все это входит в задачи DevOps.

Пиши и переводи документацию

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

Если при чтении документации по проекту тебя когда-нибудь посещала мысль: «Такое ощущение, что ее написали так, как будто я уже знаю, как пользоваться программой», то ты понимаешь, о чем речь. Очень часто взгляд со стороны позволяет выявить недостатки в текущей документации, которые могут не заметить непосредственные участники проекта. К тому же в динамично развивающихся проектах документация быстро устаревает, и ее требуется поддерживать в актуальном состоянии.

Если ты по какой-то причине думаешь, что заниматься этим «несерьезно», то ты ошибаешься. Нет «серьезного» или «несерьезного» вклада в открытый проект. К примеру, разработчик OpenBSD (в то же время и сотрудник CERN) Инго Шварц (Ingo Schwarze) написал утилиту mandoc, которая теперь используется для форматирования страниц документации не только в OpenBSD, но и во FreeBSD, NetBSD, DragonFly BSD. Попутно он привел в порядок форматирование существующих страниц документации в проекте. Так что все зависит от того, что интересно тебе. Если интересно — берись и делай!

Помогай другим пользователям

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

Рекламируй любимый проект

Если у тебя есть блог, делись своим опытом, который ты получил в проекте. Расскажи о проблемах, с которыми ты столкнулся при использовании ПО, и как тебе удалось их решить. Так ты сможешь убить двух зайцев сразу: поддержать внимание своих коллег к проекту и создать полезную базу информации для тех, кто присоединится к нему в будущем и будет искать в Сети ответы на уже описанные тобой вопросы. Блог, рассказывающий о твоих технических достижениях и изысканиях, — это еще и отличный способ поделиться реальным опытом разработки и решения технических проблем, который может пригодиться при поиске новой работы. Во многих проектах есть агрегаторы записей из блогов участников проекта, традиционно их называют «планетами»: планеты Linux kernel, Perl, OpenVZ, freedesktop, GNOME, Debian и другие.

Делай дизайн

Дизайн — это бич большинства открытых проектов. Скучные сайты и невзрачные логотипы сопровождают проекты просто потому, что технические люди в основном зациклены на реализации, а не на внешнем виде. Поэтому участие дизайнеров крайне приветствуется. Пользователи сайта StackExchange попробовали ответить на вопросы «как графический дизайнер может внести вклад в открытый проект», «что мотивирует дизайнера участвовать в открытом проекте», но мнения их разошлись. Дизайнеры из компании Red Hat тоже осознали необходимость более активного участия дизайнеров в открытых проектах и попробовали создать сайт, который поможет открытым проектам и дизайнерам найти друг друга, но о случаях успешного применения проекта пока не известно.

Ищи задачи, которые интересны тебе и полезны проекту, и пытайся их решить. Способы участия могут быть разными, иногда они описаны на специальных страницах: OpenStack, OpenVZ, FreeBSD. Само наличие у проекта такой страницы говорит о том, что он открыт для участия других людей.

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

Александр Юрченко, разработчик в компании «Яндекс»

На свою первую серьезную работу за деньги (разработчик встраиваемых систем) я пришел, уже больше года считаясь официальным разработчиком ядра бесплатной операционной системы OpenBSD. Официальным — в смысле у меня был доступ на запись в репозиторий. А до этого еще с год я был «зрителем», присылающим патчи разработчикам.

Должен сказать, что участие в подобном проекте дает колоссальный опыт. В хорошем крупном open source проекте есть все, что обычно требуют от разработчика на собеседовании: и грамотное проектирование, и хорошее кодирование, и навык работы с системой контроля версий и баг-трекером, а также peer review, работа в команде и т. д. и т. п. Таким образом, «поварившись» год-другой в такой атмосфере, можно запросто вырасти до уровня, который соответствует позиции Senior developer.

Собственно, со мной так и было. Я не имел никакого формального опыта работы (по трудовой), но меня сразу взяли старшим разработчиком. А после первой недели испытательный срок был уменьшен с трех месяцев до нуля.

Кирилл Горкунов, разработчик проектов OpenVZ и CRIU

Попал в OpenVZ достаточно случайно. По работе занимался в основном прикладным программированием, практически не имеющим точек пересечения с системным. В какой-то момент приобрел свой первый 64-битный ноутбук (Acer с AMD Turion 64), ну и поскольку Windows 64-битной под руками не было, поставил Gentoo. С Linux до того момента знакомства практически не имел, так, поиграться ставил какой-то древний Red Hat, но он меня особо не впечатлил, да и для решения текущих рабочих задач эта операционка не подходила. Под Gentoo ноут более-менее работал, но некоторых драйверов не было в стандартной поставке ядра, так что пришлось собирать свое ядро из исходников.

Тут я и словил первый баг, правда, не в самом ядре, а в программе формирования конфигурации ядра. Порыскал по Сети — решения проблемы нет, ну и рискнул сам попробовать исправить. Оказалось, пришлось разбираться со множеством смежных задач (как собирается ядро, какие инструменты используются и прочее). Сделал патч, выслал в рассылку. К моему удивлению, мейнтейнеры ядра отнеслись очень благосклонно даже к такому «кривому» патчу (забегая вперед, скажу, что его пришлось переделать, так как патч был отвратительный, просто не стали сразу давать «от ворот поворот»), не было ни одного смешка в сторону новичка: объяснили, что и как, и показали, как делать правильно.

Дальше заинтересовало само ядро — как работает, какие алгоритмы используются. В этом отношении открытость проекта оказывает неоценимую услугу: можно посмотреть, как решаются те или иные задачи (не какие-то теоретические, а реальные). Нередко возникал вопрос «а почему так, а не эдак», и вот тут крайне полезно иметь обратную связь с автором кода. Открытые списки рассылки не только позволяют спросить у разработчиков, что и как, но, что более важно, служат чем-то вроде базы знаний — всегда можно поискать в архивах обсуждения проблем и методы их решений. Для начинающего программиста без опыта работы такое окружение — просто благодатная почва, чтобы попробовать свои силы, понять, «а надо ли это все мне».

Примерно так было и со мной: несколько лет правил что-то в коде, высылал патчи, получал по рукам за кривой код, ну и одобрения, если патч был правильным и красивым. Такой опыт фактически бесценен. И можно быть уверенным: если у тебя начинает что-то получаться, то тут же появятся предложения о работе. Я так и пересекся с разработчиками ядра Linux из OpenVZ. Ну а дальше решили работать вместе над ядром OpenVZ и смежными программами, не забывая, конечно, и о ванильном ядре.

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

Александр Поляков, разработчик

Я думаю, в моей истории ничего оригинального нет. Как это происходит обычно — начинаешь использовать какой-то софт, и внезапно оказывается, что хотелось бы, чтобы что-то в нем работало не совсем так, или чего-то не хватает, или есть противные косяки. В случае опенсорса есть возможность исправить это самому. Так было с оконным менеджером dwm, в котором меня раздражала конфигурация через config.h c перекомпиляцией: сначала я добавил конфиг через xrdb, потом click to focus и так далее. Такие изменения не соответствовали минималистичным гайдлайнам проекта, поэтому пришлось делать форк.

C DragonFly BSD примерно то же самое: завлекательные тексты на сайте звучали интересно, FreeBSD надоела, но внезапно оказалось, что там плохая поддержка языков, отличных от английского, и управления энергопотреблением (ACPI). Пришлось заняться портированием необходимых участков кода из более свежей версии FreeBSD. Сильно помогли другие разработчики c IRC-канала, объясняли, что к чему, и помогали разбираться с проблемами. Там я получил кое-какой опыт разработки ядра и системных библиотек. Еще удалось на этом заработать немного денег — нашелся человек из Москвы, который использовал DragonFly BSD в продакшене и тоже что-то там хотел подкрутить в ACPI. Нашел меня через git log, связался по почте.

В OpenBSD я только по мелочи какие-то патчи кидал — в cwm что-то допиливал для удобства (в wm’ах-то я уже был спец), в ksh поправил пару косяков и улучшил vi mode. В этом проекте отношение к новым контрибьюторам не самое лучшее — предполагается, что ты самостоятельно во всем разберешься и только после этого будешь писать в рассылку. Порог вхождения высокий, выживают только самые стойкие, зато код получается хороший.

Еще я участвовал в 9front: доработал драйвер для Wi-Fi и уже знакомый мне ACPI. У них, наверное, самая маленькая работающая реализация интерпретатора AML. Да и само ядро довольно компактное (в сравнении с «нормальными» ОС), поэтому разбираться проще. Хвастался этим на собеседовании, насколько помогло (или наоборот) — не знаю.

Вот так вот можно получить опыт в открытых проектах. Главное — не бояться присылать кривой код (бывает у всех), сохранять спокойствие (когда его обругают) и выбирать проекты, которые тебе действительно интересны. И опыт получишь, и удовольствие. Еще есть шанс, что работодатель сам тебя найдет по коммитам или профилю в Гитхабе (привет, Гугл!).

Сергей Бронников

В компании Odin с 2005 года, начинал как тестировщик Parallels Desktop for Mac, потом с нуля организовал тестирование Virtuozzo и отвечал за тестирование этого продукта последние пять лет. Помимо этого занимался тестированием и выпусков таких продуктов как Containers for Windows и Parallels Server for Mac. В настоящее время занимаюсь открытыми серверными проектами компании Parallels Inc.

Цукерберг рекомендует:  Unreal engine - Помощь программирования в Unreal Engine 4

Как пользоваться GitHub

Github — это очень известная платформа для хранения, распространения и управления исходным кодом открытых проектов. Этот сервис используют множество разработчиков по всему миру, среди которых есть и крупные компании, такие как Microsoft, RedHat и множество других, также сотни разработчиков многих популярных проектов.

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

Как пользоваться GitHub

Итак, допустим, у вас есть свой проект и вы хотите разместить его код на Github в открытом доступе чтобы другие пользователи могли его посмотреть и участвовать в разработке. Первое что вам нужно сделать — создать аккаунт.

1. Создание аккаунта

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

Когда завершите ввод, нажмите кнопку «Sign Up Free»:

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

Аккаунт готов, и вы будете перенаправлены на страницу, где сможете создать свой первый проект. Но перед тем как вы сможете это сделать, нужно подтвердить свой Email адрес. Для этого откройте ваш почтовый ящик и перейдите по ссылке в письме от Github.

Никакая настройка github не нужна, достаточно лишь несколько кликов мышкой.

2. Создание репозитория

На открывшейся странице, это главная страница для авторизованных пользователей, нажмите кнопку «Start a project»:

Дальше введите имя и описание будущего репозитория:

Вы можете сразу же инициализировать репозиторий, создав файл Readme, для этого нужно отметить галочку «Initialize this repository with a README» внизу страницы. Также можно выбрать лицензию:

Когда все будет готово, выберите «Create project», будет создан новый проект с файлом README, в котором находится описание и файлом лицензии.

Дальше все самое интересное как работать с github.

3. Добавление веток

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

Текущая ветка обозначена в верхнем левом углу после слова «Branch». Чтобы создать новую ветку просто разверните этот список и начните набирать ее имя:

Сайт сам предложит вам создать новую ветку, выберите «Create branch».

Сразу же после создания вы будете работать с только что созданной веткой.

4. Изменение файлов и коммиты

Любые изменения файлов на Github делаются с помощью коммитов. Коммит выполняется путем внесения самих исправлений и описания этих исправлений. Это необходимо для того, чтобы вы знали что и когда вы меняли, а также позволяет легко отслеживать работу команды. Слово коммит можно перевести как «фиксировать». То есть мы можем внести изменения в несколько файлов, а затем их зафиксировать. Давайте для примера изменим файл README. Для этого найдите в в правой стороне панели кнопку с кисточкой и нажмите на нее:

Откроется текстовый редактор, где вы можете ввести нужные вам исправления:

После того как вы сделаете все что вам нужно, необходимо заполнить поле «Commit» внизу страницы. Кратко опишите что было изменено, а затем нажмите кнопку «Commit changes»:

Эти изменения будут внесены в текущую ветку проекта, поскольку мы сейчас работаем с testing, то и изменения будут отправлены именно туда.

5. Создание запросов слияния (Pull Request)

GitHub для начинающих может показаться очень сложным именно из-за таких возможностей, но это очень удобно если разобраться. Запрос слияния или Pull Request — это возможность, благодаря которой любой разработчик может попросить другого, например, создателя репозитория просмотреть его код и добавить его в основной проект или ветку. Инструмент работы с запросами слияния использует инструмент сравнения diff, поэтому вы можете увидеть все изменения, они будут подчеркнуты другим цветом. Pull Request можно создать сразу же после создания коммита. Давайте отправим Pull Request из нашей testing ветки в основную. Сначала откройте вкладку «Pull Request».

Здесь нажмите кнопку «Create Pull Request»:

Дальше вам нужно будет выбрать ветку, которую нужно слить с основной, в нашем случае «testing».

В этом окне вы можете просмотреть все изменения, сейчас мы видим, что была добавлена строчка:

Дальше нажмите зеленую кнопку «Create Pull Request» и введите описание, как и для коммита:

6. Просмотр и одобрение запросов на слияние

Теперь, на той же вкладке Pull Requests мы видим только что созданный запрос на слияние и нам остается только принять его нажав «Merge Pull Request»:

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

Дальше можно подтвердить Pull Request:

Затем код будет импортирован в основную ветку, а ветка testing может быть безопасно удалена.

7. Отчеты об ошибках

Удобно еще то, что возможно использование GitHub не только для разработки и управления кодом, но и для обратной связи с пользователями. На вкладке «Issue» пользователи могут оставлять сообщения о проблемах, с которыми они столкнулись при использовании вашего продукта. Откройте вкладку «Issues», и нажмите на кнопку «New issue»:

Дальше вам осталось ввести заголовок, текст и нажать «Create new issue».

8. Релизы

Последнее что мы сегодня рассмотрим — это релизы. Когда продукт достиг определенной стадии можно выпустить релиз, чтобы пользователи и вы могли быть уверенны что там все стабильно и никто ничего не сломал неверным Pull Request в Master. Сначала нужно перейти на главную страницу проекта, затем на вкладку «Releases»:

Дальше нажмите кнопку «Create New Release»:

На этой странице нужно указать версию в поле «Tag Version», затем имя релиза и небольшое описание. Если у вас есть скомпилированные архивы с бинарниками то их тоже нужно прикрепить сюда. Затем нажмите «Create Release»:


После создания релиза будет создана такая страничка:

Ссылки на исходный код в tar.gz и zip будут созданы автоматически, все остальные файлы вам придется добавлять вручную.

Выводы

В этой статье мы рассмотрели как пользоваться GitHub для размещения и управления своим проектом. Вся система на английском, так что базовые знания языка очень желательны но даже без них работа с github будет не очень трудной. Надеюсь, эта информация была полезной для вас. Если вас интересует как работать с Git из командной строки, смотрите статью как пользоваться git для начинающих.

GitHub опубликовала инструкции по взаимодействию с Open Source: как внести вклад, как начать проект и т.п.

Крупнейший хостинг Open Source-проектов GitHub запустил новый сайт, содержащий инструкции по участию в жизни свободного программного обеспечения и ПО с открытым кодом.

Так называемые Open Source Guides, подготовленные в GitHub, отвечают на популярные вопросы, с которыми сталкивается любой энтузиаст или разработчик, приходящий в мире Open Source. На данный момент на сайте представлены руководства по следующим направлениям взаимодействия со свободным ПО:

  • Как внести свой вклад в Open Source-проект?
  • Как начать свой Open Source-проект?
  • Как найти пользователей для своего Open Source-проекта?
  • Как построить дружелюбное Open Source-сообщество (вокруг своего проекта)?
  • Лучшие практики для мэйнтейнеров (поддерживающих Open Source-проекты).
  • Лидерство и руководство в Open Source-проектах (формальные правила для принятия решений).
  • Как получить финансирование на свою работу над Open Source-проектом?
  • Как составить и принять кодекс поведения (Code of Conduct)?
  • Метрики успешности для развития Open Source-проекта.
  • Юридическая сторона Open Source.

Все руководства от GitHub написаны на английском языке. Их содержимое распространяется на условиях лицензии CC-BY-4.0, а код и другие исходники или примеры — CC0-1.0. При этом они доступны не только на специальном веб-сайте для удобного просмотра (opensource.guide), но и в рамках Git-репозитория github/open-source-guide.

В GitHub отмечают, что цель этих инструкций, «призванных помочь наиболее эффективному участию в Open Source», — это «отразить голос сообщества и нашей многолетней мудрости и практики».

Введение в GitHub для разработчиков

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

Короче говоря, это платформа для разработчиков программного обеспечения, основанная на GIT.

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

Почему GitHub?

Теперь вы знаете, что такое GitHub и наверняка задаетесь вопросам – зачем мне его использовать и как?

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

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

Со временем основные кодовые базы были перенесены из других систем контроля версий в GIT из-за его удобства. GitHub исторически находится в выгодном положении и прилагает много усилий для удовлетворения потребностей сообщества открытого исходного кода.

Сегодня, когда вы будете искать какую-либо библиотеку, вы в 99% случаев найдете ее на GitHub.

Помимо открытого исходного кода, многие разработчики также размещают частные репозитории на GitHub из-за удобства платформы.

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

GitHub Issues

GitHub Issues – одна из наиболее популярных в мире систем отслеживания багов.

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

Если вы найдете проблему в проекте, управляемом кем-то другим, она будет открытой до тех пор, пока вы не закроете ее (например, если выясните, в чем заключается проблема) или пока владелец репозитория не закроет ее.

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

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

Социальное кодирование

Несколько лет назад в логотип GitHub входил слоган «социального кодирования».

Что это значит? Важен ли сейчас этот слоган? Конечно.

Подписки (Follow)

На GitHub можно подписаться на разработчика или репозиторий, зайдя в профиль пользователя и нажав «Подписаться» или нажав кнопку «Следить» в репозитории.

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

Звезды (Stars)

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

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

Крупные проекты могут иметь десятки тысяч звезд.

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

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

Ответвления (Fork)

Последний важный сетевой индикатор проекта — это количество ответвлений.

Это ключ к тому, как работает GitHub. Ответвление — это основа запроса на включение (PR), который является предложением об изменении. Человек может добавить ответвление к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения в исходник.

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

Чем популярнее, тем лучше

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

Запросы на включение (Pull requests)

В предыдущем разделе я объяснил, что такое запрос на включение (PR). Повторим: человек может добавить расширение к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения.

Проект может иметь сотни PR. Как правило, чем популярнее проект, тем больше PR. Например, в проекте React:

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

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

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

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

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

Управление проектами (Project management)

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

Одна из них – Projects. Это новый раздел, который очень редко используется. Это система «Канбан», которая помогает организовать баги и работу, которую необходимо выполнить.

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

Также в управлении проектами помогают контрольные точки. Это часть страницы issues. Вы можете соотнести проблемы с определенными контрольными точками, которые могут быть целями релизов.

Представив релизы, GitHub расширил функциональность тегов GIT.

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

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

Хотя тег GIT можно создавать программно (например, с помощью тега git из командной строки), создание релизов GitHub – это ручной процесс, который происходит в пользовательском интерфейсе GitHub. Вы, по сути, говорите GitHub создать новый релиз и сообщаете, к какому тегу вы хотите применить его.

Сравнение коммитов

GitHub предлагает множество инструментов для работы с кодом.

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

GitHub позволяет вам делать это с compare view: просто добавьте /compare в конец имени репозитория.

На рисунке ниже я сравниваю последнюю версию React v15.x с последней версией v16.0.0-rc, доступной на момент написания этой статьи, чтобы увидеть, что изменилось.

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

Webhooks и Services

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

Webhooks

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

Когда происходит событие, GitHub отправляет запрос POST на URL, который мы говорим ему использовать.

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

Мы отправляем команду push к GitHub, GitHub сообщает серверу об этом, и сервер извлекает данные из GitHub.

Services

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

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

Можно настроить непрерывную интеграцию с помощью CircleCI .

Можно создать интеграцию Codeclimate , которая анализирует код и предоставляет отчет «Техническая задолженность» и покрытие тестирования.

Заключение

GitHub — это замечательный инструмент и сервис, которым можно воспользоваться. Это настоящий драгоценный камень в современном наборе инструментов для разработчиков. Данное руководство поможет вам начать работу. Реальный опыт управления проектами с открытым или закрытым исходным кодом GitHub (как пользоваться им, показано во многих статьях) — это то, что нельзя упустить.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих