This is an interesting way to frame this that I appreciate. It helps me better elucidate my own processes. One thing that jumps out of me is that I'd rename "A

This is an interesting way to frame this that I appreciate. It helps me better elucidate my own processes. One thing that jumps out of me is that I'd rename "Ask" as presented here as "Tell": it tells a story of work already done and implies a binary merge yes/no question, but it doesn't really "Ask" for discussion in my opinion. It's mentioned in the caveats list too that often such branches get PRed too late for meaningful discussion. Something that I try to encourage are "very early PRs" (sometimes "as early as possible") and I'd call those "Ask" branches: some PR tools allow PRs as early as an empty branch. Other times it makes sense to open a PR after writing an initial bit of documentation about how it is expected to work, or a BDD style test, or even just adding a new Feature Flag ID to the list of system feature flags. People are often hesitant to do that, but I've seen some great discussions in branches worked on in this way. Most of the PR tools today have a good user flow for it allowing you to review/comment piece at a time over time as updates to the branch are made. Various ways to signal a re-discussion point in an ongoing PR depending on the tool (@-mentions, status changes, …). Some PR tools are better than others at even some "advanced" discussion flows like force pushing a clean branch to wipe existing code-specific reviews but leave past discussion history. Adding a fourth option to the list Ship/Show/Tell/Ask maybe starts to make it maybe too many options (people love the rule of three), but I think that "open a PR early as a discussion container on approach/everything" is a sometimes very powerful tool. Personally, I don't allow "Ship" changes, and try to default more to "Show". Not because of trust reasons, but for tooling ones: I like --no-ff merge commits as a strong log encoded directly in the git DAG of every integration, even "small/minor" integrations that look deceptively simple as a fast-forward. git bisect --first-person I can trust to run at the "integration log" level, for instance. git log --first-parent gives a high level integration log as a focused place to read branch histories. (And helps answer questions such as "when did this change make it into this branch?" versus "when was it written?") I think git works really well that way using the power of git's DAG to help, and I don't have to worry about accidental bad integrations/merges hidden away in rebases that I can't find because the tools don't record/log them (outside of deep dive internals such as reflog; I have been able to do some of that work when I needed to in a past life but I'd hope to never again need to).