What is the "Ship, Show, Ask" Git strategy

Hello everyone! This month, I want to talk you about the "Ship, Show, Ask" git strategy. I use it with my teammates at Cabify, and I find it to be a wonderful way to maintain a good pace and individual productivity, while at the same time, ensuring a continuos code delivery and transparency and communication with the rest of the team.

Has you ever had a pull request or merge request blocked for days waiting for review? Do you find difficult for you or your team to review every piece of code in time? Then, "Ship, Show, Ask" could be a good fit for you or your team. Only note that, for this git strategy to work, two things must be truth in your team and your code:

• You have a mature team, where everybody knows everybody and trust everybody (how they code, how they work).
• You have a good automatic test suite and checks/regression tests that are automatically run in the pipeline prior to deploying any new code.

without the above, "Ship, Show, Ask" won't never work. Why? With this strategy, you won't always open a Pull/Merge Request. And when you do, you won't always wait for your colleagues to review it prior to merge. So yes, a mature team and good and sufficient automatic checks are a must.

Okay, after this disclaimer, let's dive into it!

What is "Ship, Show, Ask"?

"Ship, Show, Ask" is a branching strategy that combines the idea of creating Pull Requests with the ability to keep shipping changes quickly. It was introduced by Rousan Wilsenach on Martin Fowler's blog.

The changes we make in the repository are categorised into three types:

• Ship: Merged into the main branch without review.
• Show: Opens a Pull Request but merges immediately without review.
• Ask: Opens a Pull Request to discuss changes before merging.

Click on image to enlarge

The three possible categories for your changes give the strategy its name. Now, let's see each of them in detail and why. When should you use each of them?

Ship

Ship means making a change directly to the main branch. We don't expect code reviews, we go straight to production (though tests or checks will still run automatically by the CI before deployment to prevent errors).

The commit goes directly to production, bypassing the usual Pull Request.

Click on image to enlarge

Intended for:

• Adding a small change using an established pattern.
• Fixing a simple bug caused by an error.
• Documentation updates.
• Small code improvements based on team feedback.
• Adding new tests to prevent errors.

Show

Here, we use a Pull Request, but we don't expect manual code reviews. Instead, we rely on automated tests, coverage checks, and code validation without requiring another person's input. We create a Pull Request as a way to document the change and validate that automated tests pass, but don't wait for team feedback.

This doesn't mean conversations about the code won't happen. They'll just occur after merging. The goal is to keep work flowing forward with minimal blockers while still leaving room to discuss and improve development practices. The team is notified when a Pull Request is created, reviews it later, and provides any necessary feedback. The key is that the Pull Request remains easily identifiable and separate.

Click on image to enlarge

Intended for:

• Necessary bug fixes that leave a record for learning.
• Small code improvements or refactors.
• Adding new features following agreed structures.
• New functionality with automated tests.

Ask

This category is similar to Show, but here we do wait for team feedback before merging. We do this because there's some uncertainty: maybe the solution is complex, we don't know how to implement it, or there are doubts. The goal is to keep the branch alive for as little time as possible to avoid blocking others.

With Ask, we expect the team to review the Pull Request before merging. We're not waiting for an approval, we're just starting a conversation to resolve uncertainty. This is important to remark: choosing Ask doesn't mean we're waiting for colleagues' approval, but just to open a discussion before merging due to blockers or doubts. We may not need a full review, and if we do, we should clarify that.

Click on image to enlarge

Intended for:

• Large pieces of code requiring assistance.
• Doubts about implementation or code quality.
• Uncertainty about what we're doing.
• Waiting for external dependencies before merging.

The Rules of "Ship, Show, Ask"

Naturally, as stated at the beginning of this article, following this strategy requires some ground rules:

1. A good, robust, and sufficient automated test suite.
2. A reliable CI/CD system that ensures the main branch is always deployable, and that prevents unwanted errors in production.
3. Branches are as small as possible, short-lived, and always branched directly from main.
4. Trust in the team and strong development practices like pair programming, seniority, and above all, accountability. The developer decides their change's category. With great power (merging your own Pull Requests) comes great responsibility (not breaking production).
5. The team has moved past individual ego, trusts each other, and accepts that the main branch doesn't need perfect code (as long as automated tests pass).

Final Thoughts

I want to close this article as I started it, defending all the good about this strategy. I believe the core idea behind it is to empower individuals, give the team autonomy, and treat everyone equally. It also speeds up development and enables continuous delivery. But achieving this requires a lot of trust, which not all teams may have initially. Because of that, being able to apply this inside a team is an achievement in its own, as it's a proof that the team has reached a mature state, without individual egos and with trust in each others. A truly sane work environment.

I'm proud to be using it from nine to five Mondays through Fridays, and I'm glad for my teammates. Keep it going!