> For the complete documentation index, see [llms.txt](https://docs.zerve.ai/zerve-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zerve.ai/zerve-docs/git-and-version-control/source-control-in-notebooks.md).

# Source control in notebooks

Commit, branch and restore your projects with Git, and use code from your repositories.

Once you've [connected a Git provider](/zerve-docs/git-and-version-control/git.md), each project has **source control**. Open the source control sidebar with **Ctrl+6** (Windows) or **⌘+6** (Mac).

## Connecting a project to a repository

1. In source control, choose where the project's code is saved:

   | Provider         | Choose                                       |
   | ---------------- | -------------------------------------------- |
   | **GitHub**       | Repository and branch                        |
   | **Bitbucket**    | Workspace, repository and branch             |
   | **Azure DevOps** | Organization, project, repository and branch |
2. Set the **branch path**: the folder in the branch where this project is saved. It defaults to the project's ID; you can change it to any name.

To save to a new repository, create it with your Git provider first.

## Committing

Enter a commit message, then commit. Zerve pushes the project's code and structure to the repository. Each commit appears in the project's **commit history**.

### What's saved

| File or folder              | What it holds                                                                                            |
| --------------------------- | -------------------------------------------------------------------------------------------------------- |
| **`canvas.yaml`**           | The project's structure: its layers, global imports, compute settings and the connections between blocks |
| **A folder for each layer** | The layer's code, as `.py` files, and a `layer.yaml` describing the layer                                |

## Comparing versions

Use the commit history to see past commits, and compare versions block by block with the diff viewer.

## Working on a branch

1. Select **Create Branch**, and name the branch. Zerve opens a copy of the project on the new branch.
2. Make and commit your changes on the branch.
3. Select **Create Pull Request** to open a pull request with your Git provider, so others can review it.
4. Merge the pull request with your Git provider.
5. In the main project, **pull** the latest changes to bring the merged work in.

## Restoring an earlier version

Choose an earlier commit to restore. Zerve creates a new copy of the project at that version, leaving the current one unchanged.

## Using code from repositories in your blocks

You can **include** a repository in a project, so its code can be imported in your blocks, such as your team's shared utilities.

1. In source control, select **Include Repository** and choose the repository.
2. Import its code in your blocks.

If the repository's name has hyphens, use underscores instead in your import statements. For example, a repository named `risk-utils` is imported as `risk_utils`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zerve.ai/zerve-docs/git-and-version-control/source-control-in-notebooks.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.