Відео пояснює роль `.gitignore`, візуальні підказки IDE та безпечний щоденний Git workflow. Головна практика — одразу визначити локальні й згенеровані файли, а перед кожним commit вручну перевіряти staged diff, щоб не опублікувати результати тестів, секрети або випадкові зміни. Наприкінці розглядається локальна й глобальна Git-ідентичність для кількох робочих і персональних акаунтів.
Примітка: конспект укладено за автоматичними українськими субтитрами; назви команд та інструментів нормалізовано за контекстом. Важливе уточнення: правила ігнорування виконує сам Git через `.gitignore`; IDE-плагін лише допомагає створювати правила та візуалізує їх.
Після цього уроку ви зможете
Пояснити, які файли має ігнорувати Git і де зберігати спільні правила.
Перевірити staged changes перед commit і не додати secrets або generated artifacts.
Відрізнити global та local Git config і перевірити джерело активного значення.
.gitignore описує файли й каталоги, які Git не має додавати до індексу як нові untracked-зміни. Зазвичай проєктний файл лежить у корені репозиторію. IDE також може мати власні налаштування або ignore-файли, але вони не замінюють правила Git, які мають однаково працювати для всіх учасників і в CI.
У PyCharm, IntelliJ IDEA, WebStorm або VS Code плагін для ignore-файлів може дати шаблони та зрозуміле підсвічування. Навіть після git add . Git пропустить нові файли, які відповідають правилам .gitignore. Водночас правило не прибирає файл, якщо Git уже почав його відстежувати: такий файл треба окремо вилучити з індексу без видалення локальної копії.
Термін
.gitignore
Version-controlled файл patterns для intentionally untracked files, які мають ігноруватися в певній частині working tree.
Термін
Git index
Проміжний стан підготовленого snapshot, до якого git add записує зміни перед створенням commit; already tracked files не перестають відстежуватися через нове правило .gitignore.
IDE кольорами відрізняє нові, змінені, незмінені та проігноровані файли. Конкретні кольори залежать від теми й редактора, тому важливий не сам колір, а статус у Version Control.
Як приклад до .gitignore додаються каталоги з результатами та звітами тестів. Такі артефакти зазвичай відтворюються під час запуску й не потрібні іншим розробникам у Git. Після зміни правила варто перевірити, що каталог справді став ignored і не присутній у staged changes.
У демонстрації виправляється помилка з назвою .ignore: для Git потрібен саме .gitignore. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад .cursorignore, але кожен із них має окреме призначення.
Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити .gitignore, одразу записати відомі локальні каталоги на кшталт .idea/, .venv/ і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
Практика
Провести Git safety audit
В окремому навчальному repository додайте правила для .venv/, .env і test results.
Перевірте кожен path через git check-ignore -v.
Задайте local user.name і user.email, потім перевірте їх через git config --list --show-origin.
Результат: Команди перевірки та staged diff, у якому немає .env і generated artifacts.
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. .gitignore зменшує ризик, але не замінює перегляд staged diff.
Корисна послідовність: перевірити git status, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати user.name і user.email локально.
Практичні команди: git config --list --show-origin показує активні значення та їх джерела; git config user.name і git config user.email читають поточну ефективну ідентичність; git config --local user.name "Name" та git config --local user.email "email@example.com" задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.
Термін
Git config scope
Рівень, з якого Git читає setting: system, global, local, worktree або command. --show-origin і --show-scope допомагають знайти джерело ефективного значення.