Version control within Salesforce can be quite a tricky topic, very quickly one will experience the conflict of knowing what is the source of truth within their organization. It seems the most educated responses on the topic always include CI integrations that help maintain some of this complexity... unfortunately they don't also come with step by step tutorials for setting up what can be a complicated structure.
Beyond these issues which have been discussed in other post, I specifically want to understand the best practices used when it comes to maintaining the versioning of different modules, components, or features within you Salesforce repository.
For example when creating a new business process you may have triggers, classes, objects, pages, etc., once that deliverable is ready for deployment I question how you handle versioning and maintaining these subsets (possibly using submodules, subtrees, other).
It would seem impossible to manage submodules (essentially separate repos) because the "sub-project" overlaps with everything (also deployment with submodules is brutal and likely not even possible with Salesforce). Classes and Triggers are ALL in the
triggersfolders (no awareness of the project it belongs to)... and unfortunately I can't just create
project-xdirectory with its own
So now even though
project-x is at version 1.0, while
project-a is at version 7.0, the Salesforce repo as a whole is at version #.##.#### ??? These are all in one ever growing repo, but each business discipline has its own development road map, so how do you manage this? Or am I asking the wrong question and overthinking this with the wrong approach?