# Should generated files be committed and reviewed with their source inputs? > Commit generated outputs when consumers need them, review source inputs, pin generators, and enforce regeneration in CI to prevent drift. Canonical URL: https://www.devobs.io/articles/qa-generated-code-review-policy/ By: Ines Costa Published: 2023-10-30T02:41:04.006Z Updated: 2026-09-06T10:18:15.722Z Section: Architecture Commit generated files when consumers need them directly from the repository, cannot reliably run the generator, or when your release artifact is defined by checked-in outputs. Otherwise, prefer committing only the handwritten source inputs and regenerate in CI. The tradeoff is simple: checked-in outputs improve consumer convenience and auditability, but they add review noise and create drift risk unless regeneration is strictly verified. ## When should generated files be committed? Use consumer requirements first. If another repository, package manager, or deployment step reads generated code straight from Git, commit it. This is common with generated SDKs, vendored schemas, or projects that publish source archives where consumers do not run the build. Generator availability is the next deciding factor. The Protocol Buffers project documents that users need the protocol compiler and language runtime, and recommends pinning to release commits because head revisions can be unstable in between releases ([Protocol Buffers repository](https://github.com/protocolbuffers/protobuf)). If your build depends on a toolchain that is hard to install, slow to bootstrap, or sensitive to version drift, committing generated outputs can be the safer interface for downstream users. Do not commit generated files just because they exist. If every contributor and every CI job can deterministically regenerate them from versioned inputs, excluding them from Git keeps history smaller and reviews clearer. ## How should generated changes be reviewed? Review the handwritten inputs as the primary change: the schema, IDL, OpenAPI document, template, or configuration. Then enforce a regeneration check: CI must regenerate from the checked-out inputs and fail if the working tree changes. That check is the control that prevents stale outputs; a pre-merge reminder is not enough. Reviewers usually should not inspect every line of machine-written output. They should spot-check generated diffs for signs of an unexpected generator version, broken paths, accidental manual edits, or suspicious API surface changes. To keep pull requests readable, mark generated paths with `linguist-generated` in `.gitattributes`, which GitHub says will hide them by default in diffs ([GitHub documentation on customizing changed files](https://docs.github.com/en/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github)). That preserves traceability without forcing humans through boilerplate. ## What policy works well in practice? A solid default policy is: 1. Commit only source inputs. 2. Commit generated outputs only for consumer-facing artifacts or generator-availability constraints. 3. Pin generator versions. 4. Regenerate in CI and fail on drift. 5. Hide generated diffs by default with `.gitattributes`. 6. Treat manual edits to generated files as prohibited. Worked example: your repository contains `api/service.proto` and generated Go stubs. Commit the stubs if downstream services import them directly from the repo and do not run `protoc`. Pin the protobuf release used for generation, because the upstream project warns that working from main can be broken and recommends release commits for stability ([Protocol Buffers repository](https://github.com/protocolbuffers/protobuf)). In review, inspect `service.proto`, confirm the pinned generator version did not change unexpectedly, and let CI prove the generated Go files match the source. ## Should reviewers inspect every generated-code diff? No. They should review the inputs deeply and the outputs selectively. Full line-by-line review of generated files spends human attention where automation is better. ## What should the team verify before adopting this workflow? Verify four things: consumers really can build without committed outputs, generation is deterministic, the generator version is pinned and available in CI, and CI enforces regeneration after checkout rather than relying on a local preflight step. If your team is undecided, start by removing generated files from one low-risk module, add a drift check in CI, and keep consumer-facing generated artifacts committed where they genuinely simplify adoption. Reviewed: 2026-09-05 ## Source references - -