This page needs a newer browser to run its tools. You can still read everything here.

GitHub and remotes interview questions

Interview questions on gitHub and remotes: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.

12 questions: 4 warm-ups and 8 with model answers · Levels: Fresher to senior

Warm-up questions

Short questions with short answers, each answered in full.

Fresher

Why should you check a host key fingerprint before answering "yes" to a first SSH connection to GitHub?

Answered in the lesson Set up GitHub: account, 2FA and SSH keys
Fresher

What is the difference between main and origin/main in your clone?

Answered in the lesson Remotes and cloning: origin and tracking branches
Fresher

What is the difference between git fetch and git pull?

Answered in the lesson Sync work with fetch, pull and push
Fresher

How is a fork different from a clone?

Answered in the lesson Forks: contribute where you cannot push

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Fresher to mid

A teammate pasted a fine-grained personal access token with write access to your team's main repository into a busy team chat ten minutes ago. Walk through what you do in the next fifteen minutes, in order, and what you change so that it cannot happen again.
What it tests

The order of an incident response for an exposed credential (revoke before cleaning up), checking for misuse, a least-privilege replacement, and removing the habit that caused the leak.

First step

Revoke the token before anything else. The message has been readable for ten minutes, so assume someone has copied it; deleting the message first only hides it from you. Then work out what the token was allowed to do and what it was used for since the leak.
Follow-ups
- How do you check whether anyone used the token?
- The same token also runs a nightly job. How do you replace it without breaking the job for long?
- What would you change so that people stop handling tokens by hand?
From the lesson Set up GitHub: account, 2FA and SSH keys
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to mid

On a college network, git push over SSH hangs for about a minute and then fails, while github.com opens normally in the browser. How do you confirm what is wrong, and how do you keep using your SSH key on that network?
What it tests

Telling a network block from a key problem, SSH over port 443 at ssh.github.com, host-key checks under a new name, and HTTPS with a credential helper as the fallback.

First step

Separate a network problem from a key problem. A key GitHub rejects fails within a second with Permission denied (publickey); a blocked port makes ssh wait for a TCP connection until it gives up. Run ssh -vT git@github.com and see whether the connection is ever established.
Follow-ups
- Why ssh.github.com, and not github.com, on port 443?
- ssh says the host key is known under another name. Is that safe to accept?
- SSH through port 443 is blocked as well. What now?
From the lesson Set up GitHub: account, 2FA and SSH keys
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to mid

git status says "Your branch is up to date with 'origin/main'", yet a teammate says they pushed to main an hour ago. Explain how both can be true, and how you check what is really on the server without changing any of your work.
What it tests

Remote-tracking branches as a cache that only fetch, pull and push update, git fetch against git ls-remote, and reading ahead and behind counts.

First step

git status compares main with refs/remotes/origin/main, a ref in your own repository that changes only when this repository talks to the remote. If nobody here has fetched since the teammate pushed, that copy is an hour old. git fetch updates only remote-tracking branches; run it, then git status again.
Follow-ups
- How would you check the server without even updating origin/main?
- After the fetch, git status says the branches have diverged. What do its two numbers count?
- Why can an editor show the teammate's commits before you have fetched?
From the lesson Remotes and cloning: origin and tracking branches
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to mid

You created a GitHub repository with a README and a licence, added it as origin to a project with forty local commits, and git push -u origin main was rejected. Explain the rejection, and compare two ways to fix it.
What it tests

Separate histories with no common commit, why a push must be a fast-forward, pull --rebase against a merge with --allow-unrelated-histories, and when a forced push would be acceptable.

First step

GitHub's main already has a commit, the one that added the README and the licence, and your main does not contain it, so moving the remote branch to your commit would drop it. Fetch it and look at both histories: git fetch origin, then git log --oneline --graph --all shows two separate first commits.
Follow-ups
- Which fix keeps the IDs of your forty commits unchanged?
- When would git push --force be acceptable here?
- Both sides have a README.md. What happens during the rebase?
From the lesson Remotes and cloning: origin and tracking branches
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to mid

Your git push to main is rejected as non-fast-forward, and a colleague suggests git push --force. Explain what the rejection protects, why the suggestion is wrong, and the safe sequence of commands, including what you check before you push again.
What it tests

The fast-forward rule, what a forced push throws away, the fetch, integrate, test and push sequence, choosing rebase or merge, and checking the result before pushing.

First step

The remote's main has commits that your main does not contain, so moving it to your commit would drop them, and --force does exactly that. Run git fetch, then git log --oneline --graph main origin/main to see both sides before you decide how to integrate.
Follow-ups
- Rebase or merge here, and why?
- The rebase stops with a conflict. What then?
- How do you confirm before pushing that none of their commits will be lost?
From the lesson Sync work with fetch, pull and push
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Explain what git push --force-with-lease protects against, describe a situation in which it still overwrites a colleague's commit, and say what --force-if-includes adds. Then give the commands you would use to update a rebased feature branch that a colleague also pushes to.
What it tests

How a lease compares the remote branch with your remote-tracking branch, how a background fetch renews it, the reflog check of --force-if-includes, and a safe update of a shared branch.

First step

A lease means: overwrite the remote branch only if it still points where my origin/<branch> says it does. The weak point is that origin/<branch> can move without you looking at it, for example when an editor runs git fetch every few minutes.
Follow-ups
- What does the explicit form --force-with-lease=<ref>:<expect> change?
- How does Git decide that you have integrated the remote tip?
- When is a forced push to a shared branch acceptable at all?
From the lesson Sync work with fetch, pull and push
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to mid

A contributor's fork has two commits on main that upstream does not have, every sync now makes a merge commit, and their open pull request shows those commits too. How did this happen, and how do you repair the fork without losing the two commits?
What it tests

Why commits on a fork's main break fast-forward syncs, moving the commits to a topic branch, resetting main to upstream/main, a safe forced push to the fork, and clean pull requests.

First step

The two commits went straight onto the fork's main, so main and upstream/main have diverged: every plain merge from upstream adds a merge commit, and a pull request opened from main carries everything on it. First put the two commits somewhere safe with git branch keep-work main.
Follow-ups
- Why is a forced push acceptable on the fork's main but not on upstream's?
- How do you make the open pull request contain only its own commits?
- Which settings and habits stop this from happening again?
From the lesson Forks: contribute where you cannot push
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Set up a contributor's clone so that a plain git pull on main reads from the original project and a plain git push writes to their fork. Name the settings, show how you would verify them, and describe one way this setup can surprise someone.
What it tests

remote.pushDefault and branch upstreams, push.default=simple in a triangular workflow, checking with --dry-run, and surprises such as new branches and @{push}.

First step

Two remotes and two settings. origin is the fork and upstream the original. git branch --set-upstream-to upstream/main makes pull read from the original, and git config remote.pushDefault origin sends every push without a push remote of its own to the fork.
Follow-ups
- What does git status compare main with after this?
- Where does the first push of a new topic branch go?
- When would you set branch.<name>.pushRemote instead?
From the lesson Forks: contribute where you cannot push
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

The lessons of this module

Set up GitHub: account, 2FA and SSH keys Free lesson, Pro answers: 20 minutes
Remotes and cloning: origin and tracking branches Free lesson, Pro answers: 20 minutes
Sync work with fetch, pull and push Free lesson, Pro answers: 20 minutes
Forks: contribute where you cannot push Free lesson, Pro answers: 15 minutes

All Git & GitHub interview questions · The Git & GitHub track

Warm-up questions

Why should you check a host key fingerprint before answering "yes" to a first SSH connection to GitHub?

What is the difference between main and origin/main in your clone?

What is the difference between git fetch and git pull?

How is a fork different from a clone?

Questions with model answers

A teammate pasted a fine-grained personal access token with write access to your team's main repository into a busy team chat ten minutes ago. Walk through what you do in the next fifteen minutes, in order, and what you change so that it cannot happen again.

On a college network, git push over SSH hangs for about a minute and then fails, while github.com opens normally in the browser. How do you confirm what is wrong, and how do you keep using your SSH key on that network?

git status says "Your branch is up to date with 'origin/main'", yet a teammate says they pushed to main an hour ago. Explain how both can be true, and how you check what is really on the server without changing any of your work.

You created a GitHub repository with a README and a licence, added it as origin to a project with forty local commits, and git push -u origin main was rejected. Explain the rejection, and compare two ways to fix it.

Your git push to main is rejected as non-fast-forward, and a colleague suggests git push --force. Explain what the rejection protects, why the suggestion is wrong, and the safe sequence of commands, including what you check before you push again.

Explain what git push --force-with-lease protects against, describe a situation in which it still overwrites a colleague's commit, and say what --force-if-includes adds. Then give the commands you would use to update a rebased feature branch that a colleague also pushes to.

A contributor's fork has two commits on main that upstream does not have, every sync now makes a merge commit, and their open pull request shows those commits too. How did this happen, and how do you repair the fork without losing the two commits?

Set up a contributor's clone so that a plain git pull on main reads from the original project and a plain git push writes to their fork. Name the settings, show how you would verify them, and describe one way this setup can surprise someone.