How do you handle a monorepo with different services needing independent versioning in Git?
Why Interviewers Ask This
This is a differentiating question used for senior and lead roles. Interviewers want to see if you can explain not just what happens, but why — and what the trade-offs are in different approaches.
Answer
Managing a monorepo where different services need independent versioning requires a combination of tagging conventions, tooling, and CI/CD automation. Strategies: (1) Namespaced tags: instead of v1.0, use service-name/v1.0: api/v2.3.1, frontend/v1.8.0, worker/v3.0.0. Each service has its own tag namespace and version history. CI triggers on matching tag patterns; (2) Path-based CI triggers: only run a service's pipeline when its files change: in GitHub Actions: on: push: paths: ["api/**", "packages/shared/**"]; (3) Monorepo tools: Nx tracks which projects are "affected" by a commit based on the dependency graph — only builds/tests/deploys affected projects; Turborepo does the same with caching; (4) Independent CHANGELOG.md per service generated from commits touching that service's path using conventional commits with scopes; (5) Semantic-release with path filters: run semantic-release per service directory, each managing its own version; (6) Lerna (for npm packages) — manages independent versioning of packages in a monorepo, handles cross-package dependencies, publishes to npm. The key challenge is mapping code commits to service versions without conflating unrelated changes across services.
Pro Tip
If you're unsure about a detail, say so honestly and explain your reasoning. Interviewers respect candidates who can think through uncertainty rather than bluffing.