Re:Safer branching
by guptaneil on Thursday October 06, 2016 @02:33PM
(#12654856)
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.
[ Parent
| 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.