> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.hodi.host/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# How should I organise my Git repository for Hodiploy?

Your Git repository is deployed as-is: on every push, Hodiploy clones it and its content becomes the custom modules folder of your Odoo instance. Organised the right way, it deploys with no extra configuration. This article describes the expected layout; to connect the repository to an instance, see [Does Hodiploy support deployment via Git?](https://help.hodi.host/en/article/does-hodiploy-support-deployment-via-git-9w70mc/) instead.

|| **The golden rule**: the root of your repository is the instance's addons folder. One Odoo module = one folder at the root, containing its `__manifest__.py`.

## The expected layout

```
your-repo/
├── my_module/
│   ├── __manifest__.py
│   ├── models/
│   └── views/
├── other_module/
│   └── __manifest__.py
└── requirements.txt   (optional)
```

* Every top-level folder containing a `__manifest__.py` file is treated as an Odoo module
* **Do not put your modules in a subfolder** (`addons/`, `src/`, and so on): Odoo would not see them. If your repository is organised that way today, move the modules to the root
* Extra files at the root (README, .gitignore...) are harmless: only folders carrying a manifest count

## What happens on every push

On every push to the configured branch, Hodiploy:

1. clones the repository again from scratch (a shallow clone, without the history); the content fully replaces the previous deployment's modules
2. restarts the instance, (re)installing your Python dependencies
3. automatically updates the already-installed modules whose files have changed

A module pushed for the first time must be **installed once through Odoo's Apps menu**; its later updates will be automatic. Conversely, removing a module from the repository does not uninstall it from your database: uninstall it from Odoo before removing it from the repository.

## Python dependencies: requirements.txt

If your modules need Python libraries, add a `requirements.txt` file **at the root of the repository**. It is installed automatically at every start of the instance, in a dedicated Python environment.

Gather all your dependencies in that single file rather than scattering `requirements.txt` files across subfolders.

## Name your modules plainly

The folder name is the module's technical name: unaccented letters, digits and underscores, starting with a letter. `my_module` works; `my-module`, `My Module` or an accented name would be skipped by the automatic update.

Also avoid giving a module the name of a standard Odoo or Odoo Enterprise module: the collision produces behaviour that is hard to diagnose.

## What Hodiploy does not read

* **Git submodules are not fetched.** To ship third-party modules (OCA for example), copy them straight into the repository, each in its own folder at the root
* **Git LFS is not supported**: files tracked by LFS would arrive as text pointers
* Any `Dockerfile`, `docker-compose.yml` or `odoo.conf` in the repository is ignored: containerisation and Odoo configuration are handled by Hodiploy

## Keep the repository light

The deployment clones your repository in seconds as long as it only contains code. Do not store backups, database dumps or large binary files in it: past a few minutes of cloning, the deployment is aborted.

## Going further

* [Does Hodiploy support deployment via Git?](https://help.hodi.host/en/article/does-hodiploy-support-deployment-via-git-9w70mc/) to connect the repository (GitHub or SSH), pick the branch and configure the webhook
* [How do I receive a webhook notification after each deployment?](https://help.hodi.host/en/article/how-do-i-receive-a-webhook-notification-after-each-deployment-1m1q2yu/) to plug your own tools into deployments