A new engineering paradigm for collaborative iteration.
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.
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.
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:
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.
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.
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.
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
Running the pierre version
command is the same as running git fetch && git checkout -b [branchName]@[version] [remote]/[defaultBranch]
.
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.
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:
Head over to our Notification docs to learn more about how notifications are managed and propagated.
Code hosting, review, docs, and CI. One place for product engineers and their teams to focus on what they do best—building products.
Join the WaitlistSkip the line! Join our Discord for early access