Skip to main content
/images/icon.png
Normal and Fork Git models are only available on the Express and Enterprise Editions.
By default, new projects use the Simple Git Storage Model and are hosted on Prophecy-managed Git. This lets users develop projects without knowledge of Git or branching strategies. While this is sufficient for most users, advanced users may want to change the Git Storage Model during project creation to use a normal or forked Git repository. Git setup during project creation

​
Model comparison

The following table describes the different Git storage models and how they work.
Git Storage ModelDescription
SimpleProvides an intuitive visual workflow for project drafting and publication. Users all work on the same dev branch in the Git backend.
Normal (no forks)Enables the typical Git workflow aligned with DevOps best practices. Users all work in the same repository on different branches.
Fork per user(External Git only) Enables the typical Git workflow aligned with DevOps best practices. Users work on their own copy of the repository.
Regardless of the Git storage model you choose, you’ll be able to use a Prophecy-managed Git repository or your own external Git repository to host your project code.

​
Simple Git Storage Model

As you move through the Simple versioning workflow in your project, Prophecy actually maps these actions to Git processes in the backend. In other words, actions like saving, publishing, and restoring changes trigger Git commands. This is possible because all Prophecy projects are hosted on Git, regardless of the project’s Git storage model. The following diagram explains what each versioning action does in Git. If you connect to an external Git provider (rather than use Prophecy-managed Git), you can view how each action in is reflected in Git as you work on your project. Simple Git The table below reiterates the diagram.
Action in ProphecyAction in Git
Save to draft
  • Pull changes from the remote dev branch
  • Pull changes from the local main branch
  • Commit changes to local dev
  • Push changes to remote dev
Publish
  • Merge changes into local main
  • Add a Git Tag with the published version number
  • Push changes to remote main
Restore previous version
  • Run git reset --soft
  • Commit the changes to revert in dev
  • Push changes to remote dev branch
(You must manually publish the project again to merge what you reverted to main)