Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Repository diff є засобом порівняння, а не доказом якості. Перегляньте й зрозумійте зміну, запустіть релевантний check/test і перевірте observable behavior; для authentication, sensitive data, secrets та safety-critical code потрібен сильніший oversight.
Репозиторій як довідник до модулів →Збережіть або закомітьте власні зміни.
Запустіть свій варіант і зафіксуйте конкретну помилку або розбіжність.
Перейдіть на гілку відповідного модуля та знайдіть найменшу суттєву відмінність.
Поверніться до власної гілки, виправте лише підтверджену причину й повторіть запуск.
Назва гілки, команда перевірки, початкова помилка та мінімальний diff виправлення.
В окремому навчальному 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.
Зіставте class name з route, visible heading і product vocabulary.
Позначте methods, які маскують click як open, або змішують action і assertion.
Перейменуйте лише підтверджені невідповідності та запишіть два project rules у README.
Один короткий diff і два naming rules, які прибирають повторну суперечку на code review.
Вузька перевірка conflict markers і налаштованих whitespace errors. Вона не доводить правильність або працездатність коду.
Репозиторій як довідник до модулів →Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Перед commit треба переглянути кожен changed file і переконатися, що до нього потрапили лише навмисні зміни. Commit message коротко описує зміст. IDE може запустити reformat code, optimize imports і code analysis; ці перевірки допомагають знайти технічні проблеми, але не замінюють ручного diff review.
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
[Дивитися з 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 або зміни, які відповідають домашній роботі.
Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.
JetBrains Structural Search and Replace може знайти синтаксичний шаблон і замінити стару конструкцію на нову. ШІ-інструмент теж може допомогти з механічною міграцією, але його результат потрібно перевіряти diff-ом і тестами. Інструмент не визначає коректність автоматично. Спочатку треба зрозуміти новий контракт API, а вже потім масштабувати перевірене перетворення на кодову базу.