Using Mavensmate with multiple developers and with multiple unrelated salesforce orgs

This is great question.

Here is how we can set them

1. Every developer has their own org and provide a unique branch to each of them on git or bit bucket
2. Keep a master branch where each individual dev will submit pull request and on each pull request you will merge them into master branch.
3. Set up an automated process on the master branch to compile the code and do an automated build to confirm that merge is valid and code broke nothing.

If you have tools like CumulusCI or CircleCI life is easy to set up automation.

You can create multiple projects in mavensmate and should not be any difficulty. It will open in separate windows.

Answering precisely:

1. Its not best practice to share sublime text configurations. Maybe you can share the project default settings but since every user can again personalize its not best to share those or version those

2. Currently way Mavensmate works is you have to create your project. In eclipse we had option to add force.com project behavior. But in mavens seems to be no way.

Creating a new project and having multiple git repos is a pretty straight forward task in terms of MavensMate, SublimeText, SourceTree (assuming you use a git ui for commits), etc. It doesn't sound like you are doing continuous integration or any actual building on the repo side, so this should be pretty easy for you and anyone else to adapt to, especially given you have experience using the tools already.

I like to start with a standard folder that will hold all my Source-Controlled projects. For now, we will call it SalesforceSource. Within SalesforceSource, I will keep git clones of any projects i am currently working on in any of my git repos. So inside of SalesforceSource, we may see Dev1 and Dev2, where each holds different metadata for two different orgs, and are synced up to two different git repos. This allows for one root folder to hold all my different git projects and keep things "clean" on the folder structure side.

At this point i would assume you already know how to take a full retrieve of an org and move it into a repo in source control (using the ant migration tool as noted). From here, i actually like to switch over to SourceTree to manage my git stuff before i create my project in MavensMate. So as noted earlier with Dev1 and Dev2, I would actually create those two folders under SalesforceSource using SourceTree and let it handle bringing down all the git stuff with it. What i end up with after pulling down Dev1 and Dev2 from different repos are two different folders of Salesforce Metadata that i can actually convert into different MavensMate projects and connect them directly to their respective orgs using the MavensMate UI. You can do this super easily by simply opening those cloned folders from SourceTree into SublimeText, and then create a MavensMate project by right clicking on the root of that folder structure and creating a new MavensMate project from them.

In Sublime, go to File>New Window

In the new window, go to File>Open Folder

Open whatever folder is the clone of your repo. Mine here is MonkeyBox. (note I'm only showing SourceTree here so you can see how that clone should be setup. You don't actually have to go to SourceTree in this step)

Right click on the folder root and select MavensMate>Create MavensMate Project

As far as your questions are concerned, keep sublime settings out of source control. There is no need to store people's personal configurations server side, especially when sharing code with other devs. Leave those local, and i would add them to the gitignore to make sure they dont come across accidentally or you may end up pointing someones project to the wrong default workspace or something of the sort.

When working with other developers, you typically DONT commit against master all the time. A lot of devs i know are used to just committing to master but i think this is bad practice for multidev environments. If you are using git for a fancy backup solution, its fine, but working with multiple devs you can step on each other's toes super fast always overwriting master. A typical CI development cycle would have developers check out master, create a branch for the ticket or change they are doing, do the change and submit a pull request for it to be merged with master, merge into master upon approval, and then repeat the cycle. So in simple terms, create branches for every change you are going to make as a dev AFTER you pull anything else other people have done from master.

Feel free to ask if you have any specific questions. I think i have a general dev cycle with git flow i may be able to find on my other pc, and i have a training video i give to my devs that literally covers this entire process step by step, with example changes being made in a dev org and pushed into a single sourced controlled org.