Branches and pull requests for papers: co-authors propose, you decide.

Picture the week before a deadline. Your co-author wants to restructure the methods section. You're halfway through tightening the introduction. Your supervisor has promised to "have a look at the results" at some point. On a shared document, all three of you edit the same text at the same time, and nobody can tell which changes were agreed and which were an experiment.

Software teams solved this years ago with branches and pull requests. Luzbase brings the same idea to papers, minus the command line.

What a branch is, in plain terms

A branch is a parallel copy of your project. Your co-author can rewrite the methods section on a branch called methods-rewrite, and the main version of the paper doesn't change at all. You keep writing. They keep writing. Neither of you overwrites the other.

To make one, open the project's Branches tab and click New branch. Give it a name and choose where to Fork from, usually main. You can also start a branch from any older version in History, which is handy when you want to try an idea against the draft you submitted rather than today's.

What a pull request is

When the rewrite is ready, your co-author opens a pull request: a request to bring the changes from their branch into main. They fill in From, Into, a Title and a Description ("Shortened methods by a page, moved the dataset table to the appendix"), then click Open pull request.

Everyone on the project now has one place to:

see exactly what changed, file by file
discuss it in the pull request conversation
approve it, or ask for another pass

Nothing reaches main until someone clicks Merge.

Edits combine on their own

Here's the part that surprises people. If your co-author changed section 3 and you changed section 1 in the meantime, merging just works. Luzbase combines both sets of edits automatically. You only step in when two people changed the same lines in different ways, and even then you get a clear side-by-side view to choose from (we wrote a separate guide to resolving conflicts).

You set the rules

Project owners decide how strict the review should be. Under Settings → Branches & merging you'll find:

Protect main: only the owner edits `main` directly. Everyone else proposes changes through a branch.
Required approvals before merge: 0, 1, 2 or 3. Approvals come from owners and editors, never from the person who opened the pull request, and they count only for its latest version. If someone pushes a new change after you approved, your approval doesn't silently carry over.
Delete branches after merge: keeps the Branches tab tidy.

A two-person paper might keep approvals at zero and use branches only for big rewrites. A five-author grant proposal might protect `main` and require two approvals. Both are a couple of clicks.

Why this matters for a paper

A paper isn't code, but it has the same problem code had: several people changing one shared thing, with real consequences when a change goes in by mistake. Branches give you three things a shared document can't:

Freedom to try things. Cut 800 words from the discussion on a branch. If it reads worse, close the pull request. Nothing is lost.

A record of decisions. Every merged pull request says who proposed what, who approved it, and why.

One person in control of the final text. The corresponding author decides what lands. That's often the person who'll be answering the reviewers anyway.

Getting started

Open any project, go to Branches, and create your first branch. Make a small change, open a pull request against main, and merge it. It takes about a minute, and after that the workflow feels obvious.