info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments"
Get a list of repository files and directories in a project. This endpoint can
be accessed without authentication if the repository is publicly accessible.
This command provides essentially the same functionality as the `git ls-tree` command. For more information, see the section _Tree Objects_ in the [Git internals documentation](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects/#_tree_objects).
| `id` | integer/string | no | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
| `path` | string | yes | The path inside repository. Used to get content of subdirectories. |
| `ref` | string | yes | The name of a repository branch or tag or if not given the default branch. |
| `recursive` | boolean | yes | Boolean value used to get a recursive tree (false by default). |
| `per_page` | integer | yes | Number of results to show per page. If not specified, defaults to `20`. [Learn more on pagination](README.md#pagination). |
> Support for [including Git LFS blobs](../topics/git/lfs/index.md#lfs-objects-in-project-archives) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15079) in GitLab 13.5.
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
| `sha` | string | no | The commit SHA to download. A tag, branch reference, or SHA can be used. This defaults to the tip of the default branch if not specified. |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user. |
| `from` | string | yes | The commit SHA or branch name. |
| `to` | string | yes | The commit SHA or branch name. |
| `straight` | boolean | no | Comparison method, `true` for direct comparison between `from` and `to` (`from`..`to`), `false` to compare using merge base (`from`...`to`)'. Default is `false`. |
The `additions` and `deletions` attributes are deprecated [as of GitLab 13.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39653), because they [always return `0`](https://gitlab.com/gitlab-org/gitlab/-/issues/233119).
| `version` | string | yes | The version to generate the changelog for. The format must follow [semantic versioning](https://semver.org/). |
| `from` | string | no | The start of the range of commits (as a SHA) to use for generating the changelog. This commit itself isn't included in the list. |
| `to` | string | yes | The end of the range of commits (as a SHA) to use for the changelog. This commit _is_ included in the list. |
| `date` | datetime | no | The date and time of the release, defaults to the current time. |
| `branch` | string | no | The branch to commit the changelog changes to, defaults to the project's default branch. |
| `trailer` | string | no | The Git trailer to use for including commits, defaults to `Changelog`. |
| `file` | string | no | The file to commit the changes to, defaults to `CHANGELOG.md`. |
| `message` | string | no | The commit message to produce when committing the changes, defaults to `Add changelog for version X` where X is the value of the `version` argument. |
If the `from` attribute is unspecified, GitLab uses the Git tag of the last
version that came before the version specified in the `version` attribute. For
this to work, your project must create Git tags for versions using the
following format:
```plaintext
vX.Y.Z
```
Where `X.Y.Z` is a version that follows semantic versioning. For example,
consider a project with the following tags:
- v1.0.0
- v1.1.0
- v2.0.0
If the `version` attribute is `2.1.0`, GitLab uses tag v2.0.0. And when the
version is `1.1.1`, or `1.2.0`, GitLab uses tag v1.1.0.
If `from` is unspecified and no tag to use is found, the API produces an error.
To solve such an error, you must explicitly specify a value for the `from`
attribute.
### How it works
Changelogs are generated based on commit titles. Commits are only included if
they contain a specific Git trailer. GitLab uses the value of this trailer to
categorize the changes.
GitLab uses Git trailers, because Git trailers are
supported by Git out of the box. We use commits as input, as this is the only
source of data every project uses. In addition, commits can be retrieved when
operating on a mirror. This is important for GitLab itself, because during a security
release we might need to include changes from both public projects and private
security mirrors.
Changelogs are generated by taking the title of the commits to include and using
these as the changelog entries. You can enrich entries with additional data,
such as a link to the merge request or details about the commit author. You can
[customize the format of a changelog](#customize-the-changelog-output) section with a template.
### Customize the changelog output
The output is customized using a YAML configuration file stored in your
project's Git repository. This file must reside in
`.gitlab/changelog_config.yml`.
You can set the following variables in this file:
-`date_format`: the date format to use in the title of the newly added
changelog data. This uses regular `strftime` formatting.
-`template`: a custom template to use for generating the changelog data.
-`categories`: a hash that maps raw category names to the names to use in the
changelog.
Using the default settings, generating a changelog results in a section along
the lines of the following:
```markdown
## 1.0.0 (2021-01-05)
### Features (4 changes)
- [Feature 1](gitlab-org/gitlab@123abc) by @alice ([merge request](gitlab-org/gitlab!123))