Gitlab hero border pattern left svg Gitlab hero border pattern right svg


GitLab’s documentation is crafted to help users, admins, and decision-makers learn about GitLab features and to optimally implement and use GitLab to meet their DevOps needs.

The documentation is an essential part of the product. Its source is developed and stored with the product in its respective paths within the GitLab CE, EE, Runner, and Omnibus repositories. It is published at (offering multiple versions of all products’ documentation) and at the /help/ path on each GitLab instance’s domain, with content for that instance’s version and edition.

It is GitLab’s goal to create documentation that is complete, accurate, and easy to use. It should be easy to browse or search for the information you need, and easy to contribute to the documentation itself.

All standards and practices for contributing documentation are found within the docs in the GitLab Documentation guidelines section.

Documentation is the single source of truth (SSOT)

Please see the SSOT section in the Documentation Style Guide and especially read the docs-first methodology.

Who contributes to the documentation

Everyone can contribute. For documentation needs resulting from the development and release of new or enhanced features, the developer responsible for the code writes or updates the docs.

Technical writers monitor the planning and merging of documentation, reviewing all changes after they are merged, unless they are brought in to the process earlier for specific questions, reviews, or projects.

For more information on these processes, see the Documentation section of our Development docs.

Who merges the documentation and when

Anyone with master access at GitLab is welcome to merge documentation changes to GitLab's master branches, provided they believe the content is:

GitLab's technical writers review all merged content to confirm it is clear and meets the structure/style guidelines, often making further improvements.

Note that documentation does not need to be perfect in structure and style to merge. It is better to publish an improved doc (simply better than what's currently there) and later refine it than to hold the doc in a review process where users do not know it exists or are using an inferior version of the doc.

However, if you know or suspect that a doc has been merged while in need of further enhancement, please create another MR or issue for this work.

For more information, see the Documentation section of our Development docs.

Resources about GitLab documentation

The Technical Writing team

For more information on the team and how it works to continually improve GitLab docs, see Technical Writing in the Product section of the handbook.