When several teams change an API, they need a shared record of what changed, who can review it, and which checks must pass. Git provides version control: it tracks revisions to files so teams can collaborate, review changes, and recover from mistakes. section 1.2
For API work, use Git as the center of the change workflow:
- Keep OpenAPI definitions in a dedicated repository. A shared location makes definitions and reusable components easier to discover and preserves their change history. section 1.5.2
- Propose changes through pull requests. Colleagues can review the API design while CI/CD runs automated compliance checks on the proposed files. section 1.5.2
- Store API configuration in version control too, so approved changes can flow through an API deployment pipeline. section 1.7
Keep the Git repository as the primary home for API definitions even if a design tool edits them. That preserves integration options and avoids depending on one vendor’s storage. An API registry is another storage option, but a Git-hosted pull-request workflow supports familiar review and automation. Automated standards checks reduce manual work; people still need to judge resource models and API operation design. section 1.5.2 section 1.7
Figure 1.9 In APIOps, you automate API governance as much as possible to deliver better compliance and reduced lead times.
The governance diagram places automated checks alongside review, showing why a Git-based approval workflow can improve compliance without making every decision a manual gate. section 1.7
