Git is the most frequently used version control system. This is mainly because it is capable of handling anything from websites to large microservice-based apps. Working with Git is usually a seamless process. A real walk in the park until it starts to rain. You create your branch and do countless regular commits. But, suddenly, something happens that completely catches you by surprise. You are not quite sure why and what it is that you have done wrong, but Git just faced you with the following message:
fatal: not a git repository (or any of the parent directories): .git
In today’s article, our web development agency in Chicago reveals possible reasons for this outcome as well as ways to solve the fatal: not a git repository error.
Understand how Git repositories work
We, as human beings, are wired to build a one-way connection between problem and solution. As soon as we encounter an issue, we search for a generally valid solution without trying to understand the cause of the problem. While this approach can be valuable for most of Git’s issues, understanding the under-the-hood mechanisms of this version control system can get you much further. This section of the article will outline some basic information to help you better understand how Git repositories work.
Git features a remote repository stored on a third-party server and a local repository in our local machine. Instead of having a single copy on a central server, each developer has a copy on their own computer. That means that we can find the code in more than one place.
The first thing you need to do upon downloading and installing Git is to clone a repository (if you have access to it) or initialize one. These two actions are respectively done with the following commands:
- git clone <repo_path>
- git init
This way, you’ll create a folder named .git. The folder contains all the info about your repository that Git tracks, such as:
- Commits
- Branches
- History
The process of contributing to a repository goes as follows:
- Stage the files: The first step in adding the files to a repository is adding them to the staging area. The staging area serves to track the files that are yet to be committed. You can stage individual files with git add <file_name> or all files with git add . command.
- Commit the changes: In this step, you move the files from the staging area to the local repository with the git commit -m <your_message> command. The message should contain info on the changes you made to the files.
- Push the code: Now, you use git push to push the changes from your local repository to the remote repository.
What are the usual reasons for fatal: not a git repository error?
The error you received is a Git error. That means that Git is installed on your local system and that the executable is accessible on the local path. With that in mind, we can rule out any issues associated with installation.
The error message is telling you that you issued a command inside a directory that Git doesn’t recognize as a Git repository. In other words, the version control system doesn’t track the directory, so Git can not perform the action you requested, such as:
- git status
- git add
- git commit
So, how does Git determine whether you are in a Git repository? It does that by looking for a hidden folder named .git in the current directory or one of its parents. That folder should be located at the root of your project tree. In case Git doesn’t find this folder in your directory, it will display a message:
fatal: not a git repository (or any of the parent directories): .git
There are a few common reasons for this message. We’ll present them in the order of likelihood:
- You are most likely required to set up a new local repository or clone an existing one.
- It is somewhat likely that Git couldn’t locate an existing repository on your local machine.
- This is very unlikely, but you may have deleted the entire Git repository or the .git hidden folder.
- This happens almost never, but let’s say that the state of your local repository somehow got corrupted.
In continuation, let’s explore the ways to mend the fatal: not a git repository error by addressing these reasons.
How to set up a new repository?
Before running commands in Git, you have to create a Git repository. Whether you are just starting with your project and need to create a new folder, or you already have a project folder that contains all the resources, the process goes as follows:
The first thing you need to do is open the command shell of your choice, based on the operating system you are using:
- cmd on Windows
- bash on Unix-like systems
- Terminal on Mac
Once there, follow these steps:
- Create a new project folder in case you already don’t have one
- Use cd to go into your project folder (you need to be at the root of your project’s folder tree)
- Enter git init
This is what the command output should look like:
mkdir my-project (Only in case you are creating a new folder)
cd my-project
Git init
Initialized empty Git repository in /home/me/projects/my-project/ .git/
If you already have existing sources, you need to add them to the repository via git add and git commit. By entering git add, you are actually staging (preparing) the changes you made to files in the repository for a check-in. To check-in (commit) these changes, you need to enter the git commit command followed by a short commit message. That message should describe the changes that are being committed. This is what it should look like:
Git add .
Git commit -m “Initial commit”
[master (root-commit) 0879183] initial commit
33 files changed, 6589 insertions (+)
create mode 100644 LICENSE-MIT
create mode 100644 README.md
The repository will store the info on the state of your files each time you make a commit in Git. That is why it is in your best interest to do a commit as soon as you make any significant change to any of the files.
How to clone an existing Git repository?
This action would be necessary only if you are joining an existing project, as opposed to starting a new one. In that case, you’ll need to clone an existing repository to your local machine.
This is a relatively simple process, and it is performed via the git clone command. However, if you are cloning remotely, you need a URL to the remote repository. On the other hand, in case you are cloning locally, you need a file system path to your repository folder or share.
For example, let’s clone a repository from GitHub. Luckily, they offer various training projects for us to experiment with. We’ll use the project called Spoon-Knife. As we have already mentioned, to download the files, we simply need to enter the git clone command. Here is how:
git clone https://github.com/octocat/Spoon-Knife
Cloning into ‘Spoon-Knife’…
remote: Enumerating objects: 16, done.
remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16
Unpacking objects: 100% (16/16), 2,24 KiB | 458.00 KiB/s, done.
After using the cd command to navigate to the Spoon-Knife folder, you can issue any Git command to verify that the fatal: not a git repository message will not appear for this local repository. Let’s use the git status command and follow what happens:
Git status
On branch master
Your branch is up to date with ‘origin/master’
Nothing to commit, working tree clean
Voila. You have successfully retrieved the sources and created a local repository.
How to locate an existing repository?
In case you already had a local project folder tracked by Git, you should manually check if there is a hidden .git folder in the current directory. To do so, use the following commands:
Unix-like systems:
ls -a
Windows:
C:…>dir /d
These commands will list all the hidden folders along with visible ones. By issuing cd .., you can go back through each of the parent folders and check if the hidden .git folder exists.
Alternatively, you can employ the Linux find command to search the entire system:
find / -type d -name “.git”
With the help of /, you can specify the path of the folder from which you want the search to start descending into child folders. In our example, the search starts from the system’s root directory. The -type d command means that we are only looking for directories, while the -name “.git” specifies the name of the directories we want to be listed if discovered.
Windows users can search for the .git folder via file explorer. However, the tool doesn’t search for hidden folders by default, so you’ll need to specify it in the settings menu.
What if you have sources along with the Git repository, but there is no .git folder?
This is not unusual. You may download the sources in a compressed archive that doesn’t include the version control files. Or perhaps there was the .git hidden folder, but you accidentally deleted it.
In case you made no modifications to the sources, you can always download a fresh local project copy. On the other hand, if you modified the sources and you need to add those changes to the repository, you can clone the project into a new folder and copy the files you modified over their counterparts in the new tree.
Remember to compare your version of the files in question to their counterparts. By failing to do so, you risk overwriting recent changes made by other members of your team. You can make a side-by-side comparison for more minor changes, and then simply cut and paste those changes. Alternatively, you can use the git diff command.
However, we believe that the best thing you can do in the current situation is create a new branch in the repository. Then you should copy your files over those in the newly created branch and merge the branch with the master. Here is how:
Note: Every Git repository contains one main branch. That branch is usually named master, but it may also be named main. If you are unsure about the name of your main branch, use the git branch command, and Git will list all the branch names within your project.
Let’s begin by creating a new branch and switching to it:
git status
On branch master
git checkout -b my-changes
Switched to a new branch ‘my-changes’
Now, copy the files you modified over the files in the repository. Don’t worry; the changes we make here won’t affect the master branch just yet. Once the files are copied, let’s commit the changes and switch over to the master branch.
git commit -a -m “Copied over files.”
[temp 64295f3] Copied over files.
1 file changed, 6 insertions(+)
git checkout master
Switched to branch ‘master’
Your branch is up to date with ‘origin/master’.
The files have now reverted to the original state. However, if we were to go to our my-changes branch, we would still find the copied versions. The next thing we should do is interactively merge the changes from the my-changes branch into the master branch.
git checkout -p my-changes –
Git will display the changes in small blocks for you to approve. It will show the code that is being replaced above the one replacing it. You can use the s option (if displayed) if you want Git to break its currently displayed block into smaller pieces. This is what the entire process should look like:
git checkout -p my-changes –
diff –git b/index.html a/index.html
index a83618b..cf2b983 100644
— b/index.html
+++ a/index.html
@@ -16,5 +16,11 @
-<img src=”my-dog.jpg” id=pet-pic” alt=” “ />
+<img src=”my-cat.jpg” id=”pet-pic” alt=” “ />
(1/1) Apply this hunk to index and worktree [y,n,q,a,d,e,?]?
Lines preceded by a “-” are going to be removed, while lines preceded by a “+” are going to be added. You can enter “?” to display a list of useful options. Here are some of them:
- ? – available options
- n – reject the currently displayed block’s changes
- y – accept the current block
- s – break the current block into smaller chunks
- e – edit the current block in the terminal’s graphical editor
Once the session is finished, your changes will be merged. Also, the changes made by your team members will be preserved. Keep in mind that this process doesn’t automatically commit changes, so you need to do it yourself.
What to do if your Git repository gets corrupted?
Although you’ll probably never face this problem, there are still ways to fix it. However, before we start working on this issue, it would be wise to make a copy of the project tree in case something goes wrong.
First, let’s use the git fsck command to verify that the problem exists. Like in the cases above, Git will display the fatal: not a git repository message.
git fsck
fatal: not a git repository (or any of the parent directories): .git
When a Git repository gets broken, it is usually extremely challenging to outline the specific issue. However, let’s quickly check the .git folder just in case there is an obvious problem like missing files:
ls .git
branches config FETCH_HEAD hooks info objects refs
COMMIT_EDITMSG description HEAD index logs ORIG_HEAD
Luckily, there is an application that may be able to fix the broken Git repository automatically. The app is called git-repair, and this valuable tool can help with a wide range of issues.
First, we should check whether the tool is already installed on your machine. We can do this by trying to invoke it with the git-repair –help command. If the app is there, you should notice the help text displayed.
On Linux, this tool is often available via a package manager such as apt. Here is the command you can use to check if that’s the case:
sudo apt-get update
sudo apt-get install git-repair
If you don’t already have the tool installed on your machine, simply follow the installation guidelines on their homepage. Let’s run the tool and see what we get:
git-repair
Running git fsck …
No problems found
Although the tool reported no problems, that doesn’t mean that our actions were in vain. To confirm that something actually changed, let’s run git fsck once again and hope that the fatal: not a git repository error won’t appear:
git fsck
Checking object directories: 100% (256/256), done.
notice: HEAD points to an unborn branch (master)
As you can see, the situation looks much better now. From what we can see, it seems that HEAD (a file with one line of text that indicates which branch we are currently working on) is pointing to the wrong place. That’s a minor problem, and it is not too difficult to fix. Now, let’s switch to the master branch and see what happens:
git switch master
error: The following untracked working tree files would be overwritten by checkout:
README.md
index.html
styles.css
Please move or remove them before you switch branches.
Aborting
Git warns us that we will lose our work unless we move or remove the listed files. Let’s remove them and switch back to the master branch.
rm README.md
rm index.html
rm styles.css
git switch master
Switched to branch ‘master’
Your branch is up to date with ‘origin/master’.
ls
backup git-repair index.html README.md styles.css
We’ve managed to recover the repository, and you can now copy the files back. Since the files were restored from the local repository, they are up to date. However, they don’t feature some changes that haven’t been checked in yet.
Final thoughts
In this article, we’ve covered multiple scenarios along with ways to resolve the fatal: not a git repository error. Git is an outstanding version control system. Aside from the fact that it truly shines in project collaboration, you can also use it for your own projects as you experiment with new branches while preserving the work on others or simply reverting files to their previous state. The options are virtually limitless for those who manage to understand its structure and master the control line.
If you are interested in Git’s inner mechanisms, whether to code a business app or arm your company with custom-coded websites, feel free to schedule a call with our dev-ops team.
