Feature Request: Deploy a Specific Git Commit with Environment-Specific Variables

What problem will this feature address?

Right now deployments are mostly tied to a branch head, which makes it hard to deploy an exact known-good revision. This causes issues when we need reproducible rollbacks, staged verification, or hotfix promotion across environments.

I'm also frustrated that environment values are not clearly separated per deployment target (for example dev/staging/prod with different variable sets). This increases risk of config mistakes and makes promotion workflows less predictable.

Describe the solution you'd like

Add support for selecting a specific Git commit SHA as the deployment source, alongside current branch-based deploys.

Proposed behavior:

Allow choosing deploy source:

• Branch (existing behavior)
• Tag (optional)
• Commit SHA (new)

Show commit metadata before deploy:

• Short SHA
• Commit message
• Author/date

Persist the selected source in deployment history for full traceability.

Add first-class environment profiles (dev/staging/prod/custom), each with its own variable set.

Allow variable override priority:

1. Global/project defaults
2. Environment profile values
3. Optional deployment-level overrides

Validate required env vars before deployment starts.

Make rollback support easy by redeploying a previously successful commit + environment profile.

This would improve reproducibility, safety, and auditability of deployments.

Describe alternatives you've considered

• Creating temporary branches/tags for each release commit. Works, but adds Git overhead and doesn't fully solve environment config consistency.
• Manually editing env vars before each deployment. Error-prone and hard to audit.
• Maintaining separate projects per environment. Heavy operational cost and duplication.

Additional context

Typical workflow needed:

1. Test commit abc1234 in staging with staging env profile.
2. Promote the same commit to production with production env profile.
3. Roll back quickly by selecting the last known-good commit from deployment history.

This feature would align deployment behavior with release management best practices and reduce accidental config drift between environments.

Will you send a PR to implement it?

Yes

No files or tests are named. Start by mapping the existing branch-based deployment flow, deployment history, and environment-variable handling; then define how commit metadata, environment profiles, override priority, validation, and rollback fit together. Done means the same commit can be promoted or redeployed with the selected profile and required variables are validated before deployment.