Quickstart

Get up and running in GitBook and publish your first docs site in minutes

This quickstart guide explains how to get set up in GitBook and publish your first docs site in minutes.

At the end of this guide, you’ll have a live documentation site, ready to expand and customize.

1

Getting started

You’ll need to create an account before you can get started with your first documentation site.

After creating your account, you’ll automatically see a new docs site that’s ready for you to edit and customize. Choose how you want to add content to your site before you publish from the on-screen options.

2

Edit your content

There are two ways to edit and update your content in GitBook — in our visual editor, or following a docs-as-code workflow. You can choose one, or use a combination of both.

Whichever workflow you prefer, you’ll edit your content using a branch-based editing flow. Find out more on the Concepts page.

Use the visual editor

GitBook’s what-you-see-is-what-you-get (WYSIWYG) editor lets you edit content visually, drag content blocks to reorganize them and see how your content will look as you work.

This visual editing workflow is ideal for users who don’t want to work in a code editor, or who have experience working with tools like Notion or Google Docs.

1. Edit your docs in a change request

First, find your docs site in the sidebar and click the item below it. This takes you to the space where your content lives.

Click Edit in the top-right. This opens a change request where you can edit the content of the space.

Click Add new… in the table of contents on the left-hand side to add a page, and give it a title.

A screenshot of the Editor in the GitBook app, zoomed in to show the menu that lets you add new pages, groups, links and more to a GitBook space.

2. Preview your changes

Along the top of the web app you’ll see tabs for Editor, Changes and Preview. These switch between different views for your content.

Click Preview to see a live preview of what your docs site will look like with all the changes in your change request, on both desktop and mobile.

A screenshot of the GitBook app with the Preview tab open, showing a docs site being previewed on a mobile-size display

3. Merge your changes

Once you’re happy with your changes, click the Merge button in the top-right corner.

This will update the primary version of your content with all the edits from the change request. If the content is part of a live docs site, the site will be updated immediately.

Code-based editing

Sync your documentation with a GitHub or GitLab repository to enable code-based editing. Once synced, you can edit your docs in your existing developer environment.

This workflow is ideal for technical users who don’t want to switch tools and prefer to manage their documentation alongside other code.

1. Set up Git Sync

If you haven’t already set up Git Sync when creating your site, first find your docs site in the sidebar and click the name of the content below it. This takes you to the space where your content lives.

Click the Set up Git Sync button in the top-right and follow the instructions to sync your space to your chosen Git repository.

Head to the Git Sync pages to find out more.

2. Edit your docs from your developer environment

Once you’ve synced your space to your Git repository, you can update the content of your docs from that repository in your development environment.

Open the repository, create a pull request and make the changes you want.

Markdown editing

GitBook supports Markdown editing, so you can create and format content using common syntax.

Every standard block in GitBook can be written and formatted using Markdown syntax.

3. Preview your changes

You can preview your changes on your published docs site from the pull request in GitHub or GitLab.

In your pull request, you’ll see a status with a unique preview URL. Click Details on that status to open the preview URL and see how your site will look when the pull request is merged and your site is updated.

4. Merge your changes

You’re good to go. Merge your pull request and your content will be updated both in the GitBook app and on your docs site, if it’s live.

In the GitBook app, every commit and your merged pull request will be synced to your space as updates in the version history.

A screenshot of the GitBook app showing the version history side panel open. In the side panel the highlighted entry shows a pull request from GitHub that was merged as part of the history, with a link to view the pull request on GitHub.
3

Customize your docs

Organize your site navigation

You can add more content to your site — such as an API reference, a help center or a changelog — at any time. When you add content, you can organize your site’s navigation bar to help users easily find what they’re looking for.

Head to the Concepts page to find out more about site navigation.

Head to the Site structure page to find out more about adding content to your site.

A screenshot of a published docs site hosted on GitBook. The top of the site has a navigation bar, and the cursor is hovering over a drop-down in that bar, with a submenu open below it showing links to more pages
Customize the look and feel of your docs site

Your docs site will look great out of the box, but you can also customize many settings that change the look and feel of your published site.

You can customize your site’s logo, colors and font, add to your site navigation bar using site sections and variants, update your site’s visibility settings and much more.

An illustration showing five docs sites hosted in GitBook, each with distinct visual customizations
4

Publish your documentation

Publish your docs

You can publish your site with a click at any time.

Open your site’s dashboard by clicking the site’s name in the sidebar. Then click Publish in the top-right corner to make it live.

Once your site is live, the dashboard will update with a link to the live site.

A screenshot of the GitBook app showing a dashboard for a docs site. The dashboard shows the public URL, site status, site content, some top-level analytics for the site, and other options in tabs along the top of the screen.
Add a custom domain

By default, you site will be published with a unique URL with this format:

https://[organization-name].gitbook.io/[site-title]

While this may be suitable for some teams, many choose to change their URL to a custom domain or a custom subdirectory.

To do this, open your site dashboard by clicking the site’s name in the sidebar, then open the Settings tab and choose Domain and URL.

A screenshot of the GitBook app showing the menu that guides you through the process of setting up a custom domain for your docs site.

Use the buttons on the screen to choose the option you want, and follow the instructions to configure the DNS settings with your domain provider.

It can take up to 48 hours for your DNS changes to take effect — although they typically propagate much faster.

Next steps

FAQs

What is GitBook?

GitBook is a collaborative, AI-native documentation platform where teams can create, review, and publish branded docs as websites. Docs sites hosted on GitBook can offer a built-in AI Assistant and connect to other AI tools via MCP.

You can edit content using the advanced visual editor using Markdown, sync your docs with a Git repository for a docs as code workflow — or use a combination of the two. However your team chooses to use GitBook, you’ll use a Git-like branching workflow with a full version history, which protects your primary content while encouraging collaboration and feedback across your entire team.

How do you publish documentation with GitBook?

Publishing in GitBook is a simple process once your content is ready to go live:

  1. Create a new docs site (or open an existing one) and choose the content you want to publish.

  2. Choose your site audience. You can publish to everyone with the public setting, or limit the audience with share links or authenticated access.

  3. (Optional) Customize the branding, domain, and theme using the built-in options.

  4. Click Publish. Congrats — your docs are live! You can add more spaces later as site sections or variants.

To find out more, check out our Quickstart guide above, or read the complete guide to creating and publishing documentation in GitBook.

Is GitBook open source?

GitBook itself is not open source. However, GitBook’s published docs platform — which is used to host and display documentation on a docs site — is open source. You can visit the repository to see the code and submit changes for review.

While GitBook itself isn’t open source, open source projects can publish documentation on GitBook for free. Teams can sign up for the Community plan and publish content using a Sponsored site plan, both of which are free to qualifying teams.

What’s the difference between a site and a space in GitBook?

In GitBook, a docs site is your overall documentation hub, hosting all content accessible to your audience and featuring customizable options like theme and domain.

Each site contains one or more spaces, which serve as individual sections within the site, organizing related content for better modularity and ease of management. Spaces let you focus your collaboration on specific topics, and you can combine multiple spaces on a single site to build structure or enable options like translations (for localized documentation) or multi-product support.

What are the differences between GitBook’s visual editor and Git Sync?

GitBook offers two main methods for editing documentation — the visual editor and Git Sync. The visual editor is an advanced, block-based editor that allows you to create and modify content directly within GitBook using a traditional user interface that includes Markdown support. It's ideal for those who prefer a more intuitive, hands-on editing experience without directly dealing with code.

Git Sync integrates your documentation workflow with a Git repository, enabling a ‘docs as code’ approach. This option is ideal for developers and teams who prefer managing documentation alongside their codebase, using familiar Git commands and workflows.

Your team can choose one of these workflows, or use a combination of them both. And whichever method they prefer, editing follows a consistent, Git-like branching workflow with a full version history and content review process. This doesn’t just promote collaboration and quality across your docs — it also safeguards primary content from accidental edits.

Last updated

Was this helpful?