Faster Change Request Merges

Skip review processes and quickly merge your content.

When we launched the newest major version of GitBook, we introduced Change Requests – a new approach for maintaining immutable primary content and allowing for asynchronous collaboration and merging of drafts and new changes.

One frustration a lot of folks had with this was, compared with the previous approach of writing -> saving a draft -> merging a draft, there were more layers of UI and complexity to deal with.

What did it look like at first?

At launch, for every Change Request you wanted to merge, you first had to submit the CR for review, give it a subject, and only then could you merge it. This was an intentional design decision to allow for more productive and collaborative reviews and review-based workflows.

The problem

The problem this caused was pretty straightforward – merging content was a pain! Not everyone who uses GitBook needs complex review features; to you, this was just unnecessary overhead, getting in the way of what matters: actually creating your content.

What does it look like now?

Now, when writing a change request, you can choose between Submit for review and Submit and merge.

Choosing a strategy for Change Request submission

Submit for review will keep the same approach as we launched with: you provide a subject, the CR moves to 'Needs review', and either you or someone else with permissions can come in, check your work, and merge the CR.

Submit and merge will skip the fanfare and simply merge the CR in its current state into the primary content branch (provided there's no conflicts).

GitBook will remember which option you chose for the submit action and default to it for all new Change Requests in the space.