Let's say it's at `/var/tmp/my-process-models` and that you are firing up SpiffWorkflow on your local machine outside of Docker (you can absolutely use Docker if you choose):
If you want to collaborate with others on a shared environment and you want process model editing to be allowed, you can set up bidirectional syncing with Git as follows.
Editing process models locally is another perfectly good option, depending on your needs.
There are other guides for running SpiffWorkflow on your local computer, so follow the one that you prefer (Docker Compose or native).
Then, when your process model repo is configured as you desire, you can run it in a read-only mode on your shared environments like dev, staging, and prod.
To do that, follow step 2 under Bidirectional Syncing with Git, but you also have an additional option of "baking the models in" to your spiffworkflow-backend image.
That is, you could choose to write a Dockerfile like:
Probably the best way of promoting models is to do work on a specific branch, and then merge that branch into the next branch (maybe staging if you are actively changing dev).
This is activated via `SPIFFWORKFLOW_BACKEND_GIT_PUBLISH_TARGET_BRANCH`, which is for a specific use case where you want to publish specific process models from the source branch to a target Git branch, rather than promoting the entire Git branch.
A publish function appears in the UI when `SPIFFWORKFLOW_BACKEND_GIT_PUBLISH_TARGET_BRANCH` is set.
It is possibly not a recommended strategy for promoting changes, however, as it is not a standard Git workflow, and it is more error-prone in situations where multiple process models need to work together.