GitHub від новачка до майстра: вичерпний посібник

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

Однак насправді гроші заробляються на фільтрації інформації та здатності до впровадження. Якщо ви хочете займатися AI, перейти на FDE (Full-stack Development Engineer) або перетворити себе на OPC (One Person Company), код, документація, версії та співпраця врешті-решт опиняться на GitHub.

Навіть якщо ви займаєтеся творчістю та медіа, на GitHub є велика кількість інструментів для вибору тем, проєктів автоматизації та процесів створення контенту. Як тільки файлів стає більше, а AI вносить зміни, без Git для керування версіями все швидко вийде з-під контролю. Тому програмісти повинні вивчити це, і менеджери проєктів, і творці контенту також; це визначає, чи зможете ви перетворити ідею на керований, багаторазовий проєкт, який можна передати.

Я витратив більше півмісяця на шліфування цієї статті, практикуючи Git, GitHub, Commits, гілки, PR та поширені помилки з 0 до 1. Майбутні прямі ефіри також будуть слідувати цьому ж процесу. Перед офіційним ефіром я спочатку публікую цей посібник у відкритому доступі. Ви можете додати його в закладки або повністю слідувати йому.

1. Git та GitHub: Хто чим керує?

Git — це інструмент керування версіями, встановлений на вашому комп'ютері. У режимі офлайн ви все ще можете робити коміти, переглядати історію, створювати гілки та зливати їх. GitHub — це віддалений репозиторій та платформа для співпраці; він отримує коміти, надіслані Git, і надає Issues, Pull Requests, Actions, перевірку коду та керування дозволами.

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

Натискання «Зберегти» лише записує вміст на жорсткий диск. git add відповідає за вибір, git commit залишає версію локально, а git push надсилає ці коміти на GitHub.

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

2. Перед початком: Підготуйте лише чотири речі

Вам знадобляться Git, обліковий запис GitHub, редактор та практичний проєкт. VS Code достатньо для редактора, а проєктом може бути веб-сторінка або документ Markdown.

Спочатку підтвердьте Git у терміналі:

1git --version

У цій вправі використовуються macOS та Git 2.49.0. Користувачі Windows можуть використовувати Git Bash або вбудований термінал VS Code; команди Git нижче однакові.

Далі налаштуйте автора коміту:

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

Це інформація про автора, яка записується в запис коміту; вона не відповідає за вхід у GitHub. Якщо ви хочете налаштувати це лише для поточного практичного проєкту, замініть --global на --local.

Вхід у GitHub — це окрема справа. У командному рядку зазвичай використовуються три методи:

• GitHub CLI, авторизація через браузер за допомогою gh auth login;
• HTTPS, використання Personal Access Token або менеджера облікових даних;
• SSH, додавання відкритого ключа до GitHub та подальша автентифікація за допомогою ключа.

Початківці можуть вибрати GitHub CLI або HTTPS. Під час використання HTTPS, якщо термінал запитує пароль, введіть Token; звичайні паролі облікових записів більше не застосовуються. Не записуйте Token у команди, віддалені URL-адреси, README, чати або скріншоти.

3. Не поспішайте з init: Підтвердьте, де насправді знаходиться термінал

Ця вправа починається з простої веб-сторінки. Її можна відкрити в браузері, але вона ще не має історії Git.

У проєкті є три файли:

1index.html
2style.css
3.gitignore

У VS Code виберіть «Відкрити папку», не просто клацайте на один файл HTML. Потім запустіть у вбудованому терміналі:

1pwd
2ls

pwd показує поточний каталог, а ls перелічує файли. Продовжуйте лише після того, як побачите index.html та style.css.

Ця перевірка виглядає безглуздо, але вона запобігає найбільш неприємному типу аварії: хтось виконує git init на Робочому столі, в Документах або навіть у домашньому каталозі користувача, а потім git add . поміщає тисячі непотрібних файлів в область індексації. Git не зламаний; каталог був неправильним.

4. Що робить git init?

Тепер ініціалізуйте репозиторій:

1git init -b main
2git status --short

git init -b main створює каталог .git у поточній папці та називає початкову гілку main. .git — це прихований каталог, де зберігається інформація, як-от коміти, гілки, області індексації та віддалені адреси. Файли проєкту залишаються на місці; Git починає спостерігати за ними з цього моменту.

?? на скріншоті вказує на невідстежувані файли. Файли існують, але Git ще не вирішив, чи записувати їх.

Щоб підтвердити кореневий каталог репозиторію, ви можете запустити:

1git rev-parse --show-toplevel

Вихідні дані мають бути поточною папкою проєкту. Якщо написано fatal: not a git repository, спочатку перевірте каталог, а потім подивіться, чи було виконано git init.

5. Перший коміт: Збережіть надійну відправну точку

Проєкт ще не змінено, то чому б спочатку не зробити коміт? Тому що всі наступні зміни потребують порівнянної відправної точки. Спочатку відкрийте веб-сторінку в браузері, щоб підтвердити, що заголовок, картки та область реєстрації відображаються; звужте вікно, щоб перевірити, чи немає горизонтальної прокрутки на мобільній ширині.

Потім подивіться на .gitignore. Вміст, використаний цього разу:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

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

Почніть вибирати файли для першого коміту:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

A у статусі означає Added (Додано), що вказує на те, що файл потрапив в область індексації. git diff --cached --stat повідомить вам, скільки файлів ви готуєтеся закомітити та приблизно скільки рядків було змінено. Щоб побачити конкретний вміст, запустіть:

1git diff --cached

Після підтвердження зробіть коміт:

1git commit -m "chore: Ініціалізація сторінки AI-рекрутингу в кампусі"
2git log --oneline
3git status

Коміт можна розуміти як знімок проєкту з автором, часом, описом та батьківським комітом. ffdf4ff — це скорочена версія хеша цього коміту; використання його в поточному репозиторії дозволяє точно визначити версію.

feat, fix, docs, style, chore — це поширені типи комітів, а не обов'язковий синтаксис Git. Важливішим за префікс є опис китайською (або англійською) мовою, який слідує за ним: що було зроблено, який об'єкт змінено та чому.

6. Другий коміт: Ставтеся до змін AI як до чернеток для перевірки

Далі додайте на сторінку кнопку «Переглянути спосіб реєстрації». Під час використання інструментів програмування AI я записую межі в підказку:

1Змінюйте лише index.html, додайте посилання «Переглянути спосіб реєстрації» під вступним текстом,
2яке веде до #apply на сторінці. Не змінюйте style.css, не виконуйте коміти Git.
3Після завершення повідомте мені, який файл було змінено.

Ручна модифікація також проста:

1<a class="cta" href="#apply">Переглянути спосіб реєстрації</a>

AI каже, що готово, але не поспішайте з комітом. Запустіть:

1git status --short
2git diff -- index.html
3git diff --check

git diff показує зміни в робочій області, які ще не були додані в індекс. Зелений + — це доданий рядок, червоний - — видалений рядок. git diff --check не має виводу, що вказує на відсутність очевидних проблем форматування, як-от пробіли в кінці рядків; він не перевіряє, чи кнопка клікабельна.

Поверніться до браузера та оновіть сторінку, натисніть кнопку, потім звужте вікно. Сторінка має прокрутитися до області реєстрації, а кнопка та картки мають залишатися нормальними на вузьких екранах.

Робіть коміт лише після того, як тест пройдено:

1git add index.html
2git diff --cached
3git commit -m "feat: Додано запис для реєстрації для швидкого перегляду способів подання заявки"
4git log --oneline -2

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

До речі, розрізняйте два diff:

1git diff             # Різниця між робочою областю та областю індексації
2git diff --cached    # Різниця між областю індексації та останнім комітом

Якщо git diff не має виводу, файл, можливо, не збережено, або його вже було додано в індекс або закомічено. Перевірка git status, git diff --cached та git log послідовно є надійнішою, ніж багаторазове введення git add ..

7. Гілки: Залиште місце для тестування невизначених змін

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

1git switch -c experiment/warm-theme
2git branch --show-current

Гілка концептуально — це ім'я, що вказує на певний коміт. Коли нова гілка створюється вперше, вона вказує на той самий коміт, що й main, тому файли абсолютно однакові. Лише коли експериментальна гілка генерує нові коміти, дві лінії розходяться.

На діаграмі синій main все ще вказує на другий коміт, тоді як помаранчевий experiment вже вказує на третій коміт. Проєкт не дублював два набори файлів; змінилися лише покажчики для двох назв гілок.

Змініть змінні кольору в style.css, оновіть сторінку, щоб підтвердити, а потім зробіть коміт:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Спробувати теплу тему в експериментальній гілці"
5git log --oneline --graph --decorate --all

HEAD вказує, де ви зараз знаходитесь. На скріншоті HEAD вказує на experiment/warm-theme, тоді як main залишається на коміті з кнопкою.

Вирішіть залишити теплу тему, перемкніться назад на main та злийте:

1git switch main
2git merge experiment/warm-theme

Тут відбувається Fast-forward, тому що main не мав нових комітів під час експерименту. Git безпосередньо переміщує покажчик main вперед до коміту з теплою темою; зміни успішно злито.

Злиті гілки можна безпечно видалити:

1git branch -d experiment/warm-theme

Рядкова -d перевіряє, чи гілку було злито. Велика -D примусово видалить, і коміти в гілці, які не були злиті, можуть втратити посилання; не використовуйте її як команду щоденного очищення.

8. Конфлікти не є загадковими; Git просто не наважується вибрати за вас

Щоб перевірити конфлікти, я дублював репозиторій. main змінив головний заголовок на «Нехай кампусна творчість буде побачена більшою кількістю людей», а гілка feature змінила той самий рядок на «Перетворити ідею на справді корисну роботу». Git зупинився під час злиття:

Маркери конфлікту поділяються на три частини:

1<<<<<<< HEAD
2Вміст поточної гілки
3=======
4Вміст гілки, яку потрібно злити
5>>>>>>> feature/rewrite-heading

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

1git add index.html
2git commit

Якщо ви не хочете вирішувати це на даний момент, ви можете перервати злиття:

1git merge --abort

Конфлікт означає, що дві особи або два агенти дали різні відповіді для одного й того ж місця, і Git не може вибрати самостійно.

9. Надсилання локального репозиторію на GitHub

Проєкт вже має локальну історію; тепер перейдіть на GitHub, щоб створити репозиторій. Натисніть + у верхньому правому куті, виберіть «New repository» та заповніть назву репозиторію, наприклад:

1campus-ai-demo

Для першої практики рекомендується встановити його як Private. Оскільки локально вже є README, .gitignore та історія комітів, залиште новий репозиторій GitHub порожнім; не ініціалізуйте README, ліцензію або .gitignore на веб-стороні. В іншому випадку локальний та віддалений репозиторії матимуть по шматку початкової історії, і перше надсилання вимагатиме спочатку вирішення зв'язку між двома сторонами. Офіційна документація GitHub «Adding locally hosted code» також чітко нагадує про це.

Скопіюйте HTTPS-адресу:

1https://github.com/YourUsername/campus-ai-demo.git

Поверніться до терміналу проєкту:

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin — це псевдонім для віддаленої адреси; він може працювати з іншими іменами, але спільнота звикла називати головний віддалений репозиторій origin. -u встановить зв'язок відстеження між локальним main та origin/main; наступні операції зазвичай просто запускають git push.

На схемі терміналу нижче використовувався локальний bare-репозиторій для виконання push та clone, тому він не змінював наявний обліковий запис GitHub. Під час перемикання на GitHub просто замініть URL-адресу origin; логіка передачі комітів Git та встановлення зв'язків відстеження однакова.

Після завершення реального надсилання поверніться на веб-сторінку GitHub та оновіть її, щоб підтвердити, що файли, README, гілка за замовчуванням та історія комітів видимі. Повідомлення про успіх у терміналі — це один рівень доказів, а веб-перевірка — інший.

10. Читання репозиторію GitHub вперше: Як читати ці речі на сторінці

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

Відкриваючи репозиторій, спочатку подивіться на ці місця:

• Code: Файли, каталоги, гілки та коміти;
• Issues: Помилки, вимоги, завдання та обговорення;
• Pull requests: Зміни, що очікують на перевірку або злиття;
• Actions: Автоматизоване тестування, збірка та розгортання;
• Security: Політики безпеки та функції, пов'язані з вразливостями;
• Insights: Внески, трафік та активність репозиторію;
• README: Вступ до проєкту та точка входу для використання;
• LICENSE: Як дозволено використовувати, змінювати та поширювати.

Читаючи незнайомий проєкт, не дивіться спочатку на Stars. Спочатку дайте відповідь на п'ять запитань: Яку проблему він вирішує, як він працює, від чого залежить, чи нещодавно він підтримувався, і що ліцензія дозволяє мені робити. Stars відображають увагу; вони не перевіряють безпеку, сумісність або авторизацію за вас.

11. clone, fetch, pull, push: Не плутайте чотири напрямки

Вперше завантажуючи віддалений репозиторій на свій комп'ютер:

1git clone https://github.com/OWNER/REPO.git

Clone приносить файли, історію комітів та віддалені конфігурації, зазвичай автоматично називаючи віддалений репозиторій origin. Завантаження ZIP дає лише знімок файлів на той момент, без повної історії та не встановлює віддалений зв'язок.

Три дії, які часто використовуються після цього:

1git fetch origin   # Завантажити віддалену інформацію, не змінює поточні робочі файли
2git pull           # fetch, а потім інтегрувати в поточну гілку
3git push           # Надіслати локальні коміти на віддалений репозиторій

Щоб спочатку побачити, що сталося віддалено, ви можете:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

Коли ви підтвердите, що локально немає розбіжностей, і ви хочете приймати лише оновлення fast-forward:

1git pull --ff-only

pull спочатку виконає fetch, а потім виконає merge або rebase відповідно до конфігурації. Команди повинні узгодити метод інтеграції перед першою співпрацею і не покладатися на force push, щоб згладити проблеми, коли виникають розбіжності.

12. Від особистого репозиторію до співпраці на GitHub

Pull Request — це пропозиція злиття та місце, де відбувається співпраця. Обговорення, перевірка коду та автоматичні перевірки — все обертається навколо одного набору змін, і воно зливається в main лише після підтвердження.

Припускаючи, що Issue має назву «Додати опис часу події», локальні операції можна виконати так:

1git switch -c feat/event-time
2# Змінити та протестувати сторінку
3git add index.html
4git commit -m "feat: Додати опис часу події"
5git push -u origin feat/event-time

Після надсилання GitHub зазвичай пропонує створити Pull Request. PR — це пропозиція злиття, яка відображає описи, коміти, відмінності файлів, коментарі, рецензії та автоматичні перевірки. Він не потрапить автоматично в main просто тому, що був створений.

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

У тій самій команді, якщо у вас є права на запис до репозиторію, ви можете надіслати PR безпосередньо з гілки. Під час внесення внеску в незнайомий проєкт з відкритим кодом звичайною практикою є спочатку зробити Fork у свій власний обліковий запис, а потім клонувати свій власний Fork:

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

Зазвичай тут є два віддалені репозиторії:

1origin    Ваш власний Fork
2upstream  Репозиторій оригінального автора

Синхронізуйте оригінальний проєкт:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

Потім виконайте модифікації в новій гілці, надішліть у свій власний Fork, а потім надішліть PR до upstream. Fork, clone та гілка вирішують три різні речі: Fork — це набір простору репозиторію на GitHub, clone приносить репозиторій локально, а гілка — це лінія розробки в межах репозиторію.

13. README та LICENSE визначають, чи наважаться інші використовувати це

README повинен відповідати принаймні на ці запитання:

1. Що це за проєкт;
2. Яку проблему він вирішує;
3. Як його встановити або запустити;
4. Наскільки він завершений на даний момент;
5. Де знаходяться основні файли;
6. Хто є авторами, матеріалами та джерелами цитування.

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

Публічні репозиторії також не означають автоматичного отримання ліцензії з відкритим кодом. Офіційне пояснення ліцензії GitHub чітко зазначає: коли ліцензії немає, правила авторського права за замовчуванням все одно діють, і автор зберігає права на копіювання, поширення та створення похідних робіт. Публічний означає, що інші можуть його бачити та Fork відповідно до умов надання послуг GitHub; щоб взяти код у свій власний публічний або комерційний проєкт, вам також потрібно подивитися на LICENSE у репозиторії.

MIT, Apache-2.0, GPL тощо мають різні зобов'язання. Зіткнувшись із комерційним використанням, перерозподілом або змішаними ліцензіями, прочитайте повний файл та проконсультуйтеся з фахівцем, якщо необхідно; не просто питайте AI «Чи можу я використовувати це в комерційних цілях?»

14. Після помилки: Визначте, на якому рівні знаходиться зміна

Ліки від жалю слід вибирати залежно від стану.

Додали неправильний файл в індекс, але хочете зберегти вміст файлу:

1git restore --staged filename

Повідомлення останнього коміту написано неправильно і ще не надіслано:

1git commit --amend -m "Нове повідомлення коміту"

Коміт у спільній гілці потрібно скасувати:

1git revert commit_hash

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

git restore filename відкине незбережені зміни; git reset --hard поверне коміти, область індексації та робочу область до вказаної позиції; git push --force може перезаписати віддалені коміти. Ці три типи операцій вимагають підтвердження мети та резервного копіювання перед виконанням; не сприймайте їх як загальні кнопки відновлення на початковому етапі.

15. Вісім найпоширеніших помилок: Перевіряйте в такому порядку

1. fatal: not a git repository

1pwd
2ls
3git status

Зазвичай каталог неправильний, або поточний проєкт ще не був git init.

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

Перевірте, чи файл збережено, чи ви змінили іншу копію, і чи зміни вже були закомічені:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin CorrectGitHubAddress

5. src refspec main does not match any

Можливо, у репозиторії ще немає коміту, або поточна гілка не називається main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

Перевірте віддалену URL-адресу, право власності на репозиторій, дозволи облікового запису та метод автентифікації. Не надсилайте Token іншим для усунення несправностей.

7. rejected non-fast-forward

Віддалено є коміти, яких немає локально. Спочатку виконайте fetch та перегляньте відмінності; не просто робіть force push:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

Запустіть git status, щоб знайти файли UU, вручну визначте остаточний вміст, протестуйте, потім add та commit; якщо не вирішуєте зараз, git merge --abort.

Коли студент або колега просто каже "Git зламався", попросіть їх надати ці п'ять виводів:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

Потім додайте операційну систему, повну команду, яку щойно виконали, та повне повідомлення про помилку. Більшість проблем швидко потраплять в один із шарів: директорія, статус, ідентичність, віддалена адреса або дозволи.

16. В епоху ШІ Git більше схожий на систему прийняття

ШІ може вводити команди за вас, але він не може автоматично знати, які модифікації відповідають бізнес-намірам. Якщо підказка змінює 20 файлів, а ви не дивитеся на diff, не запускаєте проєкт і не перевіряєте ключі, Git лише сумлінно запише цей безлад.

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

Коли дозволяєте ШІ керувати Git, також встановлюйте межі:

1Будь ласка, спочатку перевірте git status та git diff, і лише підсумуйте поточні зміни.
2Не відкидайте жодного незакоміченого вмісту, не виконуйте reset --hard, clean або force push.
3Надайте результати перевірки після завершення модифікацій, не робіть автоматичний коміт або push.

Чи можете ви запам'ятати команди, вже не так важливо. Вам потрібно вміти читати статус, знати, що перемістив ШІ, оцінювати, чи достатньо перевірки, і зупинятися, коли з'являються небезпечні операції.

17. Пройдіть весь процес знову

1# 1. Підтвердьте розташування
2pwd
3ls
4
5# 2. Ініціалізація
6git init -b main
7git status
8
9# 3. Перший коміт
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Ініціалізація проєкту"
13
14# 4. Зміна, перевірка, тестування, знову коміт
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Додати реєстраційний запис"
20
21# 5. Експеримент з гілкою
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Експеримент з теплою темою"
25git switch main
26git merge experiment/warm-theme
27
28# 6. Підключення до GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. Фінальна перевірка
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

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

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

Я Майлз, експерт з алгоритмів ШІ, який перейшов з великої компанії до FDE. Я займався дослідженнями та розробкою алгоритмів, оптимізацією розгортання та корпоративним навчанням. Слідкуйте за мною @miles_mazy Зростайте разом, заробляйте разом.