Staging Pro Repository and Branches
When you install StagingPro in your tenant, it creates a separate repository and separate branches; does not your existing Git repository. When you add Git users in the ‘Connect GitHub’ tab, it gets associated with the separate repository associated with StagingPro.
Code commits to the respective StagingPro branch, will show up in the History & Rollback > Code Deployment tab
Staging Pro Deployment workflow
The following illustration shows the suggested ideal process as part of the Git development workflow with Pull request, that can be implemented as part of your StagingPro setup.
And the following illustration shows the suggested ideal process for hot fixes as part of the Git development workflow with direct commit to the Production environment.
As a general rule of thumb, developers first commit codes to their local branch, before it reviewed and approved for merge with a shared branch (e.g. Production branch)
StagingPro Git Branch workflow
As part of theme deployment workflow, consider the following StagingPro setup showing your mapped environments for Production, Staging and UAT.
Now consider GitHub users (developer and designer) added to StagingPro using the ‘Connect GitHub’ tab
The following ‘Git Branches’ illustration, highlights the flow that brings the following components together:
StagingPro repository on your Git Organisation
Webhook configured environments Production, Staging, UAT
GitHub users developer and designer.
GitHub user branches
