Hacker News Reader

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.

View on HN

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

Couldn't agree more. In RhodeCode (https://rhodecode.com) we use Pull Requests with a voting system. Interested reviewers are added automatically, depending on the repository and the changes being made.

Reply on news.ycombinator.com