Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
В окремому навчальному 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.
Окрема лінія стану репозиторію. git switch <branch> оновлює working tree та index відповідно до вибраної гілки.
Рівень, з якого Git читає setting: system, global, local, worktree або command. --show-origin і --show-scope допомагають знайти джерело ефективного значення.
Проміжний стан підготовленого snapshot, до якого git add записує зміни перед створенням commit; already tracked files не перестають відстежуватися через нове правило .gitignore.
Створює тимчасовий repository й перевіряє, що .env відповідає правилу .gitignore.
Команда завершується з exit code 0; .env розпізнано як ignored.
State-файл може містити cookies і headers, достатні для impersonation. Офіційний guide радить зберігати його поза Git навіть у private repository.
На сторінці може бути різний контент — що робити? →Кожен 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-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.
`.gitignore` описує файли й каталоги, які Git не має додавати до індексу як нові untracked-зміни. Зазвичай проєктний файл лежить у корені репозиторію. IDE також може мати власні налаштування або ignore-файли, але вони не замінюють правила Git, які мають однаково працювати для всіх учасників і в CI. У PyCharm, IntelliJ IDEA, WebStorm або VS Code плагін для ignore-файлів може дати шаблони та зрозуміле підсвічування. Навіть після `git add .` Git пропустить нові файли, які відповідають правилам `.gitignore`. Водночас правило не прибирає файл, якщо Git уже почав його відстежувати: такий файл треба окремо вилучити з індексу без видалення локальної копії.
У демонстрації виправляється помилка з назвою `.ignore`: для Git потрібен саме `.gitignore`. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад `.cursorignore`, але кожен із них має окреме призначення. Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити `.gitignore`, одразу записати відомі локальні каталоги на кшталт `.idea/`, `.venv/` і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
Якщо repository вже існує на GitHub, GitLab чи Bitbucket, правильний початок — `Git Clone`, а не повторна публікація. З Git hosting копіюється HTTPS або SSH URL, в IDE обирається локальна папка, після чого проєкт клонується. GitHub Desktop може виконати ту саму операцію, але відео демонструє вбудовані IDE-інструменти.
Interview portal зазвичай вимагає оцінити language, framework, testing, Git і CI/CD, але не обовʼязково ставити окреме теоретичне питання на кожен пункт. Кандидату дають реальну проблему: як паралелити тести з обмеженою кількістю users, уникати race conditions або тестувати систему з кількох services. Глибина, структура відповіді та коректні терміни показують масштаб досвіду; уточнення закривають прогалини матриці.
[Дивитися з 00:00](https://www.youtube.com/watch?v=FQsfjR_iHoE&t=0s). Для Java- та Python-прикладів підготовлено репозиторії, де окремі гілки відповідають модулям курсу. Перемкнувшись на потрібну гілку, учень бачить реалізацію в тому стані, у якому вона була під час запису заняття. Це дає змогу звірити структуру проєкту, налаштування й код, якщо пояснення у відео було надто швидким або незрозумілим.
JetBrains IDE індексує Git, Java, Gradle, Maven, Node.js та інші встановлені tools. Після зміни версій без restart IDE може продовжити використовувати старі indexes і показувати хибні errors або не бачити dependencies. У такому випадку можна використати `Invalidate Caches`, очистити filesystem/VCS indexes і перезапустити IDE.
IDE кольорами відрізняє нові, змінені, незмінені та проігноровані файли. Конкретні кольори залежать від теми й редактора, тому важливий не сам колір, а статус у Version Control. Як приклад до `.gitignore` додаються каталоги з результатами та звітами тестів. Такі артефакти зазвичай відтворюються під час запуску й не потрібні іншим розробникам у Git. Після зміни правила варто перевірити, що каталог справді став ignored і не присутній у staged changes.
Наступний рівень — JSON, YAML, XML або інший структурований формат, який можна десеріалізувати у типізований config object. Це допомагає групувати налаштування за сервісами й середовищами, але файл із секретами все одно не можна публікувати в Git. У складнішій системі конфігурацію може віддавати централізований config server. Він дозволяє сервісам отримувати актуальні домени, ключі й feature flags, інколи без повного redeploy. Тестовий код не повинен створювати паралельне джерело правди, якщо може безпечно використати той самий контрольований механізм, що й продукт.
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.