In Dynamics 365 for Operation, you could either use Team Foundation or Git.
Each developer needs their own virtual machine (VM). This was already the recommended approach with Dynamics AX 2012; now, with Dynamics 365 for Operation, it’s mandatory.
You will need a TFS/VSO server that has a main repository (typically the code that matches your Production AX environment). Then you branch off a development branch from the main repository. Each of your developers will have their own VM and connect to the same branch.
All check-ins and check-outs are happening against the dev branch, and, upon check-in, your developers will get the popup window to resolve conflicts. Once they get used to it, they should be resolve any conflicts on their own by just looking at it; no big overheads here.
If development is finished and tested and you are ready to release it to production, all you need to do is hand-pick the change sets that are ready to go and merge them with the main branch. At that point, a code gatekeeper should go through the objects one by one to proof-read and double-check their work.
Once the branch merge is complete, you could trigger off the build from the main branch, and deploy that code/package to production.