---
title: "Native Git | Postman API Platform"
description: "Keep your collections, specs, and tests as YAML in the same Git repository as your code. Local by default, and shipped the way you ship code."
url: https://www.postman.com/product/native-git/
---

# Native Git | Postman API Platform

> Keep your collections, specs, and tests as YAML in the same Git repository as your code. Local by default, and shipped the way you ship code.

## Native Git

One repository for your code, collections, specs and tests. Local by default. Ship them the way you ship code.

[Read Docs](https://learning.postman.com/docs/use/native-git/overview)

---

## Your API work, as files in your repo

### Collections and specs live with your code

One YAML file per request, per spec, per environment, under /postman in your repo. They diff line by line, like everything else you review.

### Keep the Git workflow you have

They are plain files, so you branch, diff, and review them with the Git tooling you already use. Postman doesn't replace it.

### Test in CI, publish on merge

Run your collections in the pipeline with the Postman CLI, then publish to Cloud View when the branch merges.

---

## Postman AI reads your code, not just your collection

Your collection is a file in the same repo as your service, so Postman AI can read both. Ask it what your tests miss and the answer comes from the route handlers, not from a spec.

---

*CAPABILITIES*

### Bring Postman to your codebase, not your codebase to Postman

Your collections, specs, and environments version with your code in the repo you already use, run in the pipeline you already have, and reach your team the moment you decide to push them.

### One pull request for the code and the contract

Change a handler and change its collection in the same commit. Reviewers see the API change and the code change side by side, and neither one ships without the other.

### Lint, test, and publish in CI

The Postman CLI lints specs against your governance rules, fails the build on violations, runs your functional and performance suites, then publishes on merge.

### Cloud View for everyone else

Push when you're ready and the rest of your team gets a read-only view in Postman. No repo access, no local clone.

### Any Git provider, any repo

GitHub, GitLab, Bitbucket, cloud or self-hosted, public or private. Postman connects to the repository you already have.

### Monorepo ready

Connect the repository root and register every service's collections and environments in one .postman/resources.yaml.

### Edit where you work

Change a collection in your IDE, in Postman, or with Agent Mode. It is the same YAML file on disk either way.

### On every plan, including Free

Native Git, unlimited workspaces, and private repositories are not paid add-ons. Collaborating through Git costs nothing.

---

*RESOURCES*

## Go deeper on Native Git

### Native Git documentation

How Local View, Git, and Cloud View fit together, and what Native Git stores in your repository.

[Read the Docs](https://learning.postman.com/docs/use/native-git/overview)

### Set up Native Git

Connect a workspace to your repository, including the resources manifest and monorepo layouts.

[Read guide](https://learning.postman.com/docs/use/native-git/setup)

### Develop locally with Native Git

Edit the local YAML files, run your collections against a local service, and keep changes off the cloud until you push.

[Read guide](https://learning.postman.com/docs/use/native-git/develop-locally)

---

## See Native Git on your own repository

Chat with a Postman expert about connecting your repository, keeping collections and specs versioned with the code they cover, and running them in the pipeline you already have.