Git index
Проміжний стан підготовленого snapshot, до якого git add записує зміни перед створенням commit; already tracked files не перестають відстежуватися через нове правило .gitignore.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Перевірити ignore rule без commit
Створює тимчасовий repository й перевіряє, що .env відповідає правилу .gitignore.
Команда завершується з exit code 0; .env розпізнано як ignored.
.gitignore
Version-controlled файл patterns для intentionally untracked files, які мають ігноруватися в певній частині working tree.
Гітігнор та як працювати з гітом та не помилитись →gitignore Documentation
Фіксує precedence, pattern format і поведінку already tracked files.
Гітігнор та як працювати з гітом та не помилитись → Першоджерело ↗Що робить `.gitignore`
`.gitignore` описує файли й каталоги, які Git не має додавати до індексу як нові untracked-зміни. Зазвичай проєктний файл лежить у корені репозиторію. IDE також може мати власні налаштування або ignore-файли, але вони не замінюють правила Git, які мають однаково працювати для всіх учасників і в CI. У PyCharm, IntelliJ IDEA, WebStorm або VS Code плагін для ignore-файлів може дати шаблони та зрозуміле підсвічування. Навіть після `git add .` Git пропустить нові файли, які відповідають правилам `.gitignore`. Водночас правило не прибирає файл, якщо Git уже почав його відстежувати: такий файл треба окремо вилучити з індексу без видалення локальної копії.
Що не можна комітити
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.
Старт нового репозиторію без зайвих файлів
У демонстрації виправляється помилка з назвою `.ignore`: для Git потрібен саме `.gitignore`. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад `.cursorignore`, але кожен із них має окреме призначення. Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити `.gitignore`, одразу записати відомі локальні каталоги на кшталт `.idea/`, `.venv/` і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
Кілька середовищ і поступова еволюція конфігурації
Для dev, staging, UAT та інших середовищ можуть існувати окремі локальні файли, і кожен із них має бути проігнорований. Якщо файл випадково додали до індексу, простого нового правила в `.gitignore` недостатньо: треба забрати його зі staged/tracked стану й тільки тоді перевірити ignore. Середовище не завжди визначається окремим доменом. Маршрутизація може залежати від path, cookie, custom header або feature flag; у production подібний механізм використовується для canary release. У тестах ці параметри мають бути явною конфігурацією, а не розкиданими константами. Ланцюжок розвитку у відео: hardcode → `.env` → структурований config → централізований config server. Перехід потрібен лише тоді, коли попередній варіант уже створює вимірювану незручність або ризик.
Публікація локального проєкту
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Кольори IDE й згенеровані тестові артефакти
IDE кольорами відрізняє нові, змінені, незмінені та проігноровані файли. Конкретні кольори залежать від теми й редактора, тому важливий не сам колір, а статус у Version Control. Як приклад до `.gitignore` додаються каталоги з результатами та звітами тестів. Такі артефакти зазвичай відтворюються під час запуску й не потрібні іншим розробникам у Git. Після зміни правила варто перевірити, що каталог справді став ignored і не присутній у staged changes.
Перевірка staged diff перед commit і push
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Credentials і URL у `.env`
Логін, password і внутрішній base URL не слід публікувати в repository. Для Java-проєкту додається Dotenv dependency через Maven Central і Gradle, створюється `.env` у корені, а сам файл додається до `.gitignore`. Значення завантажуються через Dotenv API під час запуску; IDE plugin лише полегшує підказки ключів або маскування значень і може вимагати restart.