How to restore previously committed(but NOT deleted) files in local git project-CodePudding

I had a local project directory(with some source files) which I tried to push to a new blank gitlab repo and ran into trouble. Actually for pushing the local files to the gitlab repo, I ran few git commands on local directory and now all the source src files have disappeared from the local directory. can anyone help me in suggesting for restoring those files please? Below are the commands I ran in the directory in given order which caused the files to disappear.

git init
git add .
git commit -m "Add existing project files prior to the push to GitHub."  ###This actually committed all the source files
git remote add origin https://gitlab.com/<project.git>
### Till this point the command line was showing (master) i.e master branch in bracket
git branch -M develop
git push -uf origin develop ## error: failed to push some ref ...
git push -u origin develop ## error: failed to push some refs to ...
git pull
git push -u origin develop ## error: failed to push some refs to ...
git push ## fatal: The current branch develop has no upstream branch ..
git push --set-upstream origin develop ## error: failed to push some refs to ...
git pull https://gitlab.com/ielts-cmds/IELTS-CMDS-services-grp/cmds-circuit-breaker.git develop    ## * branch            develop    -> FETCH_HEAD  .... fatal: refusing to merge unrelated histories

git checkout feature/initial ## switched to another branch..

etc. etc.

Please note, I did NOT run any remove or delete command so I am guessing those files are there somewhere in the local git references. And I cannot go back to the very initial 'master' branch now. Please help !

CodePudding user response：

You have not shown the actual error output, which would be helpful in diagnosing the more basic "what went wrong" problem, but we can say why git checkout master is not working: you simply don't have a branch named master. You have one named develop. You can switch the name back to master if you like.

git init
git add .
git commit -m "Add existing project files prior to the push to GitHub."
###This actually committed all the source files

git remote add origin https://gitlab.com/<project.git>
### Till this point the command line was showing (master)
    i.e master branch in brackets
git branch -M develop

The last operation above changed the (local) branch name from master to develop. (Note: it's safer in general to use -m, i.e., lowercase m, to avoid deleting an existing branch name by mistake. But if git init created a new empty repository, as seems likely, then there were no other branch names and this could not have harmed anything.)

git push -uf origin develop ## error: failed to push some ref ...

This probably should have worked, and knowing what the actual error output was might help. My guess is that there was an additional message, prefixed with remote:, during which GitLab was telling you something important.

git push -u origin develop ## error: failed to push some refs to ...

Given the failure with --force (-f is the same flag, just spelled with fewer characters), it's not surprising that the push without --force would also fail.

git pull

Did this work? It would be surprising if it did, given that you then say:

git push ## fatal: The current branch develop has no upstream branch ..

since git pull with no additional options also requires that the current branch have an upstream set (the git fetch step would be able to run, but the second command that git pull runs requires an upstream).

git pull https://gitlab.com/ielts-cmds/IELTS-CMDS-services-grp/cmds-circuit-breaker.git develop
## * branch            develop    -> FETCH_HEAD  ....
fatal: refusing to merge unrelated histories

This output tells me that ielts-cmds/IELTS-CMDS-services-grp/cmds-circuit-breaker.git does have a branch named develop. I cannot access that repository myself, so I have no idea what other branch names it might have.

The commits that are on that repository's develop are now available in your own repository as well. But the history—i.e., the set of commits—obtained by starting from their last develop commit and working backwards through all other commits is independent of the commit(s) on your branch named develop. That's all fine, since their develop is their branch name; your develop is your name, and these need not denote the same set of commits at all.

git checkout feature/initial ## switched to another branch..

This would just fail, given the output shown above. You would still be on your own develop.

If you have not done anything to change the fact, your own commit(s) are still on your own develop. To make this—that your develop is completely independent of their develop—less confusing, you might want to rename your own develop:

git branch -m develop my-develop

for instance.

Run git branch with no options, or with -a, to list your own branch names, or all names (your branch names plus any remote-tracking names your Git has created based on other repositories' branch names). If there are no applicable Git commands other than the ones shown above, you will still have just the one branch named develop unless and until you rename it.

To fix the problem, read a good book on Git and learn what "related histories" means, and/or see, e.g., How to repair a git history and correctly merge unrelated histories and What happens in git when you merge unrelated histories?

CodePudding user response：

Firstly, @torek for your explanation and dan1st and sytech for commenting. The solution which worked was git hard reset. So in the logs of git I found the commit ID where those files I committed. The git hard reset to that commit ID took the directory in its previous state i.e with all files restored.