Safer branching

If your company is large enough that somebody can be stuck on a problem somebody else knows the answer to (i.e. pretty much any company with more than ~10 people), you should not be committing directly to master. All commits should be submitted via a pull request that passes your CI and code review (and ideally QA review too) before being merged to master.

Nope.<p>My command line git workflow should not require working through a GUI.<p>Now, if this was added as some git hooks, enforcing the policy from both the command line and GUI then I&#x27;d be impressed (and excited).

This is a cultural problem not a technical one. The social contract in a dev team should strictly enforce no cowboy commits to master…ever. If Bob thinks that’s OK, there are more issues than a UI warning is going to solve.

I felt it was an odd post for using as example a workflow which is common and then in the end trying to depict as something the developer has to be blamed for, for not using a UI for branching out.<p>Furthermore, using their UI doesn&#x27;t guarantee that pipelines have been setup to test the commits in the repo. The article actually is about bitbucket pipelines, but hardly illustrates any of it.<p>I hardly use the web UI of remote repos unless I have to submit or review PRs. Especially the bitbucket UI which I find lacking intuitiveness when you start navigating the repos.

My automated build&#x2F;test server adds a tag (build-pass) to commits that pass the build and another tag (tests-pass) to builds that pass all tests.<p>So, instead of branching from trunk I would branch from tests-pass and that would be guaranteed to have been tested and pass, e.g.,:<p>$ fossil branch new my-new-feature tests-pass<p>I even added some CSS to make this look fancy: <a href="http:&#x2F;&#x2F;www.rkeene.org&#x2F;viewer&#x2F;tmp&#x2F;fossil-with-tests.png.htm" rel="nofollow">http:&#x2F;&#x2F;www.rkeene.org&#x2F;viewer&#x2F;tmp&#x2F;fossil-with-tests.png.htm</a>