Looks like your case is pretty complex - this why I'm so happy with SalesforceDX so our teams can start using Git without any overhead and complex workflows or issues :)
First of all - yup, SalesforceDX might be a great solution for your team, however if your project is nig enough you should accordingly allocate "enough" (meaning "pretty much") time to convert it to the SFDX one, especially if you'd like to make it cool and right with smaller artifacts :) While SFDX is two levels higher (at this state) than many other SF features for developers, it's still not ideal, so time is needed to fight it's childhood problems...
And talking about the non-SFDX approach it seems to me that the best case wouold be to also invest some time to reorganize Git repo & maybe your workflow. I can't suggest you doing this, but this is what I think might be a good approach, that won't take more than 1 day for the team to switch over (maybe +1 day to add additional CI configurations):
- Change the repo structure to include TWS's project folder as the root, so there'll be "src" folder inside the repo as well as some other folders
- It also makes sense to include additional metadatas to the repository. For this case I've done a bat script with Ant task that downloaded all other metadatas (that are not supported by TWS) into the src folder. I've played a bit with package.xml file so it won't overlap with supported metadatas.
- In this case everything that's needed to replicate the full state of org will be in the repo, so dev will be able to pull, execute an Ant task to deploy everything to his sandbox and start working with the properly configured sandbox
Another approach is a bit different and the main idea of it is something like "separating repository from the TWS project". As regular TWS project is tied up directly to the org and repository, in general, doesn't case about the org - there might be issues with mixing everything together. Not 100%, but they might be. In somecases it worked very well to do the following:
- Keep the repo structure in the way how it's organized now for you
- Add another metadata types to the repository as well as 2 ant tasks to retrieve everything from the org and to deploy everything to the org
- If you want more automation - make 2 bat scripts to "pull from git & deploy to the org" and "retrieve from org & commit to the Git"
- Devs create separate projects in TWS, which are not linked to the repository in any way and work with them
With such flow the workflow looks like - pull from git & deploy everything to your actual sandbox with ant, open TWS project for this sandbox and pull changes (only for files that are included into the project and that are needed for development), develop whatever is needed and deploy to the org, retrieve everything from the sandbox into the repository folder using ant, commit your changes.
It adds overhead, but from our experience - in Salesforce devs rarely pull from git / commit to git more often than once a day, so adding 10 minutes for all of this actions won't hurt too much.
Otherwise, if not including all metadatas to the git repository - the team will need to manage both git repository & changesets (or refresh sandboxes) to merge changes. From our experience managing state of the development environment with 2 tools at the same time adds to much chaos and complexity :)
Again - maybe this can add some ideas for you :)
Regarding the option to build one file - please sorry for the miscommunication. It's not yet there, but it's in our backlog, so we will definately implement it sooner or later :)