I was deploying a change to production this morning, and there was an issue, and the contractor I was working with is unavailable now, despite being available just prior to deployment (eye-roll).

on my production server, I did git pull origin main, ran into the issue, and then wanted to try and revert it back. So I found the commit hash of the prior commit before this merge, and did, git checkout 612aed0227abe33f7fb8eeac5892beb0e2f67034 from the prior merge request.

It gave me this message:

However, it doesn't seem to have changed anything as I'm getting the same 500 error on production. It should've just checked out that revision right, and then everything should be fine?

I then ran git checkout main. Not sure what to do here and I don't want to break anything more than it's already broken.

UPDATE:

I somehow got it working on the prior commit, although it's still in a detached head state. I'm not making code modifications here as it's my production environment. I need to work on some fixes and then I'll need to know how to pull from main at the latest commit after that future merge I'll do.

I know enough with git to handle things when they are mostly normal. I use a handful of commands and usually I'm fine, but I don't know what a detached head is or what kind of issues I'm going to run into when I eventually pull from main again.

I don't have CI/CD set up on this project, so my normal deployment process is to SSH into the server, run git checkout ., then git pull origin main.

That's been working fine until today's fiasco. I now need to know how to get it resolved back to how it was, unless I've irreparably effed things up.

CodePudding user response：

If you want to reset your branch to that earlier commit before the pull commit, then do a hard reset:

# from your branch
git reset --hard 612aed02

What your checkout command did was to put the branch into the detached HEAD state. Temporarily the head of the branch was pointing to commit 612aed02, but the true HEAD of the branch was unchanged.

CodePudding user response：

Theory

I don't know what a detached head is

When your git repo in the detached head state it just means that your working tree (the actual files on the hard drive) is not on a branch. That all it means. It's not an error state.

what kind of issues I'm going to run into when I eventually pull from main again

If you modified files to get your code working on the prod server then it is likely you have not committed them back to origin.

This means that when you try to get the changes from origin next time you will likely get merge conflicts (because the local fixes and the remote fixes are likely be in the same files and probably even the same changes [plus new features]).

Practice

I think for your next 'deployment' you could follow these steps:

Save, just in case, any locally made changes:
1. git switch -b better_safe_than_sorry_1
2. git add --all
3. git commit -am 'PROD server as of <date_here>'
4. Now we're ready to get main
git switch main
git pull

Alternatively you could:

git fetch origin - this will download the changes made remotely but it will not apply them to your current working tree.
git reset --hard origin/main - this says: forget any¹ changes made locally and make my current working tree to what the local origin/main is. Since we did a fetch just before, after this your working tree should be identical with main on origin. This will delete any changes you made locally.

¹ = changes to the files git tracks - files from .gitignore will not be deleted. (BTW. The same applies to your pulls - any 'temp' files that git doesn't track are not changed by your pulls.)