How to push commits correctly?

Question

git

I worked with git for a very long time, but these were just educational projects where I can throw everything into master xD

Now I'm interested in several situations:
1) Until the product is finalized, then only README.md and an empty project should be stored in the master branch ?
2) For example, a developer starts to make a project -> he needs to create a separate branch, for example "dev" ? And after that, how did he create the dev branch, should he make a new branch from dev for each new "feature"?

That is, for example, the development of API. The developer was told to make endpoints for Categories(CRUD). And what should be his actions?
1) Create a new branch from dev;
2) Push commits to the new branch;
(And then the question is -> should the developer commit everything that he did with one commit? or does he need, for example, the models folder - commit as "models / entities" and so on other folders with files?)
3) Should the developer merge after checking the highest by comrade rank? And where should it be in dev?

Answer 1

There is no "should by one commit or must not"
If you are alone, you can only maintain one master.
If a team - you agree in a team, as it is more convenient for you, make it into rules and follow.
Products are different.
Quite spread git-flow, but its thoughtless use leads to a mess and overengineering.
If there is some feature that you cannot do in one commit, then you can make a separate feature branch for this feature, and develop in it. At the same time, in case of an urgent need to fix something in the master, your master is stable. Then, as soon as you finish the feature, you will be able to join the master.
The second option for using a feature branch is a pull request, if you use some kind of code review thread, and before pushing to the master, additional actions must be performed - manual code reviews or some kind of automatic tests, in general, what can you do in your CI.
It happens that several versions are being developed at the same time, then there can be several "masters" (release branches).
In simple projects, they usually just agree on a name-convention for branches, with which it is then easier to generate various release-notes, or include the ticket number in the bug tracker in the branch name.

Answer 2

1) When the product is not finished - it can be compared with your educational projects. Also at least in the master push. All "correct" work with git begins when the project has already been released. Because now production cannot be broken.
2) The rest of the logic is correct. You make a branch for a feature and maintain it.

Should a developer commit everything they have done in one commit? or does he need, for example, the models folder - commit as "models / entities" and so on other folders with files?

I have not seen this, but it is usually discussed or even a set of rules for working with git is created so that all developers adhere to it.

Does a developer need to merge after checking a friend of the highest rank? And where should it be in dev?

Well, here also how to discuss.