The deployment failed. The build log was clean until the last step. Now your OpenShift app is broken, and you need to reset fast.
Using git reset in an OpenShift workflow is straightforward, but precision matters. In most cases, you want to roll your source code back to a known commit, update your repo, and trigger a rebuild in your cluster. Here is the clean way to do it.
First, identify the commit you want. Run:
git log --oneline
Copy the commit hash of the stable version. Then execute:
git reset --hard <commit-hash>
This sets your working directory to match that commit exactly. If you have branches dedicated to deployment—for example, main feeding directly into your OpenShift build pipeline—push the reset state up:
git push origin main --force
Force pushing is disruptive. Only do it when you are certain the reset is correct. In OpenShift, the Source-to-Image (S2I) process will rebuild automatically when the updated branch is detected. If you are using Webhooks or CI/CD tools tied to OpenShift, verify the trigger is active so the reset kicks off deployment without manual intervention.
For deeper rollbacks, match your git reset with an OpenShift deployment rollback. Use:
oc rollout undo dc/<deployment-config>
This pulls your cluster back to the last successful image. Combining git reset with an oc rollout undo gives you both source and runtime rollback in seconds.
Keep your pipeline tight. Store tested commits. Automate build and deploy triggers. In OpenShift, speed is leverage—the faster you reset, the sooner your environment is stable again.
Want to see this reset-flow work end-to-end without touching local configs? Check it live in minutes at hoop.dev.