Git та GitHub — це абсолютний стандарт інженерної культури. Жоден серйозний ШІ-асистент чи CI/CD пайплайн деплою не працює без репозиторію. В цій лабораторній роботі показано кожен крок створення локального та віддаленого репозиторіїв, що містить проект лендингу з ЛР №7, керування історією змін прямо через VS Code та виконання фінального релізу.

Розробники-початківці проблематично освоюють Git і не відразу розуміють логіку роботи сервісу. Але варто створити пару репозиторіїв або, ще краще, поринути в реальну історію встановлення стартапу на хостингу, як робота з гілками стане доброзичливою, а PR (pull request) і MR (merge request) більше не викличуть плутанини.

На сьогодні стандартом стало використання систем контролю версій, які запам'ятовують, яку зміну та в якому файлі було зроблено, а також можуть показати історію цих змін. Розробники використовують кілька систем контролю версій: Git, Subversion, Team Foundation Server, Mercurial.

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

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

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

Вживані терміни

• Репозиторій (Repository). Сховище проєкту (папка), за історією змін якої стежить Git. Буває локальним (на локальному комп’ютері) та віддаленим (на серверах GitHub).
• Коміт (Commit). Зліпок (фіксація) стану проекту в певний момент часу з унікальним хет-кодом та описом. Це «точка збереження» в процесі розроблення проекту. Коміт - це основний об'єкт в управлінні контролю версій. Він містить всі зміни які зроблено до створення цього коміту. Коміти пов'язані між собою. Наприклад, є перший коміт, Коли створюється другий коміт, він (другий) знає, що йде після першого. І в такий спосіб можна відстежити інформацію. Також кожний коміт має й власну інформацію, так звані метадані:
  • Унікальний ідентифікатор коміту, за яким його можна знайти.
  • Ім'я автора коміту, який його створив.
  • Дата створення коміту.
  • Коментар, який визначає, що було зроблено під час цього коміту.
• Гілка (Branch). Ізольована лінія розробки. Основна гілка називається main. Для створення фіч (наприклад, нової форми зворотного зв'язку) розробники створюють окремі гілки, щоб не зламати стабільний код на живому сайті.

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

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

Існує багато платформ для розміщення вебпроєктів. Для навчальних і невеликих статичних сайтів найчастіше використовують GitHub Pages, Netlify, Vercel або Cloudflare Pages. Ці сервіси надають безкоштовний хостинг, автоматичне оновлення сайту після внесення змін до репозиторію, підтримку захищеного протоколу HTTPS, власні або користувацькі доменні імена, а також інтеграцію з системами контролю версій Git.

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

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

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

1. Перейти на github.com

2. Натиснути Sign up і створити безкоштовний обліковий запис (рекомендується використовувати емейл університету).

3. Заповнити відомості про акаунт.

4. Підтвердити реєстрацію через надісланий лист на пошту. Хмарний сервіс GitHub дбає за захист та непорушність збережених репозиторіїв.

Система контролю версій Git є програмою, яку потрібно встановити на комп'ютер. Процес встановлення залежить від операційної системи. В цій лабораторній роботі розглядається Встановлення на Windows

1. Завантажити інсталятор з офіційного сайту: git-scm.com.

2. Запустити інсталятор та слідувати інструкціям. Рекомендується залишити налаштування за замовченням.

3. Після завершення встановлення відкрити інструмент Git Bash

Git Bash

Git Bash — це спеціальна програма з інтерфейсом командного рядка для роботи з Git. Через термінал можна керувати файлами проєкту та репозиторієм не за допомогою мишки, а за допомогою текстових команд (наприклад: git init, git status, git add тощо).

Завдяки Git Bash можна використовувати однакові команди для керування файлами як на Windows, так і на Mac чи Linux. Розробники часто використовують саме команди в терміналі Git Bash, оскільки це швидше, гнучкіше і допомагає тонко налаштовувати процес розробки.

Під час виконання лабораторної роботи можна підключити Git Bash як основний термінал прямо всередині Visual Studio Code, щоб не перемикатися між різними вікнами.

4. Виконати команду: git --version. Якщо Git встановлено правильно, то в терміналі виведеться номер версії.

Увага! В текстовому інтерфейсі Git Bash уставляння здійснюється комбінацією клавіш Shift+Insert

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

git config --global user.name "Ваше Ім'я"

git config --global user.email "your.email@example.com"

Перевірити правильність налаштувань можна командою: git config --list

Налаштування для Git можна задавати на різних рівнях, і від цього залежить на які проєкти будуть діяти ці налаштування:

• Локальні (--local) налаштування діють лише в рамках поточного проєкту.
• Глобальні (--global) – на рівні облікового запису користувача, тобто для всіх його проєктів.
• Системні (--system) – на всіх користувачів системи.

Якщо налаштувати один і той самий параметр на різних рівнях, то найпріоритетніші – це встановлені з опцією --local, далі з --global, і найменш пріоритетні з --system. Тому зручно налаштовувати Git з опцією --global, щоб не довелося встановлювати налаштування для кожного проєкту окремо.

6. Після встановлення перезавантажити комп’ютер, щоб Git прописався в операційній системі і тоді команди Git будуть присутні в контекстному меню.

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

1. Натиснути кнопку «Create repository» (або обрати команду з випадного списку New repository).

2. Надати відомості про репозиторій

• Назву та Короткий опис репозиторію
• В секції Конфігурація в цьому проекті все залишити за замовченням, рекомендується увімкнути опцію Створення файлу README.md

Файл README.md є візитівкою даного репозиторію на GitHub. Це головний текстовий опис проєкту, який автоматично відображається на його домашній сторінці в GitHub під списком всіх файлів.Розширення .md означає Markdown — це полегшена мова розмітки, яка допомагає легко форматувати текст за допомогою простих символів (робити заголовки, списки, виділення жирним, додавати посилання та зображення).

Залежно від складності проєкту, README.md зазвичай містить наступну структуру.

• Назва проєкту та короткий опис, що це за вебсайт чи програма, яку проблему вона вирішує.
• Перелік технологій та мов розробки (наприклад, HTML5, CSS3, JavaScript).
• Інструкція зі встановлення та запуску. Які команди треба виконати користувачу, щоб запустити цей проєкт локально на комп'ютері.
• Якщо проєкт опубліковано (наприклад, через GitHub Pages), додають пряме посилання живий демо-сайт.
• Демонстрація інтерфейсу або роботи проєкту через скриншоти чи GIF-анімації
• Автори та розробники репозиторію.

3. В разі успішного заповнення відомостей буде створено віддалений репозиторій.

1. Для створення локального репозиторію потрібно скопіювати в GitHub посилання на віддалений репозиторій, щоб пов’язати їх між собою. У випадному меню <> Code скопіювати посилання і запам’ятати його в Блокноті

https://github.com/IrynaYurchak2026/WebDesign.git

2. На локальному комп’ютері в файловому менеджері створити папку, де буде розміщено локальний репозиторій (папка з проектом).

3. Зайти в пусту папку, клікнути правою кнопкою в пустому місці і обрати команду Open Git Bash here.

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

git config --global user.name "Ваше Ім'я"

git config --global user.email "your.email@example.com"

Якщо авторизація пройшла успіщно і не з’явилося повідомлень про помилки, можна продовжувати роботу в Git Bash.

5. Для створення локального репозиторію, потрібно надати команду

git clone [вставити скопійоване посилання з Github]

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

Всередині репозиторію міститься лише файл README.md, який створено у віддаленому репозиторії.

6. Наповнення локального репозиторію

Для того, щоб локальний репозиторій був й робочим простором проекту, потрібно перенести файли проекту (наприклад, лендинг з лр№7 або створити нові) в локальний репозиторій. Тепер це буде робоче середовище для VSCode.

Перенесення файлів проекту у віддалений репозиторій

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

Розглянемо перенесення файлів у віддалений репозиторій через інший інструмент Git GUI (Graphical User Interface). Як можна зрозуміти зі скорочення цей інструмент працює через графічний інтерфейс.

1. Клікнути на пустому місці і обрати команду Open Git GUI here.

Відкривається вікно Git GUI, де з лівого боку (Unstaged Changes) зазначено всі елементи сайту (файли з кодом, стилями, скриптами, картинки, відео), що було змінено чи додано до проекту.

2. В полі Commit Message зазначити опис внесених змін на даному етапі (обов’язковий крок). Звісно, що детальніший опис внесених змін в подальшому допоможе розробнику розібратися в версіях сайту.

3. Для запам’ятовування в програмі Git даних змін потрібно натиснути кнопку Stage Changed.

Після успішного запам’ятовування змін потрібно натиснути кнопки Commit, а потім Push. Якщо все зроблено вірно, то програма Git показує повідомлення про успішне перенесення змінених файлів на віддалений репозиторій.

4. Перейти на Github і переконатися, що вміст віддаленого репозиторію оновився.

1.Відкрити термінал в VS Code в любий спосіб.

• Найшвидший - натиснути комбінацію клавіш Ctrl + ~ (тильда)
• Через меню - обрати команду Terminal → New Terminal
• Через панель - натиснути на вкладку Terminal внизу екрану

В нижній частині VS Code з’явиться панель терміналу. Переконатися, що в лівому кутку терміналу вказано шлях до папки проєкту.

3. Ініціалізація репозиторію (один раз на проєкт): git init

4. Перевірка статусу (дуже важлива команда!): git status. Ця команда показує:

• Які файли змінено.
• Які файли готові до коміту.
• На якій гілці ви зараз знаходитесь.

Також, переконатися, що в Git встановлено потрібний статус розробника.

Внести певні зміни в код відкритої сторінки. На прикладі відкритої сторінки index.html внесено зміни в заголовок.

5. Додавання файлів до коміту (зліпок проекту на даному етапі роботи).

git add . # додати всі змінені файли.

git add index.html # додати лише один файл.

6. Створення коміту.

git commit -m "Edit: Change heading"

Правила хорошого коміту:

• Починати з вказанням, які дії робилися feat:, style:, fix:, docs: тощо.
• Писати повідомлення краще англійською, але допускається й українською.

7. Підключення до GitHub

git remote add origin [посилання на віддалений репозиторій]

Приклад: git remote add origin https://github.com/IrynaYurchak2026/WebDesign.git

8. Надсилання коду на GitHub.

git push -u origin main # перший раз

git push # наступні рази

9. Перейти до Github і переглянути чи оновилися зміни.

10. Забрати зміну в локальному файлі.

11. Перевірити на Github.

Приклад повного циклу роботи

# 1. Перевіряємо статус
git status

# 2. Додаємо всі зміни
git add .

# 3. Комітимо
git commit -m "style: покращив дизайн хедера"

# 4. Відправляємо на GitHub
git push

Корисні команди

git log --oneline        # коротка історія комітів
git log                  # повна історія
git checkout -- .        # скасувати всі незбережені зміни
git restore index.html   # скасувати зміни в одному файлі
git branch -d feature-menu   # видалити гілку

1.Відстеження змін

Після редагування файлів відкрити вкладку Source Control. Тут відображаються: нові, змінені та видалені файли.

VS Code підсвічує зміни:

• M (Modified) — файл змінено.
• U (Untracked) — файл додано.
• D (Deleted) — файл видалено.

2. Додавання змін до коміту

• Написати коментар до коміту.
• Зберегти стан версії Stage All Changes.

3. Натиснути кнопку Commit

4. Надсилання змін на GitHub. Натиснути кнопку Sync Changes або Publish Branch, якщо вона відображається.

5. Перевірити зміни у віддаленому репозиторії на GitHub

Для швидкої публікації можна використати нативний для GitHub інструмент публікації — GitHub Pages, що ідеально підходить для швидких релізів статичних сайтів в форматі HTML (до 30 днів).

1. В інтерфейсі репозиторію на GitHub перейти у вкладку Settings (Параметри) на верхній панелі.
2. В лівому меню знайти розділ Code and automation -< Pages.
3. В блоці Build and deployment знайти пункт Source (за замовчуванням там встановлено Deploy from a branch).
4. У випадному списку Branch змінити значення з None на main (папку залишайте /root) та натиснути Save.

5. Зачекати 1-2 хвилини. Оновити сторінку налаштувань. Вгорі з'явиться зелене повідомлення з посиланням на сторінку в інтернеті: https://вашлогін.github.io/назва-репозиторію/.

Приклад: https://irynayurchak2026.github.io/WebDesign/

Перейти за посиланням на опубліковану сторінку.

1. Відкрити сайт Netlify.com і увійти на нього через акаунт GitHub.

2. Натиснути New site from Git → обрати GitHub.

3. Заповнити відомості про користувача.

4. Дозволити доступ до репозиторіїв і обрати потрібний.

5. Підтвердити доступ до репозиторію через емейл.

6. Налаштування за замовченням (Build command: порожньо, Publish directory: /).

7. Натиснути кнопку Deploy.

Netlify автоматично розгорне сайт і надасть красиве посилання (можна змінити на власне доменне ім’я).

8. Перейти за посиланням і переглянути опублікований сайт.

• Репозиторій (Repository) — спеціальне сховище проєкту (папка), в якому Git зберігає всі файли, а також повну історію їхніх змін та метадані.
• Локальний репозиторій (Local Repository) — копія репозиторію, яка розміщена безпосередньо на комп'ютері розробника. Всі операції в ньому (створення комітів, перемикання гілок) відбуваються миттєво й без доступу до інтернету.
• Віддалений репозиторій (Remote Repository) — версія проєкту, що зберігається на хмарному сервері (наприклад, на GitHub). Це центральний вузол, через який команда синхронізує свою роботу.
• GitHub — хмарна платформа та вебсервіс для хостингу Git-репозиторіїв, що надає графічний інтерфейс, інструменти для командної взаємодії, автоматизації (CI/CD) та управління проєктами.
• Файл .gitignore — спеціальний текстовий файл в репозиторії, де вказуються шаблони назв файлів або папок (наприклад, системні логи, папки залежностей node_modules, секретні ключі), які Git повинен ігнорувати й не додавати до відстеження.

• Робоча область (Working Directory/Workspace) — звичайна папка з файлами проєкту на локальному диску, в якій створюється, редагується або видаляється код.
• Індекс/Зона індексації (Index/Staging Area) — проміжний віртуальний буфер в Git, куди за допомогою команди git add збираються та готуються зміни перед тим, як стати постійним зліпком історії (комітом).
• Невідстежувані файли (Untracked) — нові файли в робочій області, про існування яких Git вже знає, але ще ні разу не фіксував їхню історію та не додавав до індексу.
• Відстежувані файли (Tracked) — файли, які вже були зафіксовані в історії репозиторію. Вони можуть мати стан Unmodified (не змінені з моменту останнього коміту) або Modified (змінені в робочій області, але ще не індексовані).

• Коміт (Commit) — безповоротна фіксація (зліпок) стану індексованих файлів в певний момент часу. Кожен коміт має унікальний ідентифікатор (SHA-1 хеш), дату, автора та опис змін. Це головна "точка збереження" в історії розробки.
• Гілка (Branch) — ізольована та паралельна лінія розробки всередині одного репозиторію. Надає можливість створювати нові функції, не змінюючи стабільний код в основній гілці.
• Main/Master — стандартна назва головної (первинної) гілки репозиторію, в якій зберігається перевірений, стабільний та готовий до релізу код проєкту.
• Злиття (Merge) — процес об'єднання змін з однієї гілки (наприклад, допоміжної гілки фічі) в іншу (наприклад, в main).
• Конфлікт злиття (Merge Conflict) — ситуація, коли під час об'єднання гілок Git виявляє, що в один і той самий рядок коду в обох гілках було внесено різні зміни, і система не може самостійно вирішити, яку версію залишити. Конфлікт виправляється розробником вручну.
• Клонування (Clone) — процес створення повної локальної копії віддаленого репозиторію з GitHub на комп'ютер розробника разом зі всією історією комітів та гілками.
• Pull Request/Merge Request — запит на GitHub від розробника з пропозицією злити його код (з власної гілки) в основну гілку оригінального репозиторію. Використовується для перевірки коду іншими членами команди (Code Review).

• Інтерфейс командного рядка (Command Line Interface) — спосіб взаємодії з комп'ютером або програмами за допомогою введення текстових команд в терміналі, замість використання графічних вікон та миші.
• Git Bash — утиліта для Windows, яка емулює командну оболонку Unix (Bash) та надає повноцінне середовище терміналу для виконання стандартних Linux-команд та команд Git.
• Деплой (Deployment/Розгортання) — процес перенесення, конфігурації та запуску коду проєкту з локального комп’ютера (або середовища розробки) на віддалений публічний вебсервер (хостинг), щоб сайт став доступним для користувачів за унікальною URL-адресою.
• GitHub Pages — безкоштовний хостинг-сервіс від компанії GitHub, призначений для швидкого розгортання та публікації статичних вебсайтів (що складаються з HTML, CSS та JavaScript) безпосередньо з репозиторію.
• Live Demo (Жива демонстрація) — публічне URL-посилання на повністю працездатну версію вебдодатка, яка вже розгорнута на хмарному хостингу й використовується для демонстрації результату.
• Chrome DevTools Console (Консоль розробника) — вбудований в браузер інструмент налагодження, куди виводяться системні логи, попередження, а також критичні помилки мови JavaScript, що допомагає контролювати поведінку сайту після деплою.