Orbital Surveys Geospatial systems

Orbital Surveys

Live and Local Dev Workflow Design

Live and Local Dev Workflow Design

Status: Approved

Goal: Keep the existing gps.co.za GitHub Pages site stable while providing a separate local development copy for reviewing changes before publishing them to master.

Architecture

  • The current checkout remains the live repository and stays on the master branch.
  • A sibling checkout at C:\Users\dms\OneDrive\Documents\GPS Webpage-dev is created from the current live state and uses a dev branch.
  • The dev checkout uses the repository’s existing Jekyll server command and is previewed at http://localhost:4000.
  • The existing GitHub Actions workflow remains unchanged: pushes to master build and deploy the site to https://gps.co.za.

Workflow

  1. Make website changes in the GPS Webpage-dev checkout.
  2. Run the existing local Jekyll server and review the result at http://localhost:4000.
  3. Commit development changes to the dev branch.
  4. When the changes are approved, merge dev into master.
  5. Push master to the existing GitHub repository.
  6. Confirm the GitHub Pages deployment completes and the live site reflects the approved changes.

Safety and Verification

  • Confirm the live checkout is on master before publishing.
  • Confirm the dev checkout is on dev before making development edits.
  • Verify the Jekyll site builds locally before merging.
  • Do not copy or publish the generated _site directory as part of the workflow setup.
  • Do not change the existing Pages workflow or the live CNAME configuration.
  • Document the repeatable commands for starting the dev preview and publishing approved changes.

Alternatives Considered

Separate GitHub Pages repository

This would provide a public generated URL such as https://devinshark.github.io/GPS.co.za-dev/, but requires a second repository and a second Pages deployment path.

dev.gps.co.za subdomain

This would provide a polished public URL, but requires DNS and custom-domain configuration that is unnecessary for the requested review workflow.

The local dev checkout is preferred because it is the smallest reliable change and preserves the existing live deployment path.