Git Workflow Discussion

[chasetmartin]

This is to document the WDI Dev Team Rendezvous meeting workflow discussion on 1/22/2026:
https://fathom.video/share/SYxyx7gz-z6MhBrZJ8L2jyLnyByCmTuz

This is not meant to be a final proposal, it's meant to continue the discussion @kblake please update as you see fit, I may have missed part of your notes. Thanks!

Suggestion: align more towards GitLab Flow with a canonical main branch
https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/

For example:

Branch roles

Developers branch from main (not staging) to ensure new work always starts from a stable, approved baseline. staging is used only for integration and validation, not as a development base.

• main = 100% stable, approved, and deployable

  • No unstable work
  • Serves as the source of truth
  • Developers branch off of main for new work.

• production

  • Receives merges from main
  • Used for deployment to production

• staging

  • Catch-all integration branch - deploys to staging
  • Unstable or in-progress work lands here
  • Used to view changes, test, and walk through acceptance criteria
  • Periodically reset staging to main to return to a stable baseline
  • Allows for fast merge velocity since it's allowed to be unstable

---

Deployment model

• main → production triggers production deployment
• Feature → staging merges can happen anytime - triggers staging deployment

---

Branching philosophy

• Current approach is closest to GitLab Flow (branch per environment)
• Potential issue: velocity may be artificially slowed by branching complexity

Open question:
Is staging acting as too many things at once?

---

PR & collaboration practices

• Open draft PRs early and often for visibility - tag potential reviewers so they know the work is coming.
• Merge work sooner; avoid unrelated changes blocking progress
• Tests and AI support human review - staging should be able to accept work that potentially unstable for faster velocity.
• Regular cleanup of stale PRs
• Clearly label or title experimental or R&D work
• Delete branches on merge - change settings in Github.

---

Developer workflow tips

• Create branches freely — Create draft PRs early and often and tag potential reviewers

[chasetmartin]

One questions I have about this flow: how is vetted work then merged to main? From the feature branch - after it has been merged into staging? So in that case it would be merged into staging quickly for testing, but then would need a 2nd PR to go into main (and the feature branch would have to not be deleted on merge to staging)?

[kblake]

Great question!

main -> feature branch/PR

• feature branch can be merged to staging for testing, feedback occurs, work continues in feature branch. Can be merged to staging often.
• After feature branch is approved: 1) code review and 2) AC accepted THEN PR/branch is merged back to main where it'll eventually get pushed to production. Would not need a 2nd PR because the feature branch was originally branched from main and only gets merged to main when ready.

TBD on whether main is pushed to production automatically or whenever main is merged to production branch then that deploys to prod.

[chasetmartin]

Ah ok thanks!

[TylerAdamMartinez]

Looks good to me

[TylerAdamMartinez]

Open question:
Is staging acting as too many things at once?

Potentially, however, with a service like Vercel or others, we could spin up environments for each feature development, allowing us to test each feature in isolation.

[kblake]

Yes, that would be amazing. @kbighorse and I already did a basic proof of concept on Render.