Common Git Errors, How to Fix, and 5 Ways to Avoid Them

What are Git Errors?

Git is a free and open source version control system, provided under the GNU GPL version 2 license. It is commonly used for version control of source code, configuration management, and content management. Git is also the basis for a new development work model known as GitOps.

Because Git is a foundation of modern development processes and is extensively used by so many development teams, it can also be a single point of failure. If developers experience an error when trying to connect to a Git repository, committing their work to a Git repository, or when trying to perform day to day operations such as merging, this can seriously disrupt the DevOps pipeline.

We’ll cover some of the most common Git errors and how to resolve them, and also provide best practices that can help you streamline your use of Git, prevent issues and improve productivity.

This is part of an extensive series of guides about Observability.

Common Git Errors and How to Fix Them

‘fatal: refusing to merge unrelated histories’

This error occurs when a developer attempts to combine two unrelated projects into a single branch. This issue occurs when the branch contains inconsistent commit histories and tags with the pull request and clone.

There are two approaches to fixing the fatal: refusing to merge unrelated histories errors.

First Approach:

The first method to fix this issue is using the following git flag: –allow-unrelated-histories.

To accomplish this, you can use the git command: git pull origin master --allow-unrelated-histories .

Using a remote repository, you can replace the origin with its name. You could also substitute the master branch with any other branch you wish the pull request to integrate. The purpose of —-allow-unrelated-histories is to enable the merging of unrelated branches. This git flag operates flawlessly in the absence of file conflicts. However, at least one issue arises, and you must use the standard Git resolution method to fix this issue.

Second Approach:

The second method to fix this issue is using the following steps: 

1. First, unstage your existing commits.
2. Then, stash them.
3. Clone your relevant remote repository, and afterward, place the contents of your stashed branch in the new clone.

This will ensure that any potential code conflicts are resolved before the merge and prevent application errors from arising. 

The git command: git reset HEAD~ will remove all files from staging from your last commit. Using the git command git stash, you can store your unsaved files.

It will provide a clean working tree into which you may pull your remote repository. After successfully pulling into your branch, one may unstash the files, commit them individually as a separate commit, and fix the file conflicts. Use the git pop command to unstash the files. It will reapply the changes you have stashed to the current working copy. Learn more in our detailed guide to fatal refusing to merge unrelated histories.

‘fatal: remote origin already exists’

It happens when you attempt to change the repository’s origin URL after cloning it from GitHub or another remote repository to your local workstation.

When using Kubernetes, the issue could occur if you try incorporating Git repositories into an orchestration. In the majority of development environments, the default handler is the origin. Here are three solutions to this issue.

First Approach:

To fix this issue is to remove the existing remote. remote denotes the repository that is hosted. origin indicates the location of the remote. In most cases, the origin is the only pointer to a local repository. If users intend to modify the referring URL associated with the origin, one can eliminate the existing origin and re-add it with the new URL. Use the remove command on the remote, then enter the handler’s name (in this case, origin) to eliminate the handler.

First Approach:

We can fix this issue by updating the existing URL of remote. It is not always necessary to eliminate the origin handler from the remote. An efficient approach to fix this error is to modify the pointing URL of the handler. You may accomplish this by running the set-url command, then following it up with the handler name (In our case, origin), and lastly, the new URL.

Second Approach:

We can fix this issue by renaming the existing remote. Alternatively, one could rename the origin to a different name. It indicates that rather than removing the handler’s pointing URL to create a place for the new one, one can rename it while retaining the original data. To accomplish this, run the rename command with the remote. Learn more in our detailed guide to fatal remote origin already exists.

‘ssl certificate problem unable to get local issuer certificate’

It is a common git error encountered by users when attempting to push, pull, or clone a git repository with Git Bash, a Windows-specific command-line tool. Alternatively, one could rename the origin to a different name. It indicates that rather than removing the handler’s pointing URL to create a place for the new one, one can rename it while retaining the original data. To accomplish this, run the rename command with the remote. When the SSL certificate used by the Git server is self-signed, users encounter an error that indicates: unable to get local issuer certificate. This is because the private key linked to it is a security flaw that cannot be revoked. When a self-signed certificate creates an SSL certificate error,  add it to the trusted certificate store to fix it.

Git Bash’s default location for the trusted certificate store is as follows:

C:Program FilesGitmingw64sslcerts

Open ca-bundle.crt in the directory above and add the Git SSL certificate. Once accomplished, save the file and execute the following commands: git pull, push, or clone. For security considerations, it is not advised to disable SSL certificate validation. However, it is a possible solution to this issue.

The following command disables SSL certificate validation in Git locally:

$ git -c http.sslVerify=false clone [URL]

Reinstall Git using the SSL transport backend setting to fix this error. Learn more in our detailed guide to ssl certificate problem unable to get local issuer certificate.

‘failed to push some refs to’

It occurs when a developer pushes code to an external git repository. The pushing code suddenly stopped working. This error occurs when modifications aren’t committed before pushing, there are Git pre-push hook difficulties, or the branch name is incorrect. It occurs when multiple people update the same branch at once, and the remote repository has more recent changes than your local machine.

Here are the causes and solutions for the failed to push some refs error:

Another developer pushed a commit to the same branch

The terminal error appears as follows:

To [email protected]:sometest.git
! [rejected] your-branch -] your-branch (non-fast-forward)

Git can’t manage this because the head is on the same code timeline at multiple points. As a result, the origin repository is more recent than your current working copy. To fix, git pull your local repository. Then, it should restore the origin push.

git pull origin [your-branch]
git push origin [your-branch]

You got a ‘master (non-fast-forward)’ error with a ‘failed to push some refs to’ error

A git fast-forward occurs when the commit history ref pointer is advanced. If your code deviates before the newest commit, you’ll be unable to push certain refs to error. --rebase flag can fix this issue. --rebase moves commit files to the newest pull code.

The following describes how to pull using --rebase:

git pull --rebase origin [branch]

You got a ‘master (fetch first)’ error with a ‘failed to push some refs to’ error

When it happens, someone has already pushed to the branch. Git requires a pull before a push your modification. stash local modifications to prevent losing work during the pull. To push local modifications, use —-force to fix this issue. However, using —-force can produce inconsistencies. Use —-rebase to update your local repository without creating a divergence in the remote repository.

Using —-force to fix this error can cause more problems. It is because —-force employs brute force to make your present code and ref head the truth source.  As a result, your push can overwrite the remote’s changes, deleting any features or improvements other developers may have added. Use —-force if you’re comfortable with local features being overwritten. Use —-force if your local repository is correct. Learn more in our detailed guide to failed to push some refs to.

‘fatal: not a git repository’

All of Git’s commands are meant to be run in conjunction with a repository. Git won’t know what to push if you do git push -u origin master without a repository. This error means you ran a repository-specific command outside of Git. Despite being a prevalent issue, it’s easy to fix. This issue means you’re not in a git repository. There are two possible causes:

1. You attempted to execute the command without navigating to the project folder containing the git repository.
2. You are in the project folder but have not initialized the Git repository for that location.

Recheck the folder from which you are attempting to execute the command to resolve the first issue. Then, use the cd command to browse the correct directory if you need to be in the right directory. In the second issue, the user must initialize the Git repository in the project folder. To do this, navigate to the relevant folder and run git init to create a new or re-initialize Git repository.

‘fatal: repository not found’

Repository Not Found occurs while cloning or pushing modifications to a repository. The error may indicate that the repository doesn’t exist or was removed. The repository exists, but an access-related difficulty or remote origin difficulty causes this error.

You did not authenticate

If you try to access a private GitHub or BitBucket repository without authenticating, you’ll get a repository not found error. So, log in to the repository with your credentials in the Git URL to authenticate:

git clone https://mcnz:[email protected]/cameronmcnz/private-github-repo.git

You are not a collaborator

Even if you can authenticate against GitHub or GitLab, you will still receive this error if you are not a collaborator on the project. Get in touch with a GitHub or BitBucket repository admin and ask to be added as a contributor.

Incorrect case or a word misspelled

The repository name could be case-sensitive if the managing source code tool is on Linux. Watch out for inventive repository spellings like 0 for O or 1 for L. Copy and paste the git clone code from the documentation if you can.

Tips from the expert

Itiel Shwartz

Co-Founder & CTO

Itiel is the CTO and co-founder of Komodor. He’s a big believer in dev empowerment and moving fast, has worked at eBay, Forter and Rookout (as the founding engineer). Itiel is a backend and infra developer turned “DevOps”, an avid public speaker that loves talking about things such as cloud infrastructure, Kubernetes, Python, observability, and R&D culture.

In my experience, here are tips that can help you better troubleshoot and avoid common Git errors:

Regularly prune and clean your repository

Use git gc and git prune regularly to clean up unnecessary files and optimize your repository. This helps maintain performance and prevents errors related to repository size and complexity.

Create and use Git aliases

Simplify complex Git commands by creating aliases in your .gitconfig file. For example, alias git checkout to co or git commit --amend to amend for quicker and more efficient workflows.

Implement Git hooks for consistency

Use Git hooks to enforce coding standards, run tests, and ensure commit messages follow a specific format. Pre-commit hooks can prevent common mistakes before they are committed to the repository.

Use branch protection rules

Set up branch protection rules in your Git repository to enforce workflows, such as requiring pull request reviews, passing status checks, and preventing force pushes. This helps maintain code quality and prevents errors in critical branches.

Leverage Git rebase for cleaner history

When working with feature branches, use git rebase instead of git merge to maintain a linear commit history. This makes it easier to understand the project’s progression and identify where changes were made.

5 Git Coding and Troubleshooting Best Practices

Use these best practices to prevent issues in Git workflows, and to enable easy troubleshooting when they happen.

1. Discard Local File Modifications

Working with the code can be the greatest way to understand a problem. However, sometimes, the changes done throughout the procedure could be better, so returning the file to its previous state is the fastest and easiest approach:

The double dash (–) indicates the end of command line parameters.

Edit a Commit Message

In commit messages, typos are trivial to repair:

However, git-amend has more capabilities. For example, have you forgotten to upload a file? Add it and update the commit:

--amend creates a new commit that replaces the prior one; therefore, don’t use it to change commits in a central repository. If no other developer has checked out the prior version or built their work upon that, a forced push (git push --force) could be acceptable. However, since the tree’s history was locally updated, the remote server will refuse the push because no fast-forward merging is permitted.

2. Clean Up Local Commits Before Pushing

--amend is useful, but it won’t help if the commit users want to rewrite isn’t the last. In this scenario, an interactive rebase is beneficial:

This opens your configured editor’s menu:

You’ll find local commits and accessible commands. For example, modify pick to reword (or r) to alter the commit message. Interactive rebase offers much more than commit message editing. You can delete commits from the list, modify, reorganize, and squash them. Squashing allows you to merge many contributions into one. 

3. Reverting Pushed Commits

Despite the prior suggestions, incorrect commits may get into the central repository. Git makes it easy to roll back single or multiple commits.

Use —-no-commit/-n to avoid creating additional revert commits and apply the essential modification to the working tree.

4. Avoid Repeated Merge Conflicts

Addressing merge conflicts can be difficult, but addressing the same issue repeatedly (e.g., in long-running feature branches) is frustrating. If you’ve experienced this, you’ll like the reuse recorded resolution feature. Add it to the global config for all projects:

Per-project enabling is possible by manually creating .git/rr-cache.

For those that require it, this function can save time. Imagine working on multiple feature branches at once. Now merge them into a testable pre-release branch. You resolve multiple merge conflicts. A reversal of the merge is made since it becomes clear that one of the branches still needs to be completed. When the branch is ready, combine it using the recorded resolutions feature.

5. Avoid Common Mistakes With Git Hooks

Some mistakes are repeated but can be avoided by executing checks or cleanup actions at a specific git workflow stage. It is precisely the case for which hooks were intended. First, add an exe file to .git/hooks to establish a hook. The script’s name must match any hooks listed in the documentation (man githooks). Next, create a template directory for git to employ when creating a new repository to define global hooks. This is how ~/.gitconfig and a template directory look:

When you establish a new repository, template directory files are copied to your project’s .git directory.

This slightly fabricated example commit-msg hook will assure that each commit message has a ticket number, such as “#123,” as an identifier.

Related content: Read our guide to Git revert

See Additional Guides on Key Observability Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of observability.

Exit Codes

Authored by Komodor

• How to Fix OOMKilled Kubernetes Error (Exit Code 137)
• Exit Codes in Containers & Kubernetes | Complete Guide | Komodor
• How to Fix OOMKilled Kubernetes Error (Exit Code 137)

Distributed Tracing

Authored by Lumigo

• What is Distributed Tracing?
• Distributed Tracing in Microservices: Basics & 4 Tools to Know
• Distributed Tracing Tools

serverless monitoring

Authored by Lumigo

• Serverless Monitoring Guide 
• Serverless Deployments: 5 Deployment Strategies & Best Practices
• Serverless vs. Microservices: 4 Differences & Potential Synergies