Live data from Hacker News

Safer branching

blog.bitbucket.org

11–12 of 12 posts

Re: Safer branching

#11

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.

Absolutely. An alternative title for the comic would be "For the love of branch permissions". The second developer in the comic is doing the right thing by creating a feature branch. However even in a strict branching workflow, there's still a chance you'll have genuine integration failures when two branches are merged, even if they independently pass the tests.

I totally agree it should have been a merge request and the master branch should be protected so novices can't merge to it.

There is a chance that the merge itself breaks the build. I must say that in practise we don't often see this. Maybe because we keep our branches small. Other people seem to be more aware of this problem https://gitlab.com/gitlab-org/gitlab-ce/issues/4176

Re: Safer branching

#12
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.

Furthermore, using their UI doesn'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.

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.

Post reply on HN