I am not a GIT expert, however, we use GIT where I work - not for Captivate projects, but other projects - but I guess I don't see why it could not be used.
Do multiple people work on a local copy of the same CPTX file at the same time?
That would seem really problematic to me.
For us, GIT is not a working space but a storage space. Files are worked on locally and then updated to GIT.
Your team would need to work out the details of the standard operating procedures as it relates to how you need to do business.
In my position, I seldom need to utilize GIT so I cannot speak to all the features.
In our workflow - creators can all post to GIT and those with permissions can pull but we only have the original creator of a particular project update that project in GIT.
Each creator is responsible for keeping up to date their own projects. All others can download and use a file but if changes are made, they must be sent to the original creator for updating GIT.
Also, if changes are needed - I don't make the change myself - I inform the original creator of the project of my recommendations and we proceed from there.
We have three people using Captivate where I work and while we are happy to support each other - we don't touch someone else's CPTX file - at least not without them over our shoulder. We publish to a common location and provide a URL. Others give us feedback and we go and update. We don't even start versioning Until the first one is official on the LMS and to be honest, the LMS takes care of that - not us.
Have you looked that the features list of GIT? Link below.
Hopefully that helps a little bit.
Efficient version control is a distributed development team is essential.
Unfortunately, git will treat the CPTX file as a binary, and won't be able to offer diff functionality.
An efficient method of version control for Captivate would be a great add-on for Adobe cloud, but our company will not allow us to store files in the cloud, therefore we need an on-prem solution.
1 person found this helpful
I don't personally think Captivate projects are a good case for trying to use version control that goes any deeper than the CPTX itself.
It's well known that the best way to work with Captivate project files is NOT to load them into Captivate from any location OTHER THAN the local hard drive of the development computer. And you should never Save directly back to a network location either...if you are serious about avoiding project file corruption.
Additionally, when the developer inserts assets such as video, audio and images into a CPTX Captivate remembers the original pathway to the asset and stores this information in the CPTX as well.
It's obvious from all of this that Adobe didn't really design Captivate e-learning projects to work in quite the same way as a typical software application project where you might have a dispersed team of developers all working simultaneously on a multitude of small files (via Check-IN and Check-OUT version control).
As you can easily see if you open up the cache of a typical Captivate CPTX , it actually a renamed ZIP archive comprised of a multitude of files. However, the cache ALWAYS lives on the local hard drive of the development PC. Which means there's no practical way to have other users of the same file going in and changing small parts of it (without risking monumental failure).
If you are looking for an e-learning solution where the entire project was made up of separate version-controlled files, Captivate is NOT going to fit the bill. But then neither would Storyline or most other authoring tools that I can think of. You'd need to be building the entire project from the ground up in Dreamweaver of similar to get that kind of distributed effort.