Дисклеймер

Все персонажи вымышлены, события случайны. И вообще такого не может быть, потому как твои сайты в интернетах работают исключительно при помощи БВ[1] и от тебя ничего не зависит.

Не стоит повторять что-либо из нижеописанного без присутствия взрослых.

Предостережение:

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

1. Введение

Итак. Что же такое GitHub.com? Это сервис, который предоставляет удобный веб интерфейс для хранения, версионирования и управления версиями исходного кода ваших проектов. Для чего всё это нужно? - спросите вы. Давайте представим, что когда-то давно папин друг дядя Мага попросил вас сделать сайт для его Шаурмешной в Бирюлёво. И недавно он приходит в гости и говорит: “Здравствуй, дарагой. Целую твои мысли. На том чудо-сайте, что сотворила твоя ясная голова и искусные руки образовалась неведомая шайтан-хрень, которая не даёт покоя достопочтенным гостям моего-чуда сайта. Не мог бы ты, о лучезарный, ради Аллаха изгнать демона из святой обители?” Вы соглашаетесь, разворачиваете у себя сайт, находите место, на которое собственно сайт и ругался и даже не помните, что данный кусок кода писали вы сами и, возможно, даже помните, что так было сделано специально, но для чего? Давайте об этом и о многом другом поговорим более подробно.

2. Мир Git вашему дому коду.

Почему именно git? По большому счёту не важно какую систему версионирования вы будете использовать, будь то гит, свн или миркуриал. Я работал со всеми из них и больше предпочитаю гит. Различия и плюсы/минусы рассказывать считаю излишним. В контексте данного топика это не принципиально. Представьте, что вы построили дом с подземным гаражом, выложили стены, поставили крышу. Всё ок. Потом покупаете машину, а гараж для неё мал. Что делать? Разбирать весь дом, увеличивать гараж и собирать по новой как-то не комильфо. Вот бы был инструмент, который позволял бы легко увеличить гараж без переколбашивания всего остального. Так вот с системой версионирования это сделать проще простого. Как и многое другое.

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

• init - создание репозитория
• remote add - добавление удалённого репозитория
• clone - копирование удалённого репозитория
• add - добавление файлов для фиксации изменений
• commit - фиксация изменений (может сопровождаться комментарием, чтоб не вводили в ступор ситуации из “Введение”)
• push - отправка изменений в удалённый репозиторий
• pull - получение изменений из удалённого репозитория
• merge - слияние веток
• checkout - создание/переключение локальных веток

Как правило, используется от 2-3х веток. Это master - та стабильная версия вашего когда, которая в данный момент работает на продакшене, devel - активная ветка, в которой ведётся основная разработка, staging или release - предпродакшн версия, для тестирования и отладки, в неё как правило допускаются коммиты с мелкими хотфиксами багов, выявленных во время тестирования и отладки. Релизных веток может быть сколько угодно, они обычно именуются и вешаются теги версий. Дабы не засорять репозиторий после слияния с мастер веткой они удаляются.
Потратьте вечер на знакомство с вашей будущей системой версионирования. Это сыграет немаловажную роль в вашей карьере программиста не зависимо от выбранного ЯП[2]
З.Ы. Код drupal.ru использует Git в качестве системы контроля версий

3. GitHub - утроба open source

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

3.1 Ваш профиль

В первую очередь он служит вашей визитной карточкой для большинства работодателей, так ка показывает вашу активность, ваши репозитории, а так же коссвенно указывает на ваши интересы в сфере IT[3]. Как его прокачать и сделать привлекательным для потенциальных работодателей мы поговорим немного позже. А пока можете попрактиковаться в создании своих репозиториев или перенести к себе(форкнуть) понравившиеся чужие.

3.2 Аутентификация

GitHub.com для работы с вашими репозиториями предлагает на выбор 2 протокола - http и ssh. При использовании ssh сервис поддерживает аутентификацию по ssh ключам. Идентифицировать пользователя по ключу будет так же полезно и при подключении к вашим серверам по ssh. Подробнее о создании и использовании ssh-ключей можно найти в той же документации по git.

Ссылка

Там же внизу есть ссылка на документацию из самого github.com

3.3 Работа с репозиториями

Для ведения/управления вашего проекта на github доступны многие удобные инструменты. Это и wiki, где вы можете хранить внутреннюю документацию по проекту, список задач(issue), где собираются проблемы, связанные с ошибками, предложения по улучшению, и остальная информация, связанная с развитием проекта, pull requests - система предложения о внесении изменений в ветки репозитория с возможностью комментирования участков кода с удобным UI[4]. некоторые инструменты рассмотрим подробнее.

3.3.1 Issues

При использовании сторонних open source библиотек на своих проектах вы наверняка сталкивались с какими нибудь ошибками в коде этих самых библиотек, приходилось рыть интернеты в поисках заплаток, патчей или даже отказываться от библиотеки в пользу другой. Так вот, любой open source проект находится на каком-нибудь открытом сервисе, типа github или даже на нём самом. В описанной выше ситуации нужно посетить страницу данного проекта и убедиться, что он активно поддерживается(по временным меткам коммитов, по активности в issues) Если на проект забили, то у вас в принципе 2 варианта - найти для себя новую библиотеку, либо форкнуть(перенести себе) эту и развивать самостоятельно. Но представим, что проект активно развивается, вы заходите в issues и видите, что вашей проблемы нет в списке. В таком случае вы создаёте новую задачу, где описываете свои проблемы, связанные с использованием данной библиотеки. Это обратит внимание разработчиков на проблему, возможно они даже объединят с другой открытой задачей вашу (визуально это видно внутри самого issue). Так же внутри issue можно вести диалог с разработчиками при помощи комментариев.
Это намного удобней и продуктивней, чем постить на профильных форумах “ПАМАГИТИ”. Точно так же другие пользователи смогут создавать issue к вашим проектам, либо вы сами можете так делать(своего рода ToDo/менеджер задач для развития вашего проекта)

3.3.2 Pull Requests(PR)

Возвращаемся к ситуции выше. Вот вы нашли баг, написали issue, разработчики приняли в разработку. Вы сделали хорошо. А можно лучше? Ну конечно можно. Как правило ваша задача далеко не единственная в списке и написание, принятие и внедрение исправлений займёт какое-то время. Как же быть в таком случае? Можно помочь разработчикам и самостоятельно исправить докучающий баг. Так как никто не даст вам право бесконтрольно вносить свои изменения в основной код продукта, для этого существуют PRs, в которых Вы можете предлагать свои варианты решения проблем/улучшения. Для этого достаточно форкнуть себе репозиторий, внести изменения, закоммитить и создать PR в ветку основного репозитория с измениями из вашей ветки. (PR это предложение на слияние отдельных веток между собой, не нужно путать с целыми репозиториями) Разработчики могут принять/отклонить/прокомментировать с указанием на конкретные участки кода ваш PR. Если ваш PR не отклонили, то есть все шансы, что ваш код станет частью проекта, но сверлить дырку для ордена пока рановато. Если по вашему PR имеются комментарии, вы должны принять их во внимание и исправить те участки кода, к которым они относятся в своей ветке. Пока PR открыт, все ваши исправления после ревью попадают в него. Интерфейс PR довольно удобный, визуально можно видеть весь лог действий по PR: комментарии, коммиты… После исправления кода по комментам в интерфейсе они схлопываются, чтобы не отвлекать. И вот наступает тот момент, когда все пожелания/наставления учтены и разработчики принимают ваш PR. Ваш код становится частью проекта, все счастливы. Вы всё сделали отлично.
Так же при закрытии PR в свои проекты, если коммит или сам PR содержит ссылку на открытые/ую issue, при закрытии PR такие issue автоматически закрываются, что делает управление ещё удобное, так как нет необходимости вручную ходить и прокликивать.

3.4 Выводы

Для чего все эти сложности? На самом деле понимание, как всё работает приходит уже через пару дней работы с интерфейсом. Полный дзен наступает после первого успешного PR. Да, с виду кажется сложным и непонятным, но поверьте, на данный момент это лучшее устройство системы коммуникаций между разработчиками всего мира, которое существует на данный момент. Если придумаете лучше, то вы уже знаете что делать: issue->PR )))

4 Что дальше?

Сейчас компании, которые ищут сотрудников в области IT[3:1] обращают внимание на ваши профили в соответствующих сетях: github, drupal.org… где можно посмотреть вашу активность и примеры написанного кода. Это значительно сокращает время возможного собеседования, избавление от скучных и тупых тестовых заданий. Что нужно, чтоб на вас обратили внимание? Всё правильно - прокачивать свой профиль. Каким образом? Да всё тем же, issue, PR, свои какие-нить open source проекты… Вся ваша активность будет отображена в профиле.
Самый простой способ прокачки это открывать любые популярные интересные вам репозитории, читать issue и делать PR))) Тем самым вы помогаете всему сообществу, ну и себе конечно же)))
Чистого кода всем и профессионального роста.

Сноски:

1. БВ - Божественное Вмешательство(примечание автора) ↩︎
2. ЯП - Язык программирования ↩︎
3. IT - Информационные технологии ↩︎ ↩︎
4. UI - User Interface(пользовательский интерфейс) ↩︎