Should work fine for a solo developer however I believe his point was that you shouldn't be re-writing the history.
That is, what would be the next command you use? You have just done a hard reset and removed the last commit from the history. Now your remote and your local copy have diverged. You can do `--force` of course to rewrite the history on your remote but that wouldn't be acceptable in a corporate environment because many other people also have their local copies of that repository and they'll all have issues after you force your change in.
A more transparent approach would be to do `git revert HEAD` or even better `git revert <hash>` to explicitly have your change be reverted with another commit.
The deployment git shouldn't be making commits and should only ever be a slave to wherever it pulls from. Production git clone shouldn't be pushing commits upstream.
So while it's running the previous version, you just `git pull` again to get the latest fixes for whatever broke at a later time. No history is rewritten as it fasts forward to the latest commit. I hope that clears up how it's used. As far as I know this is a common pattern of usage for deployment scenarios.
For a deployment pipeline that takes the HEAD state on the git repo, you are right, that's perfectly fine. However if you have other developers or SRE that have that repo checked out, they'll have problems. Not problems that they can't take care of, but an additional step nonetheless.
Let me clarify the scenario I'm using, as far as I can see there should not be anyone else touching the repo except production services that depend on it.
1. Push to somewhere (maybe a bare repo, or github/bitbucket).
2. Production clone pulls from the master.
If any issues arise, you can do git reset --hard HEAD^ on the production repo to rollback any changes to an arbitrary prior version.
> However if you have other developers or SRE that have that repo checked out, they'll have problems
What do you mean by this? The production repo should only be read from by production services serving from it (webserver, database, etc). Any engineers shouldn't be making commits to it and merging upstream. It should be purely be used for deployment.
I think maybe you're assuming the production repo is also the master repo? This is not something I recommend and if you use my deploy scenario, this is not how it would be setup. The production repo should just be a clone of the master, purely pulling updates from master just like everyone else, which can be on github or another bare repo that others work from. Except the production repo would also be a read-only repo. You obviously don't SSH in, make hot patches, and commit from there. Based on this, what I suggested (git reset --hard HEAD^) and having a repo deployed on the production server is a best practice for deployment. It allows for effortless roll back to arbitrary prior states, easy post-update hooks for build steps. And should upstream ever be updated, it's one command that just re-syncs (git pull) to any of the latest fixes for whatever went wrong.
That is, what would be the next command you use? You have just done a hard reset and removed the last commit from the history. Now your remote and your local copy have diverged. You can do `--force` of course to rewrite the history on your remote but that wouldn't be acceptable in a corporate environment because many other people also have their local copies of that repository and they'll all have issues after you force your change in.
A more transparent approach would be to do `git revert HEAD` or even better `git revert <hash>` to explicitly have your change be reverted with another commit.