Chapter 17
GitHub Branching, Pull Requests, and Code Review
Learning Objective
Understand how teams manage GenAI code, prompts, tests, and releases.
What it means
GitHub is used for source control, branching, pull requests, review, automation, and release management. A branching strategy controls how code moves from development to production.
Why it matters
GenAI projects contain Python code, prompts, evaluation datasets, configuration, infrastructure files, and deployment scripts. These assets must be versioned and reviewed. Prompt changes can affect business behavior and should be reviewed like code.
Branching Strategy
main → production-ready code develop → integration branch feature/* → new work release/* → UAT and release stabilization hotfix/* → urgent production fixes
Code: Commit and Pull Request Workflow
git checkout develop
git pull origin develop
git checkout -b feature/clinical-summary-api
# Make code changes
git status
git add .
git commit -m "Add clinical summary API endpoint"
git push origin feature/clinical-summary-api
# Then create Pull Request in GitHub:
# feature/clinical-summary-api -> developCommon Mistakes
- Direct commits to main.
- No pull request review.
- No automated tests.
- No branch protection.
- Prompt changes made without versioning.
Interview Q&A
Q: How do you manage code changes in GitHub?
A: Developers work in feature branches, create pull requests, run automated checks, complete peer review, and merge only after approval.
Q: Can GitHub automatically review Python code?
A: GitHub supports automated checks through GitHub Actions and tools such as linters, tests, CodeQL, and security scans. Human review is still needed for business logic and architecture.
Architect Takeaway
In GenAI projects, prompts, retrieval logic, and evaluation tests should be governed with the same discipline as application code.