I don't think FM has any of the version-documenting tools that say, .NET has. Sadly, I've never had any co-developers to have a need for this. Fortunately, somebody else will probably chime in soon and provide more help (it's a holiday here today).
Its just my opinion, and I'm no expert, but I think the tool will only be as good as your company's procedures and culture. An FM database is as good a tool as any for tracking version changes. Without good management and processes it can be a real nightmare. I worked in a multi developer environment where this was a problem, but it wasn't the tools that were the issue but the processes. If the management of your company see the importance of managing versions properly and documenting changes clearly then I reckon you could just as easily use an FM database as the tool for managing it.
Not sure this helps, but you hadn't had any answers, and I think it is an important topic that you have raised.
Implement a sound backup strategy.
Always develop on FM server.
If you have to go to a more traditional dev/staging/prod strategy then careful deployment planning is a must.
You have to reconcile schema differences before you try to move data.
Its not easy but it can be done.
I recently saw a demo of BeezWax's Inspector Pro. It has the ability to compare two copies of the same file and list what's different between the two based on their Database Design Reports. This is not a full up "version control" tool, but it can definitely be a part of this process.
One thing that I have instituted where I work is a simple process of documenting change within scripts in our large system:
We've always had a "header block" of comments where we document what the script does and who created it. There's a "modified by" section there where we enter our name, date and what we changed each time that we modify the script.
To that, I've started the process of encapsulating the new code in comments in this pattern:
Phil 11/25/16 Begin change
New code here
Old code here, disabled
Phil 11/25/16 end change
The idea is two fold: to be able to quickly find and examine the most recent changes made to the script and to be able to quickly revert the script by disabling the new code and enabling the old should the need arise.
The final "rule" to this is that developers are encouraged to remove the Begin/end comments and disabled code for any changes more than 1 month old. We have back ups after all so this is mainly to help make updates to the script something that can be managed gracefully with a "fall back" option something that we can quickly take advantage of.
For complex updates of a given script, We will simply duplicate the script and put an "expiration date" in the script name so that we can use it for the above purposes without having to go through and do 30 different cases of commented changes to document the update.
For Layout updates, I've added another tool. I've built in a "help window" system where users can click a button and see a "table of contents" of help info about the current layout or layout feature where they clicked the button. They can then click a topic to read 2 or 3 paragraphs of info about that topic. I built into this tool the ability to add "developer notes" that do not appear in the Table of Contents unless the user has [full access]. I can thus use these notes to both document less than obvious layout features (There's an slide control located inside the xyz popover panel...) and to document recent changes made to that layout.