Щоденний цикл розробника: Commit, Push і .gitignore

1. Початок роботи: клонування проєкту

Почнімо з того, на чому ви зупинилися в попередній лекції. У вас є репозиторій, створений на GitHub, і тепер потрібно отримати його локальну копію на свій компʼютер, щоб почати роботу. Цей процес називається клонуванням.

Крок 1. Запустіть вашу IDE. Якщо у вас відкрито якийсь проєкт, закрийте його через File | Close Project. На початковому екрані (Welcome Screen) виберіть Clone Repository (або Get from VCS).

Крок 2. У вікні, що відкрилося, вставте URL вашого репозиторію. Такий спосіб стане у пригоді, якщо ви клонуватимете чужий репозиторій. URL можна скопіювати зі сторінки репозиторію на GitHub.

Якщо ви клонуватимете свій репозиторій (наш варіант), найпростіше увійти у свій обліковий запис GitHub просто з IDE. Для цього виберіть опцію Log in to GitHub. Ваша IDE відкриє браузер для авторизації.

На сторінці, що відкрилася, натисніть зелену кнопку Authorize JetBrains. Після цього ви зможете вибирати свої репозиторії просто зі списку в IDE. Виберіть потрібний проєкт і натисніть Clone.

Крок 3. Ваша IDE запитає, чи довіряєте ви цьому проєкту. Оскільки це ваш власний репозиторій, натисніть Trust Project.

Крок 4. Налаштування антивірусу (якщо працюєте на Windows)

Антивірус Windows може попередити, що IDE намагається виконати невідомі для нього дії. Оскільки ми будемо збирати й запускати програми за допомогою компілятора Swift, нам потрібно дозволити IDE працювати без додаткових обмежень. Натисніть кнопку Automatically, і IDE сама додасть потрібні папки до винятків антивірусу.

2. Збереження змін: Commit

commit — це «знімок», тобто збережений стан вашого проєкту в певний момент часу. Уявіть його як точку збереження в грі: за потреби ви завжди можете повернутися до неї, якщо щось піде не так. Кожен коміт має унікальний ідентифікатор і повідомлення, яке описує внесені зміни.

        gitGraph
        commit id: "Початковий коміт"
        commit id: "Додати автентифікацію користувача"
        commit id: "Виправити помилку кнопки входу"
        commit id: "Рефакторинг підключення до бази даних"
    

Крок 1. Внесіть зміни.

Якщо ви клонували щойно створений репозиторій, у ньому буде лише один файл — README.md — і приховані папки IDE.

Відкрийте файл README.md і додайте до нього опис вашого проєкту. Щойно ви почнете редагувати файл, IDE виділить його назву синім кольором на панелі проєкту. Це означає, що файл змінено, але зміни ще не збережено в Git. IDE також додасть зелену лінію там, де ви внесли зміни.

Крок 2. Відкрийте вікно Commit.

Ліворуч у IDE є вкладка Commit. Відкривши її, ви побачите всі зміни, готові до збереження. Це ваша область індексації (Staging Area).

Розберімося, що саме тут є:

• Changes: тут містяться файли, які вже відстежуються в Git, але були змінені. У нашому випадку це README.md, до якого ми додали опис проєкту.
• Unversioned Files: це нові файли, які Git бачить у папці проєкту, але ще не відстежує.

Важливо

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

Якщо ви бачите у списку Unversioned Files папку .idea/ (і особливо файл workspace.xml, який змінюється під час кожного клацання миші), або приховані папки менеджера пакетів .build/ і .swiftpm/ — зупиніться! Ці службові файли не повинні потрапити до спільної історії. Гарна новина: якщо ви створили репозиторій із шаблоном .gitignore (Swift), Git сам сховає ці папки. Якщо ж вони видимі, їх потрібно терміново додати до ігнору (про це наприкінці лекції).

А поки що наше завдання для першого коміту — поставити позначки біля основних файлів проєкту й написати зрозуміле повідомлення в полі Commit Message.

Крок 3. Зробіть коміт.

Натисніть синю кнопку Commit. Готово! Ви зберегли «знімок» вашого проєкту в локальному репозиторії. Назва файлу знову повернеться до звичайного кольору.

3. Надсилання змін на GitHub: Push

Ваші коміти поки що зберігаються лише на вашому компʼютері. Щоб поділитися ними з командою або зберегти їх у надійному місці, потрібно надіслати їх у віддалений репозиторій GitHub.

        sequenceDiagram
        participant Локальний репозиторій (Ваш компʼютер)
        participant Віддалений репозиторій (GitHub)

        note over Локальний репозиторій (Ваш компʼютер): Ви зробили один або кілька комітів.
Вони існують лише тут.

        Локальний репозиторій (Ваш компʼютер) ->> Віддалений репозиторій (GitHub): git push (надіслати коміти)

        note over Віддалений репозиторій (GitHub): Ваші коміти скопійовано
й надійно збережено на сервері.
    

Крок 1. Натисніть кнопку Push.

В інтерфейсі кнопка Push розташована на верхній панелі інструментів (Main Toolbar). Вона виглядає як стрілка, спрямована вгору і вправо. Натисніть на неї.

Крок 2. Перевірте й підтвердьте.

Відкриється вікно, де ви побачите всі коміти, які готові до надсилання. Це ваш останній шанс переконатися, що ви надсилаєте саме те, що потрібно. Натисніть Push.

Якщо все пройшло успішно, ви побачите спливаюче сповіщення від IDE: Коміти надіслано до origin/main. Створити pull request.

Крок 3. Перевірте результат на GitHub.

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

4. Панель керування Git

У вашій IDE є окрема панель інструментів Git, а також швидкі дії на верхній Main Toolbar. Це ваш центр керування версіями. Розгляньмо ключові кнопки.

• Commit (позначка): відкриває панель для збереження змін.
• Push (стрілка вгору/вправо): відкриває вікно для надсилання ваших комітів на GitHub.
• Branches: відкриває віджет для керування гілками (у лівому верхньому куті).
• Show Git Log: показує всю історію комітів вашого проєкту на вкладці Git. Ваша особиста машина часу.

Ранок починається з Update Project

Кнопка Update Project виконує найважливішу функцію — завантажує свіжі зміни від інших учасників команди із сервера GitHub на ваш компʼютер (виконує git pull).

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

5. Використання .gitignore-файлів

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

Специфіка Swift і чому ми ігноруємо папки

В екосистемі Swift стандартом де-факто для керування залежностями та збиранням проєктів є Swift Package Manager (SPM). Процес компіляції Swift створює велику кількість тимчасових, кешових і бінарних файлів, які категорично заборонено надсилати в Git:

• .build/ — це прихована папка, у яку SPM складає всі проміжні результати збирання, завантажені зовнішні пакети (залежності) і готові виконувані бінарні файли. Ця папка може важити сотні мегабайтів, а її вміст унікальний для вашого компʼютера й ОС.
• .swiftpm/ — прихований каталог із налаштуваннями плагінів і специфічними для користувача конфігураціями пакета.
• *.xcodeproj/xcuserdata/ — якщо хтось із вашої команди вирішить відкрити проєкт через Xcode, середовище розробки автоматично створить користувацькі налаштування (наприклад, розташування вікон), які не потрібні іншим учасникам проєкту.
• .idea/ — локальні налаштування вікна IDE JetBrains (які файли у вас відкриті, розміри панелей). Вашим колегам ваші особисті налаштування інтерфейсу не потрібні, а файл workspace.xml взагалі змінюється щосекунди.

Як додати файл до списку ігнорування вручну:

Крок 1. Припустімо, ви створили тимчасовий файл notes.txt з паролями до тестової бази. Клацніть по ньому правою кнопкою миші у вікні проєкту.

Крок 2. Перейдіть у меню Git -> Add to .gitignore -> Add to .gitignore. Ця опція додає вибраний файл до файлу .gitignore в корені вашого проєкту.

Якщо у вас ще немає файлу .gitignore, IDE запропонує його створити. Погодьтеся.

Крок 3. Ваша IDE автоматично додасть імʼя файлу до .gitignore.

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

А що, якщо я вже закомітив?

.gitignore ігнорує лише нові, ще не відстежувані файли. Якщо ви помилково вже закомітили папку .build/, вона вже є в історії, і Git продовжить стежити за нею, навіть якщо ви додасте її до .gitignore. Для таких ситуацій потрібно очистити кеш (наприклад, командою git rm -r --cached .build/ у терміналі), але краще просто не допускати потрапляння сміття в першому коміті.

Правила для .gitignore

У файлі .gitignore вказуються шаблони імен файлів і папок, які Git має ігнорувати. Порожні рядки ігноруються. Щоб додати коментар, почніть рядок із символу #.

• * — замінює будь-яку кількість будь-яких символів. Наприклад, *.log ігнорує всі файли з розширенням .log.
• / — у кінці шаблону означає каталог. Наприклад, build/ ігнорує весь вміст папки build.
• ! — на початку рядка скасовує правило. Наприклад, якщо у вас є правило *.log, але ви хочете відстежувати important.log, додайте рядок !important.log.
• ** — відповідає будь-якій кількості вкладених папок.

Приклад файлу .gitignore для Swift

# Результати збирання Swift Package Manager
.build/
.swiftpm/

# Файли проєктів Xcode (якщо генеруються або використовуються)
*.xcodeproj/xcuserdata/
*.xcworkspace/xcuserdata/

# Файли й налаштування локальної IDE (CLion/IntelliJ)
.idea/

# Файли операційної системи macOS/Windows
.DS_Store
Thumbs.db

Готові шаблони

Вам не потрібно писати ці файли з нуля. Існують готові, перевірені спільнотою шаблони:

1. Добірка .gitignore від GitHub для різних мов і фреймворків: https://github.com/github/gitignore.
2. gitignore.io — зручний вебсервіс, який генерує файл .gitignore під ваші технології (просто введіть Swift, macOS, Xcode, IntelliJ).