Do we need to work each developer in a different dev environment? if not, is there any way to work in the same environment without step on each other's toes?
When developers work in the same org, they tend to overwrite each other's work. You can avoid this with frequent communication and setting up some safeguards in each IDE (like checking the modified stamp before each commit, doing merges, etc). At minimum, developers need a CVS (Git or SVN, for example) in order to fix the mistakes that will happen from time to time.
This was the inspiration for DX. In DX, each developer creates temporary orgs that are used for development. One environment per developer. If you decide not to use DX, you should still have each developer in their own org. Pre-DX, the typical scenario would be that each developer gets their own sandbox. Unfortunately, sandboxes tend to not get refreshed regularly, which has its own complications. If practical, move to DX.
The project managers just add metadata on Salesforce and not writing code, should they all work in the same environment or in a mutual environment with the developers?
Metadata should also be in your repository. Like code, it can conflict if incompatible changes are made. Also, it makes it more likely that a developer will accidentally wipe out some configuration (say, a validation rule) if they are not aware that such changes have occurred. Also, a metadata change (again, a validation rule) could result in failed unit tests or code that breaks because of the new rules. PMs should also work in scratch orgs and also commit changes to the repository.
What is the right process for a developer from the moment he pulls the origin master from Git until he push his feature / component?
The general process is as follows:
Create a Branch
In your repository, create a new feature branch to work on. You'll use this to keep your changes separate until you're ready.
Create an Org
Create a new scratch org or Sandbox. This should ideally be done weekly or sooner with scratch orgs and sandboxes. You can use Developer Orgs, but that tends to complicated after a while, so developers tend to only create them infrequently. They also have the smallest storage space, and so are rarely useful for continual development.
Push Code
Update the sandbox, developer, or scratch org with code from the repository. This should be done periodically throughout the process as well to avoid working with old code and metadata.
Do Development
Use the IDE of your choice, or if using DX, you can work directly in the org and pull changes back to your repository.
Run Tests
Make sure all unit tests are created and updated, and test before committing.
Commit to Feature Branch
Save your changes that you've made in your feature branch with commits to make sure that you don't lose your changes.
Do It Again
For longer features, you may end up starting over from the Create an Org step several times, possibly merging the parent branch back into the feature branch to keep code up to date.
Merge Final Changes
Finally, once the feature is complete, the changes are merged to the parent branch. There's a few merging strategies that will depend on your exact cycle, but typically expect a few more orgs between this point and production, usually a QA and a UAT org for quality assurance testing/bug finding and user acceptance testing for users to test new features before they're implemented globally.
Note that there are several different, valid types of development cycles that may be more or less complicated than presented here, and its worth the time to do some research, experiment with a few models, and tweak it to suit your needs. It also depends on your methodology, such as Agile or Scrum development, and other tools you may be using.
Note
This is a big one. Developers should typically not be pulling from master unless they're doing hotfixes. This tends to lead to all sorts of nasty merge conflicts later on down the road. A better approach is a multi-branch strategy. Master represents a golden copy, the state of production. Hotfixes should be branched from master since they need to happen first/fast. There should also be at least one branch (probably two) that are used for QA and UAT. UAT should be branched from master, and QA from UAT. feature branches should come from the QA branch. Definitely do your research before starting down a particular branching strategy.
