🔀 Ship/ Show / Ask
is a branching strategy that offers three options for making changes:
➡ Ship:
Directly make changes to the mainline. No code review required. Ideal for straightforward tasks like bug fixes or documentation updates. This approach aligns closely with Continuous Integration.
➡ Show:
Open a Pull Request (PR) for feedback but merge it immediately after automated checks pass. Team members can review and provide feedback post-merge. Great for sharing new approaches or refactored code while keeping the workflow smooth.
➡ Ask:
Open a PR and wait for feedback before merging. Use this when you're uncertain about your approach or need input from the team. Encourages conversation and ensures careful review of complex changes.
📜 The Rules
Code review isn't mandatory for merging PRs.
Developers control their own merges, deciding whether to "Show" or "Ask".
Use Continuous Integration and Continuous Delivery techniques to keep the mainline releasable.
Keep branches short-lived and rebase them often.
⚖️ Balancing the Options
The balance between Ship, Show, and Ask depends on the team's context:
Mostly Ship: When delivering well-understood features or working in high-trust environments.
Mostly Show/ Ask: When the team is new, exploring new approaches, or has lower trust levels.
💬 Conversation & Collaboration
While PRs are useful for feedback, they shouldn't replace direct conversations. Teams should maintain a good feedback culture and discuss approaches before starting work.
🔚 Conclusion
Ship/ Show/ Ask encourages a dynamic and inclusive approach to branching, helping teams find the right balance between immediate delivery and collaborative feedback.
#programming #shipShowAsk #pullRequest
From Martin Fowler: