Continuous Branches

Overview

Historically, branch collaboration ended when you merged a pull request. You’d make a change, get a review, merge it, and then never see it again.

But what if someone reviewed your change after you merged it? Or what if this merged change was just the first piece of a much larger effort?

With continuous branching on Pierre, we’re setting out to normalize a number of behaviors that were previously impossible on traditional Git platforms. Behaviors that we think will lead to more collaboration and faster iteration speed.

Ship incrementally

At it’s core, Continuous Branching is incremental shipping from the same branch surface over time. Think of it like shipping branch "versions", like v1, v2, etc from the same "pull request". This can be pushing a fix to a previously merged branch, or shipping iterative chunks towards a bigger effort (like migrating a data layer or building out a new feature).

What makes this special is that with Continuous Branching, you can ship many small, iterative, and easy to review changes from the same timeline while retaining all of the relevant context from conversations, attachments, and code.

Review code, even after merge

Continuous Branches are the first engineering surfaces designed from the ground up to enable reviews both before and after merging. This is important for a few reasons:

1. Code reviews don’t have to be blocking.
   Your ability to have your code reviewed shouldn’t be tied to your ability to ship. CI is green? And you’re making a simple change? Request a review, then merge freely. Your reviewer can show up afterwards and approve or leave feedback. If they catch something that needs a change, push a new version to the same branch surface that addresses their feedback and resolves their comments.

2. Review windows optimized for more time and more eyes.
   In today’s world, your window to review a change is very small. If another teammate reviews your branch, chances are it will be merged before you ever see it. Allowing for post merge reviews means more members of the team can review changes and leave feedback (hours or even days later), all without blocking shipping.

3. Approve, with follow ups.
   In traditional code review, all reviewer feedback needed to either be addressed before merge or would need to be captured in a separate "follow up" branch. The issue with this is that follow up branches lose all the context and conversations from previous reviews, and require manual linking and re-pinging of reviewers. With Continuous Branches, you can merge now and then push a follow up directly to the same collaborative branch surface. Past reviewers will be notified of the new version and all of your comment history will be maintained.

How it works

All branches on Pierre automatically support continuous branching. To push a new version of a branch, create a new branch appended with an @ and an incremented number.

# Original branch: my-feature

git fetch && git checkout -b my-feature@2 origin/main

To simplify this workflow locally, we’ve added a command to our CLI. Run this command from any existing branch to create a new version.

npx pierre@latest version

It’s important to note you can’t have more than one version of a branch in active development. This means you can only push a new version of a branch after the previous version has been merged. If you have an active, unmerged version, trying to push the next version will be rejected by our Git server. Pushing a version that’s non-serial will also be rejected (e.g., trying to go from @2 to @4 without a @3 ).

By default, all actions from the dynamic island (like approve and merge) are applied to the most recent branch version. However, reviewers can review old versions by commenting on them or clicking "Approve this branch" on a change’s activity stream.

After a merge, branch authors will be shown a callout to help push the next iteration of a continuous branch.

Notifications

One of the things that makes working with Continuous Branches most elegant is that all stakeholders automically get notified of any new activty. Activity items include:

• Pushing new versions
• New comments, reactions, and reviews
• Approvals

Head over to our Notification docs to learn more about how notifications are managed and propagated.