Troubleshooting of GIT

Troubleshooting of GIT

Restoring deleted files in Git

Restoring deleted files in Git

SSH Authentication Failed: Permission denied (publickey)

Error Message

After keyin the command

git clone [email protected]:your-org/your-repo.git /opt/your-app

, met the error message

Cloning into '/opt/your-app'...
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Cause

This error occurs when Git cannot authenticate with GitHub over SSH. This typically means the SSH key on your machine is either missing, not registered with your GitHub account, or not being picked up by the SSH agent.

Solutions

Option 1 — Configure your SSH config file

Add an entry to `~/.ssh/config` so Git automatically uses the correct key:

Host github.com
  HostName github.com
  User git
  IdentityFile /path/to/.ssh/your_key_name

Option 2 — Pass the SSH key inline

1. Before running `git clone`, test whether the specified SSH key can successfully authenticate with GitHub:

ssh -T -i /path/to/.ssh/your_key_name [email protected]

If the key is configured correctly, you should see:

Hi your-org/your-app! You've successfully authenticated, but GitHub does not provide shell access.

`successfully authenticated` confirms the key is correctly linked to your GitHub account and you're good to proceed with `git clone`. The message `GitHub does not provide shell access` is expected — SSH is used for Git operations only, not for interactive shell login.

2. Override the SSH command directly when cloning:

sudo GIT_SSH_COMMAND='ssh -i /path/to/.ssh/your_key_name -o IdentitiesOnly=yes' \
  git clone [email protected]:your-org/your-repo.git /opt/your-app

Notice: `-o IdentitiesOnly=yes` prevents SSH from trying other keys loaded in the agent, which can cause unexpected auth failures.

Git Submodule Pull Failed: unable to create file — File exists

Error Message

After pulling in GitHub Desktop, met the error message

Fetching submodule lib
error: unable to create file feeds/example.php: File exists
Updating xxxxxxxx..xxxxxxxx

Cause

When Git tries to update the submodule to a newer commit, it finds a local untracked file with the same name, blocking the checkout. A mid-pull failure leaves the submodule in an inconsistent state and causes a large number of unexpected unstaged changes to appear in GitHub Desktop.

Solution

Run the following command in the project root directory to force re-sync the submodule:

git submodule update --init --recursive --force

If it still fails, manually remove the conflicting file and retry:

rm lib/feeds/example.php
git submodule update --init --recursive

Enter the submodule directory and verify the status is clean:

cd lib
git status

The expected output should be:

HEAD detached from xxxxxxxx
nothing to commit, working tree clean

`nothing to commit, working tree clean` confirms the submodule has been successfully synced — return to GitHub Desktop and continue as normal. `HEAD detached` is the expected state for a submodule and does not require any action.

Notice: The large number of unstaged changes appearing in GitHub Desktop after a failed Pull will typically return to normal once the submodule is fixed. If unexpected changes still remain, run git submodule foreach git checkout . to revert all modifications inside every submodule.

Further Reading

• Generating a new SSH key and adding it to the ssh-agent - GitHub Docs
• Adding a new SSH key to your GitHub account - GitHub Docs
• Testing your SSH connection - GitHub Docs
• ssh_config(5): OpenSSH SSH client config files - Linux man page
• Troubleshooting SSH - GitHub Docs