Home > Mobile >  Harddrive with github repo destroyed, how to reconnect?
Harddrive with github repo destroyed, how to reconnect?

Time:10-17

Working on a school project and had my git init and branch connected to my d: drive but it got fried when the electricity cut a few days ago.

How do get my work back and continue to work from the same branch?

CodePudding user response:

Your GitHub repository is stored in "the cloud" (i.e., on some server somewhere, perhaps in the Seattle or Northern Virginia area (see Where does GitHub store my code and files?, which is off topic but historic and hence grandfathered into existence on StackOverflow). Anything that has happened to your own laptop or desktop system is not relevant.

Your own Git repository is—or was—stored on your D: drive, just as you said. That repository is presumably irrecoverable. (There are certain forensic data recovery techniques but you'll find they tend to be quite expensive, and there are few guarantees here.)

The good news is this: Every Git repository stores a full snapshot of every commit it's ever had, forever (more or less).1 The bad news is this: The GitHub copy of the repository has only the commits you've sent to it.

This is the reason behind matt's comment. If you ran git push to send the commits to GitHub, and they accepted the push request, your commits exist in your GitHub repository. If not, they're not.

Note that I keep mentioning commits. Git is not about files, at least not at this level, and it's not really about branches either: it's all about commits. The commit is the unit of storage and transfer, when using Git.2 A branch name, in Git, is simply a special-purpose kind of name, with all names in Git serving to help you (and Git) find the commits.

If you did send your commits to GitHub, you simply need to clone the GitHub repository again. You will get, in your new clone, a full copy of every commit, and—initially—no branches at all. Then git clone will make one branch in your new clone, after which you can make more branches, including branches whose names match all the branches that your Git software saw in the Git repository over on GitHub.

When you go to send commits to GitHub using git push, you do this with:

git push -u origin <branch>

(for a first-time setup for a new branch name) or simply:

git push

(after that first-time step). This uses the named branch (first-time setup) or the current branch name (simpler, second-and-later steps) to find any commit(s) you have that your GitHub repository copy lacks. Your Git software then packages up these commits and sends them over to GitHub, and asks them to store those commits and create (first-time push) or update (remaining pushes) a branch name in their repository—your GitHub repository—to remember the latest of these commits. The latest commit remembers the second-latest commit. The second-latest commit remembers the third-latest, and so on. Git has, built in, the capacity to work backwards from the latest to any earlier commit, so this enables both your Git software and GitHub's Git software3 to find all the commits, starting from the latest, on that branch.


1On GitHub, this is entirely true, and on your laptop, it tends to fall into the "less" category on purpose, since Git deliberately makes a lot of temporary "junk objects" as you do work, and then runs various cleanup operations at various times to clear out the "junk" commits. You only push "good" commits—or at least, ones GitHub thinks are highly valuable—to GitHub, so they keep those forever, even if you accidentally push secret data to GitHub. So if you accidentally expose sensitive data, you need to invoke GitHub's service people to scrub it, although by the time you can get them involved, billions of nanoseconds have passed and the data have probably been copied and your Bitcoins or whatever stolen.

  • Related