I work with a small team in a highly-collaborative, continuous delivery, environment. Up until recently, we used Perforce and Crucible to support this, which worked pretty well (with a few warts, of course). Crucible was a great post-commit review tool that helped ensure nothing fell through the cracks, while still supporting high-frequency commits (as many as 10-20 per day for some developers).

Our organization has upgraded to Git and Bitbucket, which throws a lot of complexity into supporting this workflow. We want to commit directly to main, but also want reviews that stay open until people are done with them. But reviews require branches and pull requests, while committing to main automatically closes the reviews, using a standard feature branch workflow.

I've come up with a work-around described below (with a sample issue), but it would be better if the additional steps were built into an alternate workflow that projects could select, if they wanted it. Hiding the complexity under the hood will help with consistency and user fatigue.

1. Use the Jira issue to create feature/pbeg-61-create-better-workflow-01-old
2. Use the Jira issue to create feature/pbeg-61-create-better-workflow-01-new (or use back button after #1)
3. Commit the change with an appropriate comment that includes the Jira ID
4. Push commit to feature/pbeg-61-create-better-workflow-01-new
5. Push commit to main (NOTE: Order of #4 & #5 is not important)
6. Create a pull request from feature/pbeg-61-create-better-workflow-01-new to feature/pbeg-61-create-better-workflow-01-old
   The developer can now pull/rebase from main and work on commit #2, using the progress already committed for #1. The review can stay open as long as needed, and he and all other developers can work with the new code immediately, create additional reviews, etc. Since every review has its own isolated branches, Bitbucket is doing nothing under the hood to automatically close them until we want them closed.

Once review #1 is done, it can be merged (which automatically deletes the "new" branch), and the "old" branch can then be manually deleted.

Ideally, the extra branching and deleting would be implemented under-the-hood with the alternate workflow or something similar.