GitHub

Що таке GitHub?

GitHub – це онлайн-платформа для зберігання, спільної роботи і контролю версій програмного коду.

У цій статті ми пояснимо, як працює GitHub, чим він корисний і як почати ним користуватися. Короткий лікнеп по найпопулярнішій у світі платформі для хостингу IT-проектів і спільної розробки.

Користування GitHub

83 мільйони користувачів, чотири мільйони організацій і 200 мільйонів репозиторіїв. У Мережі багато сервісів для розміщення вихідного коду своїх проєктів, але говорять найчастіше саме про GitHub. У чому ж справа?

Звісно, відомий власник сервісу (Microsoft) і звичка відіграють свою роль, але головна причина – можливості платформи.

Що таке GitHub?

GitHub – це хмарна платформа для хостингу IT-проектів і спільного розроблення, під капотом якої міститься популярна система контролю версій Git, а також повноцінна соціальна мережа для розробників.

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

До речі, деякі умільці примудряються збирати в GitHub цілі бібліотеки – книг і статей, а не програмістські ліби 🙂

І так, якщо ви незадоволені якимись фічами в улюбленій відкритій програмі і її викладено на GitHub, ви завжди можете прийти і посваритися в коментарях до проєкту 🙂

А найкраще – оформити issue (ми розповімо, що це) і самостійно пофіксити проблему на радість усім користувачам. Не забувайте і дякувати авторам класних відкритих проєктів – донатами і просто теплими словами. Їм буде дуже приємно.

Прийшовши практично в будь-яку IT-компанію, ви зіткнетеся з тим, що код десь зберігається – і в переважній більшості випадків цим «десь» буде саме GitHub. У GitHub є досить відомий конкурент – GitLab, він теж заснований на Git, але це різні платформи різних компаній, хоча їхня функціональність дуже схожа.

А ще не варто плутати GitHub і Git. GitHub – лише одна з реалізацій системи контролю версій Git (лише погляньте на повний список Git-клієнтів із графічним інтерфейсом), до якої додано багато зручних інструментів і можливостей (ті самі коментарі, issues, гіперпосилання, форматований текст тощо).

Пам’ятайте, GitHub можна використовувати і без знання Git (зворотне теж вірно).

Ну як, звучить круто? Тоді приступайте до нашого гайда про те, як користуватися GitHub, щоб у всьому розібратися і взагалі зрозуміти, чи потрібен він вам просто зараз.

Чи потрібен вам GitHub

Безумовно, GitHub потрібен не всім. Припустимо, ви ще тільки вчитеся кодити або неспішно робите невеликий проєкт для особистого користування – і вас влаштовує зберігання проєкту на локальній машині. Може, зараз ви просто вивчаєте мову, яка вам подобається, і на цьому етапі не хочете хапатися за все одразу.

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

Хоча і тут є винятки – навіть деякі з ключових розробників ядра Linux досі обмінюються оновленнями коду за допомогою електронної пошти та архівів із файлами 🙂

І справді, є безліч інших способів зберігання початкових кодів: можна створити для них папку в розділі «Мої документи», закидати їх у хмару і підписувати версії або навіть завантажувати в «Вибране» в Telegram.

А ще можна накидати список змін у нотатках у телефоні/на холодильнику текстом у приватному Telegram-каналі. Можна деплоїти проєкт за допомогою простого скачування і розпакування ZIP-архіву з файлами вашої програми (особливо якщо мета – просто показати програму другові або дівчині, якій ви прийшли «допомогти з ноутбуком» ^_^).

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

Усі ці способи по-своєму хороші, але для роботи в IT потрібно звикати до GitHub: це стандарт індустрії.

Нещодавно з’явилася українська альтернатива GitHub під назвою GitFlic. Команда сервісу заявила, що має намір дати «новий імпульс розробці вітчизняних операційних систем, програм, додатків і серверних рішень». Серед привабливих можливостей – інтеграція з Telegram.

Більша частина необхідних можливостей GitHub безкоштовна, хоча у платформи є і платні тарифи – проте з ними можна довго не стикатися, тому що безкоштовних звичайному розробнику вистачає з лишком.

Концепції GitHub

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

Майже вся термінологія успадковується у Git. Основні терміни – репозиторій, гілка, коміт, форк. Вибір деяких із цих назв може здатися не дуже інтуїтивним (навіть якщо ви володієте англійською), але так уже склалося.

Як заливати файли, створювати репозиторії та проводити інші операції, ми розглянемо в наступному розділі, тож не лякайтеся згадки різних дій у визначеннях термінів – все покажемо з картинками 🙂

Репозиторій

Це просто коренева папка з файлами і вкладеними директоріями вашої програми – і одночасно її сторінка на GitHub. Завантажити в репозиторій можна все що завгодно, але передбачається, що ви зберігатимете в ньому файли з вихідним кодом і якісь додаткові матеріали – припустімо, необхідну для GUI або верстки графіку (картинки, іконки тощо).

Репозиторії можуть бути публічними та приватними, у них можна створювати інші папки та відстежувати зміни версій. Керувати своїми репозиторіями можна прямо через інтерфейс сайту, командний рядок, десктопний застосунок GitHub або різні засоби розроблення (IDE), що підтримують інтеграцію із сервісом.

Гілка (branch)

У гілки групуються зміни та оновлення – припустимо, одна головна гілка (за замовчуванням створюється main) і одна beta. Гілки незалежні одна від одної, але за бажання їх можна об’єднувати (merge – злиття) – навіть якщо між ними є різниця в коді.

Способи зміни репозиторію

Внести у вміст репозиторію зміни можна безпосередньо або створивши копію. Саме внесення змін називається «коміт» (від англійського commit – зробити), у нього є тимчасова мітка і хеш-сума.

Перенесення змін-коммітів із локального репозиторію (на вашому ПК) на віддалений (remote repository, тобто в даному випадку на GitHub) називається «пуш» (push) – від англійського “штовхати” (дослівно – «проштовхувати» зміни).

Скопіювати репозиторій для внесення змін до копії можна двома основними способами:

• клонувати (clone) – тобто просто скопіювати на локальний комп’ютер або сервер;
• або форкнути (від англійського fork – розвилка) – зробити окрему копію репозиторію (зазвичай чужого) для продовження розробки «іншим шляхом розвилки».

Якщо ви форкнули чужий проєкт, щоб запропонувати автору конкретні поліпшення, потрібно за готовністю «запулити» їх у вихідний репозиторій – тобто зробивши pull request (запит на зміни).

Це 90% необхідних фактів. Більш нудні подробиці описані в документації та розділі навчання GitHub, а також у керівництві по самому Git, ну а ми спробуємо застосувати все це на практиці.

Створення репозиторію

Звичайно, найпростіший спосіб користуватися GitHub – через сайт, тому почнемо звідси.

Найтиповіші дії під час роботи з репозиторієм – його створення і завантаження файлів, їх ми вже розглядали раніше. Легко переконатися, що обидва завдання займають не більше 30 секунд.

Дуже коротко повторимо висновки з нашого минулого матеріалу:

• для створення репозиторію потрібно натиснути на + у правому верхньому кутку сайту, вибрати пункт New Repository, заповнити назву та опис, проставити потрібні галочки і клацнути на Create Repository;
• для завантаження файлів потрібно зайти в потрібний репозиторій, клацнути на Add file і вибрати Upload files.

Але для навчання Темній стороні Сили роботі з GitHub корисно потренуватися виконувати й інші необхідні в процесі розроблення дії: клонування/форк, об’єднання гілок, перегляд і розв’язання конфліктів та інші.

Давайте покроково пройдемо все це разом – спочатку через сайт, а потім поглянемо одним оком на роботу через GUI-клієнти та інтерфейс командного рядка (CLI).

Перегляд файлів у репозиторії

Погодьтеся, що в низці випадків зручно не завантажувати вихідні коди, а просто побіжно ознайомитися з ними. Для таких простих операцій зовсім не потрібен десктопний клієнт: усі файли можна швидко відкрити у веб-версії (і код, і ті ж картинки). Просто клацніть по них для перегляду!

Пошук і читання репозиторіїв

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

Як і в інших випадках пошуку, ви можете вийти на потрібний репозиторій із пошуковика або через внутрішній пошук по GitHub.

Важливіше інше – на що звертати увагу. Пройдемося деякими пунктами зі скріншота вище.

По-перше, найочевидніше – це опис на головній сторінці. Саме в ньому міститься відповідь на ваше головне запитання – що це і чим може вам допомогти.

Якщо точніше, передбачено два описи репозиторіїв – короткий (один абзац праворуч угорі) і повний (по центру, під списком файлів).

Якщо репозиторій здається корисним, далі потрібно зрозуміти, на яких умовах ви можете його використовувати, що залежить від зазначеної автором ліцензії.

Після цього оцініть, чи підходить вам частота оновлень, – це можна зробити в розділі Releases (посилання прямо під коротким описом). Звісно, це залежить від ситуації: десь може стати в пригоді інструмент, який не оновлювався чотири роки, але найчастіше потрібна хоча б мінімальна підтримка – тобто оновлення щонайменше раз на кілька місяців.

Важливо знати і де подивитися кількість і зміст комітів – клікабельний лічильник знаходиться над списком файлів праворуч.

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

Ще трохи нижче праворуч – одна з найцікавіших штук: аналіз використовуваних у репозиторії мов програмування. У репозиторії зі скріншота вище набір має такий вигляд.

Взагалі, непогано вивчати репозиторії відомих застосунків, якими самі користуєтеся (як на скріншоті вище), і відмічати ті, що сподобалися, зірочками. Це не тільки цікаво – з часом GitHub вивчить ваші вподобання і стане пропонувати в блоці Explore те, що вам може сподобатися.

Створення гілок

Створити нову гілку дуже просто:

• Тиснемо на велику зелену кнопку New branch.
• Вводимо назву нової гілки.
• Вибираємо вихідну гілку для копіювання (тобто main, оскільки поки що інших і немає).
• Клацаємо на Create branch.

Перемикання гілок і вирішення конфліктів

У цьому випадку потрібно спочатку уточнити, що мається на увазі: якщо необхідно просто зайти в альтернативну гілку, це можна зробити в списку гілок репозиторію (потрібне посилання є над списком файлів).

Створимо також альтернативну гілку №2 (sava) і подивимося, який вигляд усе це має в підсумку.

Можна говорити і про перемикання між гілками в іншому сенсі – коли зміни з альтернативної гілки зливають із головною гілкою. Дивіться: у нас є файл code.js, але його вміст трохи відрізняється:

• у гілці main там JS-команда console.log («Дефолтна гілка») і картинка з великим маестро сучасності Ріком Естлі;
• однак у гілці koshka той самий файл містить команду console.log («Кішка!»);, а замість Ріка – смішний кіт;
• і все зовсім ускладнюється третьою гілкою sava, де консольний вивід має вигляд console.log («Сова!»); і використовується картинка з совою (природно, усі перераховані картинки у всіх гілках називаються однаково – pic.jpg).

Виходить, між гілками є конфлікт і просто злити будь-яку з альтернативних гілок з головною не можна! Але для цього вже є рішення: GitHub пропонує нам порівняти гілки, що конфліктують, і, якщо ми захочемо, то й запустити зміни в основну – тобто зробити той самий pull request, про який йшлося вище.

Ось який вигляд має порівняння гілок (c koshka і sava відповідно).

Припустимо, ми вирішуємо прийняти зміни з гілки sava і створюємо pull request з невеликим коментарем.

Далі він з’являється в списку пул-реквестів репозиторію, де ми визначаємо подальшу долю цього запиту на зміни.

Пул-реквест можна остаточно прийняти, підтвердивши злиття (merge) гілок, або відхилити, закривши запит (Close pull request).

При цьому головну гілку main можна захистити від змін, увімкнувши відповідні опції в налаштуваннях сховища (що вам і буде запропоновано при створенні нових гілок).

Щоб змінити цю низку параметрів, зайдіть у своєму репозиторії в розділ Settings -> Branches. Потрібні налаштування – у підрозділі Branch protection rules (цілих 10 галочок на вибір).

Налаштування опису репозиторію

Основний опис вашого GitHub-проекту задається у файлі Readme.md, який можна створити разом із репозиторієм або після. Розширення md – це просто скорочення від назви популярної мови спрощеної розмітки контенту – Markdown.

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

Щоб оформити Readme зі смаком, можна скористатися керівництвом GitHub з markdown-розмітки. Ось який вигляд матиме Readme нашого репозиторію-прикладу після прокачування (перший і другий екран відповідно).

Зверніть увагу: в оформленні можна використовувати все що завгодно – заголовки різних рівнів, виділення жирним/курсивом, зображення, емодзі, посилання тощо.

Файл Readme може бути досить довгим, але все ж для оформлення великої документації GitHub рекомендує створити «Вікі».

Створення сайту з вашого GitHub-профілю

Захостити сайт на GitHub можна за допомогою функції GitHub Pages. Це дуже просто:

• Зайдіть у налаштування репозиторію.
• У блоці Code and automation виберіть Pages.
• Виберіть джерело (Deploy from a branch, потім потрібну гілку).
• Натисніть на Save.
• Оновіть сторінку, і вгорі сторінки з’явиться посилання на ваш новий сайт.

У разі створення сайту для просування себе, а не проєкту, просто створіть сховище з кодом сайту-візитки і дайте йому ім’я вигляду [username].github.io, де username – назва вашого облікового запису на GitHub. Більш докладно про цю функцію – тут.

Підключення GUI-клієнта GitHub Desktop

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

• Завантажуємо і встановлюємо сам клієнт.
• Авторизуємося у своєму обліковому записі.
• Працюємо з наявними репозиторіями або створюємо нові (локальні).

Застосунок пропонує виконати клонування репозиторію на локальну машину для подальшої роботи, що ми і зробимо.

Клоновані з віддаленого GitHub-репозиторію файли зберігаються в спеціальній папці на вашому комп’ютері, і в них легко вносити зміни – клієнт відкриватиме їх в обраному вами редакторі коду/середовищі розробки (хоча зручніше все окремо – обравши потрібний файл-початківець у папці).

Загалом, усе просто, як раз-два-три.

Робота з GitHub через CLI

Працювати з GitHub можна і через командний рядок Windows або PowerShell. Це не дуже складно: для початку інтерфейс командного рядка також потрібно завантажити і встановити (документація – тут).

Команди для GitHub CLI починаються зі скорочення gh – наприклад gh repo clone.

Є й інший варіант – використовувати власне Git і працювати через його власний CLI. Git завантажується і встановлюється окремо, там є мінімалістичний GUI, але його вже логічніше використовувати в терміналі.

Головне, що потрібно про це знати: всі команди Git починаються відповідно – зі слова git, після чого вказується тип дії: git clone, git merge, git fork та інше. Щоб скористатися ними, встановіть Git, роздрукуйте собі будь-яку пам’ятку з його команд і сміливо починайте ними користуватися.

Налаштування GitHub-профілю

Кастомізація профілю – важлива частина самопрезентації розробника: резюме, візитна картка і вітрина проєктів, над якими ви працювали.

Цю інформацію оцінюють роботодавці, тож варто заповнити інформацію про себе та зробити публічними кілька ваших найкращих репозиторіїв (звісно, якщо там нічого секретного :)) – саме вони будуть частиною вашої персональної вітрини.

Подивимося на профіль якогось крутого розробника з тих, хто зараз у тренді GitHub (так-так, є й такий розділ).

На першому місці – такий собі Стівен Селіс. А що в його профілі? Зазначено місце роботи, є сайти і контакти, а в статистиці – 123 репозиторії і 1725 змін у репозиторіях за рік (цілий рік). Тобто неозброєним оком видно, що людина щонайменше активна і досвідчена.

Навіть якщо ви поки що не в топі GitHub, потрібно прагнути до подібного наповнення профілю: детальна інформація + показова низка проєктів (ви можете закріплювати їх по-своєму, натиснувши у власному профілі на Customize your pins).

Висновок

Усе не так складно, як може здатися (кажучи алегорично, кожен розробник у своєму житті спочатку вчиться їсти виделкою, а потім – форкати GitHub-репозиторії).

GitHub користуються всі: це одна з важливих загальних навичок незалежно від обраної вами мови програмування і напряму розробки. І, як і шкільні уроки ОБЖ, той самий git clone коли-небудь вас врятує.

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