1. You should only share the package.xml, the src/ folder, and any project specific files. It is a good idea to .gitignore all of deploy/ apex-scripts/ config/.
2. You can open the folder in Sublime, and in the tree nav, right click the top level folder that contains src/ and create a project. Your top level folder should already be in your workspace folder, and it should not have the name of another existing project.

Leveraging a tool like CumulusCI may significantly help your development process.

There could be multiple use cases for introducing a source code repository into your Salesforce development process.

Metadata backup

You could create backups of your metadata at regular intervals in a source code repository. This would give you a history and also some traceability, e.g. knowledge when something was introduced. The simplest approach to a metadata backup would probably be a full metadata retrieve which you could then check into your source code repository. No sophisticated branching strategy would be needed because you really just need the history information.

Isolation

You wrote that currently all your developers are working in a single developer sandbox. Could you achieve isolation by letting them commit their work to a source code repository individually? You'd have to work for that. But for what benefit? Isolation by itself won't provide you any additional value. Isolation may allow you to do more in parallel though - there are some that say you can better scale if you allow a certain degree of autonomy in your team(s) compared to having the whole team being aligned all times. This kind of isolation is though only really achievable if you completely isolate the work of individual developers or sub-teams from others. The source code repository could then be the point where changes from different developers or sub-teams are integrated. This integrated view in your source code repository would become your source of truth. But this would also be the source of any deployment then (because it is your only complete source of truth now). It comes quite natural to setup a continuous integration / deployment pipeline from such a source code repository. However now you also have to take care about providing the integrated results into the development environments of each individual developer or sub-team. If they are using sandboxes you'd have to take care of regularly deploying from your integrated (branch) version in the repo to those sandboxes. On the other hand with scratch orgs which are shortlived and can be thrown away once something is committed to the source code repository this comes naturally.

In short: in large (whatever number that means) teams people will start standing on each others toes at some point if they're working in a single development environment. Using isolated development environments and integrating results in a source code repository can help with scaling up teamsize. But you need to take care of getting the integrated results back into the individual development environments. Use scratch orgs to simplify this.

Deployments

My personal perspective comes largely from doing project work as a system integrator for clients. A project is typically - in my world at least - developed over a certain time, then you have a thorough test phase and finally a release. A release is something fairly large. I do like that with having individual commits to a source code repository over the timespan of a project you get a history of changes resulting in a fairly complete picture of what changes are part of your release. At the end of the release we would typically do a full deployment from the source code repository to UAT/PREPROD and finally PROD stages. With some discipline (e.g. commit message which reference your work items, i.e. Jira issues) you can have a nice traceability from your code/config changes to a requirement, e.g. your able to answer when and why a certain change was introduced. And the totallity of your customizations in the source code repository is what makes up your release. This allows to setup things like continuous integration or continuous deployments. After each commit to your repository you can trigger something that tests your release and provides immediate feedback whether something is wrong with your release. You could have automated tests on different levels of sophistication, e.g. unit tests, integration tests, automated end-to-end tests. Even automated user acceptance tests. This could then give you a lot of confidence to say: we're ready to move this into production. Or you could stop after automatically providing a new release in a testing environment.