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.