4 ms·

honestly though... how many everyday devs actually use something like this?

giancarlostoro 8y ago
If you have a job where you arent allowed to commit directly to master / development branches this is probably how they enforce it. It keeps juniors from pushing bad code without peer review. It forces developers into doing PRs instead. Protected branches are the first thing we setup when we make a new repository at work once we hit the "getting good enough for production and autobuilds" stage of development.
- jsjohnst 8y ago
  > It keeps juniors from pushing bad code without peer review. It keeps all developers from pushing code without peer review. (In my experience, it’s just as often senior devs pushing broken code because “this was a simple change, why does it need review?” and it in fact being broken. Furthermore, doing PRs is not solely to “check for mistakes”, they are also used for knowledge sharing, among other reasons)
  - giancarlostoro 8y ago
    > It keeps all developers from pushing code without peer review. This is true, I don't know why I went with juniors.
    - marmaduke 8y ago
      Because junior is a state of mind not an age
- KallDrexx 8y ago
  Yeah but the concept of this post revolves around individual developer github account (not an organizational one). What circumstances would you be protecting your own private repo?
  - giancarlostoro 8y ago
    You can still use the same ruleset to force yourself to write code independently with a sane process though. I put repository rules on my personal private repositories on BitBucket and GitLab. Once you're used to a specific process and it works nicely for you, it makes sense to repeat. This way you don't ever pollute your main branches with in-progress code by mistake.
- thrownaway954 8y ago
  but you're talking about a company or corporate environment where, if they do use Github, it ain't you who is going to be in charge of the account and making a decision like OP did.
imtringued 8y ago
If a push to master triggers a deployment then protecting master is basically mandatory.

If you have a job where you arent allowed to commit directly to master / development branches this is probably how they enforce it. It keeps juniors from pushing bad code without peer review. It forces developers into doing PRs instead. Protected branches are the first thing we setup when we make a new repository at work once we hit the "getting good enough for production and autobuilds" stage of development.

jsjohnst 8y ago
> It keeps juniors from pushing bad code without peer review. It keeps all developers from pushing code without peer review. (In my experience, it’s just as often senior devs pushing broken code because “this was a simple change, why does it need review?” and it in fact being broken. Furthermore, doing PRs is not solely to “check for mistakes”, they are also used for knowledge sharing, among other reasons)
- giancarlostoro 8y ago
  > It keeps all developers from pushing code without peer review. This is true, I don't know why I went with juniors.
  - marmaduke 8y ago
    Because junior is a state of mind not an age
KallDrexx 8y ago
Yeah but the concept of this post revolves around individual developer github account (not an organizational one). What circumstances would you be protecting your own private repo?
- giancarlostoro 8y ago
  You can still use the same ruleset to force yourself to write code independently with a sane process though. I put repository rules on my personal private repositories on BitBucket and GitLab. Once you're used to a specific process and it works nicely for you, it makes sense to repeat. This way you don't ever pollute your main branches with in-progress code by mistake.
thrownaway954 8y ago
but you're talking about a company or corporate environment where, if they do use Github, it ain't you who is going to be in charge of the account and making a decision like OP did.

imtringued 8y ago

If a push to master triggers a deployment then protecting master is basically mandatory.