Щоденний цикл розробника: 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 намагається виконати невідомі йому дії. Оскільки ми створюватимемо й запускатимемо програми, потрібно дозволити 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, який змінюється після майже кожного клацання мишею) або папки cmake-build-debug/ чи cmake-build-release/ — зупиніться! Ці службові файли не мають потрапити до спільної історії. Добра новина: якщо ви створили репозиторій із шаблоном .gitignore (C++), 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: Pushed commits to origin/main. Create 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.

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

У світі C++ (зокрема під час роботи в CLion) стандартом де-факто є система збирання CMake. Під час компіляції C++ утворюється велика кількість тимчасових і бінарних файлів, які категорично не варто додавати до Git:

• cmake-build-debug/ (або cmake-build-release/) — це каталоги, які CLion створює автоматично. У них зберігаються всі проміжні результати збирання (Makefile, кеш CMake, обʼєктні файли). Ці каталоги можуть важити сотні мегабайт, і вони унікальні для кожного компʼютера.
• *.o, *.obj — обʼєктні файли (результат компіляції одного .cpp файла).
• *.exe, *.dll, *.so, *.dylib — готові виконувані файли й бібліотеки. Зберігати бінарні файли в Git — невдала практика: вони займають місце й не приносять користі іншим розробникам, оскільки скомпільовані під вашу конкретну ОС і процесор.
• .idea/ — локальні налаштування IDE: які файли у вас відкриті, який розмір шрифту тощо. Колегам ваші особисті налаштування інтерфейсу не потрібні, а файл workspace.xml узагалі змінюється щосекунди.

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

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

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

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

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

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

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

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

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

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

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

Приклад файла .gitignore для C++ і CLion

# Результати збирання CMake (за замовчуванням у CLion)
cmake-build-debug/
cmake-build-release/
build/

# Скомпільовані обʼєктні файли та виконувані файли
*.o
*.obj
*.exe
*.dll
*.so
*.dylib

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

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

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

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

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