Branching strategies have long been the backbone of efficient collaboration and streamlined release cycles in software development. As the landscape evolves, so do the strategies we employ. This article provides an in-depth comparison between the “Ship/Show/Ask” strategy and the once-popular “Gitflow” workflow.

A Deep Dive into Gitflow

Introduced by Vincent Driessen at nvie, Gitflow emerged as a structured approach to branching and release management. Tailored for projects with scheduled release cycles, it provided a clear path from development to production.

Key Components of Gitflow:

• Develop and Main Branches: These are the two primary branches. The main branch holds the official release history, while the develop branch serves as the integration point for features.
• Feature Branches: Created for new features, branching off from develop.
• Release Branches: Prepared for a release, merging into both main and develop.
• Hotfix Branches: For urgent fixes, branching directly from main.

In this example, two distinct features were developed between updates to the main branch. Due to a bug, we introduced a hotfix that was merged into both the develop and main branches. After the development cycle for these features was completed, we tested their compatibility in a production environment (Release). Subsequently, we merged this branch with both the main and develop branches to continue the development process.

The Essence of Ship/Show/Ask

Proposed by Rouan Wilsenach, “Ship/Show/Ask” is a more agile approach. Tailored for continuous integration, it emphasizes rapid deployment and feedback.
This strategy promotes continuous feedback and collaboration, especially for remote teams.

Ship: Direct merges without review.

• Adding new features with an established pattern.
• Simple bug fixes.
• Documentation updates.
• Code improvements based on team or community feedback.
• Adding new tests to prevent errors.

Show: Pull requests for review but immediate merges.

Opens a change request for CI review but merges immediately. The idea is to let the work flow forward with minimal blockages while still having spaces to discuss and improve development practices and the created code.

Ask: Opens a PR to discuss changes before merging.

• The work is extensive and assistance is needed.
• There are doubts about its functionality or code quality.
• There’s uncertainty about what’s being done.
• Waiting for something to happen before merging the branch.

Comparative Analysis

Gitflow:

• Pros: Structured, clear development-to-production path, suitable for scheduled releases.
• Cons: Complexity, potential merge conflicts.

Ship/Show/Ask:

• Pros: It’s flexible, promotes continuous integration, and is driven by feedback.
• Cons: It might be overly agile for stringent review processes.

Conclusion

As a developer, the best experience I’ve had was with teams that employed a mixed approach. The main branch was safeguarded with bi-weekly deployments, while the Staging/Development branches were open for the Ship/Show/Ask methodology.
This approach is intriguing because it combines the cleanliness of git flow’s main branch with the flexibility and empowerment of Ship/Show/Ask. As a result, each development becomes significant for every developer, fostering a sense of responsibility for their individual changes.
As always, I’ll continue to share more insights and experiences in the exciting world of JavaScript. To join me on this journey:

• Connect with me on LinkedIn
• Explore my projects on GitHub

Let’s continue exploring the vast universe of coding together. Happy coding! 😃