15 ms·
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 peopl
by guptaneil 10y ago
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.
- kannonboy 10y agoAbsolutely. 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.
- sytse 10y agoI 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 https://gitlab.com/gitlab-org/gitlab-ce/issues/4176
- dmitry-k 10y agoCouldn't agree more. In RhodeCode (https://rhodecode.com 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.