Git index
Проміжний стан підготовленого snapshot, до якого git add записує зміни перед створенням commit; already tracked files не перестають відстежуватися через нове правило .gitignore.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Перевірити ignore rule без commit
Створює тимчасовий repository й перевіряє, що .env відповідає правилу .gitignore.
Команда завершується з exit code 0; .env розпізнано як ignored.
Перегляд diff і commit checks
Перед commit треба переглянути кожен changed file і переконатися, що до нього потрапили лише навмисні зміни. Commit message коротко описує зміст. IDE може запустити reformat code, optimize imports і code analysis; ці перевірки допомагають знайти технічні проблеми, але не замінюють ручного diff review.
Перевірка staged diff перед commit і push
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Commit і push
Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.
Commit review, Gradle і JUnit lifecycle
Перед commit потрібно переглянути кожен changed line і переконатися, що `.env` не потрапив до repository. Gradle configuration коригується так, щоб tests можна було запускати з command line через `gradle test`, а не лише кнопкою IDE. `@BeforeAll` виконує спільний open/login один раз перед усіма tests, `@BeforeEach` може перевідкривати home page перед кожним test; наприкінці автор пропонує так само дослідити відповідні after hooks.
Публікація локального проєкту
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Ризик очищення Local History
Опція очищення Local History видаляє детальну локальну історію edits, з якої можна відновити незакомічений код або невдалі експерименти. Перед її вибором потрібно commit-нути чи іншим способом зберегти корисний working state. Якщо ця історія не потрібна, `Invalidate and Restart` може очистити caches та побудувати indexes заново.
Домашні завдання через GitHub
[Дивитися з 10:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=630s). Щотижня очікується один або кілька нових tests. Перша домашня робота публікується як repository link; наступні — в окремих branches і pull requests порівняно з `main`. Це дає reviewer-у точний diff конкретного модуля, а учневі — невеликий, але реальний portfolio artifact. Якщо PR уже merged, треба чітко вказати commit або зміни, які відповідають домашній роботі.
Окрема branch для зміни
Зміни для окремого завдання виконуються в новій branch, створеній від актуальної основної гілки. При створенні варто одразу checkout на неї, після чого перевірити поточну branch перед commit. Це ізолює роботу та спрощує подальший review.
Локальний і глобальний Git config
Кожен 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-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.