Accidentally deleted all in Git branch

HELP! What to do?

I made first commit. Noticed a file that is not supposed to be save with sensitive values. Did not want to get the history for this one file in there, that would be viewable still.

Proceed to revert that first commit, thinking it will go back when no files was committed.

All files are gone now as result! I cannot find in my project folder even recycle bin.


First commit? But you want to undo for a file or two? Easy peasy. No need for revert. It’s only 1 commit! Then you would not have been in this trouble you are now.

Delete the .git folder! Mind you this is before you should have done any git voodoo. Re-init git, add files, then commit. Then you’re done. You’re back in business without having so much down time.

Now going to the other solution. I have encountered this before like you. The files are still there. So to speak. Git knows it, since it has the history for that action. A simple git log will prove.

Normally, you can pick the files back one by one simply by using the checkout command. But first, get a list of these files, including full path to it. This will show all the files that have been affected or deleted in your case.

git status


git checkout path/to/filename

For a few files, this approach works. Not very convenient when you have dozens to hundreds of files to recover. This may be your situation too. For some reason, using a wildcard will not work.

git checkout *
git checkout path/to/*

It executes but does nothing.

Sometimes commands like below will do the trick. Or it won’t. YMMV. But may be limited to *NIX-compatible OSes. For Windows, use Git Bash for one.

git ls-files -d | xargs git checkout --

In my experience, I did the following steps in git.

git log
git checkout COMMIT_ID
git commit -m "Restore my files"
git checkout master

The first command is to get the commit ID.

Second is to checkout at that commit. Now you’ll be in limbo. You’re not back at master branch where you started out. Instead this checkout will be outside of master. You’ll see a message such as


This is all good. Don’t worry. Just commit those files again. That’s the third command up there.

Then once done, checkout to master. The last command shown up there.

If for some reason there are files that conflict, the switch to master branch won’t succeed. Just add those conflicting files too.

git add path/to/file/name
git commit -m "Some more files"
git checkout master

Now all is good. Look at your folder. All files are there again.

Create Fat .gitignore in Intellij

Rather than create my .gitignore file by hand or copy from a previous project, I do not prefer this method. Is there a quicker way to generate the .gitignore file with many of the things I don’t want to be tracked by Git to be included in it.


Intellij IDEA


Add that to your Intellij IDEA app. There is a button in that page to automatically download and install this plugin. Make sure the Intellij app is running before hitting that button.

Or you could simply download, then install manually. Select the Versions tab in the plugin page. Choose the version you want to download. Find the zipped file in your “downloads” folder.

To install manually, head over to: Settings > Plugins > (gear icon) > Install Plugin from Disk

The gear icon might be different with other versions of IntelliJ.

The plugin should be activated already, not needing an app restart.


For Eclipse, I’m not sure of a plugin that has pre-defined lists. I can right click on a folder/file and add to .gitignore (Team > Ignore), is what I did before. Haven’t tried an Eclipse Marketplace search.

Visual Studio Code (VS Code)

Click extension then type in “gitignore” in the search box. Look for the extension by CodeZombie. Versions as of this writing is 0.7.0.

To use, do the following:

Start command palette (with Ctrl+Shift+P or F1) and start typing Add gitignore


Another way is to go to OR and get a generated .gitignore template from there. Search/select the application, OS you want. Then copy/download the generated templates.

Fatal: Refusing to Merge Unrelated Histories

fatal: refusing to merge unrelated histories

I get this error every now and then. This happens when I created a new branch first right after a new Git project was started (by me), without bothering to base it from the Master branch. The reason is the lack of permission/access to being able to write or put anything on the latter branch.

Rather than waiting for someone to kick off the Master branch, I just go ahead and start my own branch as I’ve mentioned earlier. Later on, somebody from the team who has write permissions to Master, starts a README file just to initiate it. Thus the “unrelated histories” issue happens from then on. Two branches that started off independently from each other and with no common base.

The issue appears when I want to merge my branch to Master. Git will say my branch is behind on commit on the branch it will be merged into. If I try to merge it, it gets rejected. The pipeline also won’t allow for merge conflicts like this, and advises me to fix it first.


As I recall, this behavior started after a certain Git version only. This to avoid to unnecessarily create a parallel history being merged into the project, because a previous merge happened between to branches that didn’t have a common base.

I’ve used Git’s “–allow-unrelated-histories” option to fix this problem. I’ll do this via command line.

Pull the Master branch into mine with the option above included.

Fix the merging conflict.

Commit the changes.

Push to remote repository.

Then this time the merge request to Master will not warn that my branch is behind a commit.

Others have commented saying that rebasing also does the trick for them. I do not recall having gone that route though.

How is reproducable build guaranteed with version ranges in NPM

I know with npm, caret and tilder and some logical operators can be used to specify version ranges. This post explains a bit on how this works.

The problem now is I find it hard to rectify the use of version ranges with the idea of having reproducible builds.

I mean version ranges for dependencies means that you are not specifying a requirement for a particular version but a range of version, which might change between builds (ie a patch release of a dependency was released between the last and current build).

Reproducible build seeks to remove variability in environment ensuring that every repeated build would always be the same.

From where I stand, these two ideas are in conflict with each other, hence my question here: perhaps someone can help me understand how it is ever possible to have reproducible builds with version ranges when using npm

Go to Source
Author: Finlay Weber

What can be used as abbreviation for perpetual beta?

According to Wikipedia, we talk about stages of development;

  • prealpha
  • alpha
  • beta
  • release candidate
  • stable

But, beta also have 2 sub-stages;

  • perpetual beta
  • open/closed beta

Now if we were to version a software with these and semver. It would look somewhat like this:

  • prealpha: 0.x.x
  • alpha: x.0.0-alpha.x
  • beta: x.0.0-beta.x
  • release candidate: x.0.0-rc.x
  • stable: x.x.x

However how would these look if we want to differentiate between perpetual and open/closed beta?
Would this be allowed, and if yes would something like this work?

  • perpetual beta: x.0.0-pb.x
  • open/closed beta: x.0.0-ob.x, x.0.0-cb.x

Go to Source
Author: Keimeno