"one should not work on master as a general practice" - did someone tell you this nonsense or you just read it somewhere?
For people who are just starting with Git: don't blindly believe everything you find on internets. Before you continue to blindly follow some so called "best practices" I highly recommend you to learn what alternatives are. And in this specific case I recommend to read about Trunk Based Development.
Isn't it a norm/best practice to have a dev branch where all the development goes down and a clean empty branch (master/main for example) where the finished product get merged to ?
Yes, from my past experience the master branch is the clean branch. Everything gets merged into that branch before it is pushed up to staging or production.
I only say "one should not work on master", if you are not team lead. I was never team lead. I was always one memeber out of 2-15 other people. So, unless I am working on personal projects, then of course, you can push stuff from master after you have merged your separate branch changes. Because no one else will do it for you.
A master branch should not be committed to. The master branch should be merged to after other branches have been through a formal approval process. Writing directly to the master branch is sloppy and unprofessional. That is a fact. Your code should be rigorously reviewed before it is ever merged into a master branch.
On a personal project is what my article is referred too. But yes, you are right. In a professional setting there usually is a team lead or dev manager who monitors this particular task of merging pieces together. In my experience I was never the one to merge things to production.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"one should not work on master as a general practice" - did someone tell you this nonsense or you just read it somewhere?
For people who are just starting with Git: don't blindly believe everything you find on internets. Before you continue to blindly follow some so called "best practices" I highly recommend you to learn what alternatives are. And in this specific case I recommend to read about Trunk Based Development.
thanks
Isn't it a norm/best practice to have a dev branch where all the development goes down and a clean empty branch (master/main for example) where the finished product get merged to ?
Yes, from my past experience the master branch is the clean branch. Everything gets merged into that branch before it is pushed up to staging or production.
I only say "one should not work on master", if you are not team lead. I was never team lead. I was always one memeber out of 2-15 other people. So, unless I am working on personal projects, then of course, you can push stuff from master after you have merged your separate branch changes. Because no one else will do it for you.
I think this is where the confusion lies.
I totally agree with you James. I have a similar workflow when working in a team
A master branch should not be committed to. The master branch should be merged to after other branches have been through a formal approval process. Writing directly to the master branch is sloppy and unprofessional. That is a fact. Your code should be rigorously reviewed before it is ever merged into a master branch.
On a personal project is what my article is referred too. But yes, you are right. In a professional setting there usually is a team lead or dev manager who monitors this particular task of merging pieces together. In my experience I was never the one to merge things to production.