Модуль 8 · Урок 32 із 58
Remotes і pull request: від fetch до review
Remote collaboration складається з двох різних систем: Git передає commits і references, hosting platform організовує pull request, review, checks і permissions. Fetch не інтегрує код у вашу branch, а pull не є магічною синхронізацією без policy.
Безпечна Git-практика модуля 8
Пакет містить тільки synthetic repository files, локальний Python CLI, tests і read-only history verifier. Не додавайте .git, .env, credentials, персональні або production-дані, machine paths чи зовнішні endpoints.
Remote — named URL і refs namespace
git remote -v
git fetch --prune origin
git branch -vvorigin — звичайне default name, не спеціальний server role. Fetch отримує objects і оновлює remote-tracking refs на кшталт origin/main, не змінюючи вашу working branch. --prune прибирає stale remote-tracking refs, а не видаляє local work.
Pull = fetch + integration
git pull спочатку fetch-ить, потім merge або rebase відповідно до flags/config. Команда зручна лише коли team policy та current branch очевидні. Для навчання й incident-safe роботи розділіть кроки: fetch, inspect log/diff, deliberate merge/rebase.
git fetch origin
git log --oneline HEAD..origin/main
git diff --stat HEAD...origin/main
git merge origin/mainPush публікує refs, не «завантажує теку»
git push -u origin feature/case-validationПерший push може встановити upstream. Non-fast-forward rejection захищає remote history від випадкового overwrite. Не відповідайте автоматичним force push; спершу fetch і зрозумійте, чи remote branch містить чужі commits. Якщо policy допускає rewrite власної branch, --force-with-lease безпечніший за blind force, але все одно потребує coordination.
Pull request — proposal і review surface
Pull request показує difference між head і base branches, збирає discussion, reviews і checks, після чого changes можуть бути merged. Хороший description містить problem, scope, verification, screenshots/evidence, risks і rollback. Draft PR доречний для early feedback, але не замінює готовність.
Review перевіряє change, а не автора
- Base/head branches і diff scope правильні.
- Немає unrelated formatting або generated noise.
- Tests доводять behavior і negative paths.
- Security/privacy boundaries не порушені.
- Blocking feedback resolved або explicitly accepted owner-ом.
Approval не гарантує production correctness; branch protection і required checks зменшують risk, але deploy verification лишається окремим етапом.
.gitignore не видаляє secret із history
Ignore patterns допомагають не stage-ити generated/local files. Уже tracked file лишається tracked, а committed credential залишається в history навіть після deletion. У разі leak треба revoke/rotate secret, оцінити exposure і окремо вирішити history rewrite з coordination.
.venv/
__pycache__/
*.py[cod]
.env
.coverageDefinition of Done
- Fetch та integration виконуються як окремо зрозумілі кроки.
- Push target/upstream перевірені.
- PR має scope, proof, risk і rollback.
- Review закритий evidence, а не лише approval.
- Secrets не потрапляють у files, output, screenshots або history.
Модуль 8 завершено
Після тесту прогрес становитиме 32/58 уроки й відкриється review-проєкт 2 «Git collaboration release». Фінальний іспит, PDF, QR та email-сертифікат лишаються заблокованими до 58 уроків і чотирьох прийнятих проєктів.
Методичні джерела
- git-fetch documentation
- git-pull documentation
- git-push documentation
- GitHub Docs: Pull requests
- GitHub Docs: Ignoring files
Урок, сценарії, пояснення й вправи створені SEOWORK. Посилання ведуть лише на офіційну документацію Git і GitHub.
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.