51
What are the main modes of git reset?
git reset can move the current branch reference and optionally update the staging area and working tree. The three commonly discussed modes are --soft, --mixed, and --hard.
Git & GitHub Interview
Undo & Recovery, Tags, Forks, Pull Requests & Code Review
Git & GitHub interview questions 51-75: Undo & Recovery, Tags, Forks, Pull Requests & Code Review.
25 Questions Filter by level
Interview questions
Open a question for the full answer, code and interview guidance.
52
What is the difference between git reset --soft, --mixed, and --hard?
With --soft, the branch moves but the index and working tree remain unchanged, so the undone commit's changes stay staged. With --mixed, the branch and index are reset while the changes remain in the working tree.
53
What does git restore do?
git restore is designed to restore file content in the working tree or staging area. It separates file-restoration tasks from the older multi-purpose git checkout command.
54
What is the difference between git restore and git reset?
git restore primarily works with file content in the working tree and index. git reset can move the current branch reference and can also reset the index and working tree depending on its mode.
55
What is git revert and when should it be used?
git revert creates a new commit that reverses the changes introduced by an earlier commit. The original commit remains in history.
56
How do you amend the most recent Git commit?
git commit --amend replaces the most recent commit with a new commit. It can be used to include newly staged changes or correct the latest commit message.
57
What is git reflog?
git reflog records updates to local references such as HEAD and branch tips. It can help locate commits that appear to have been lost after operations such as reset, rebase, branch deletion, or checkout.
58
How can you recover a commit after an accidental git reset?
If the commit was recently reachable in the local repository, git reflog can often reveal its previous commit ID. After identifying the correct commit, create a branch pointing to it or reset the intended branch carefully.
59
What is git cherry-pick?
git cherry-pick applies the changes introduced by one or more existing commits onto the current branch and creates new commit identities there.
60
What happens if a cherry-pick has conflicts?
Git pauses the cherry-pick and marks conflicting files for manual resolution. The developer resolves the files, stages them, and runs git cherry-pick --continue.
61
What is a Git tag?
A Git tag is a named reference commonly used to mark an important point in repository history, such as a release version. Unlike a normal branch, a tag is generally intended to remain fixed rather than move as new commits are created.
62
What is the difference between lightweight and annotated tags?
A lightweight tag is essentially a simple name pointing to a commit. An annotated tag is a full Git object that can include a tagger, date, message, and optional cryptographic signature.
63
How do you push tags to a remote repository?
Normal branch pushes do not necessarily publish all local tags. A specific tag can be pushed by name, or multiple tags can be pushed with the appropriate option.
64
What is GitHub repository visibility?
GitHub repositories can have visibility settings that determine who can access them, subject to account and organization capabilities. Public repositories are broadly visible, while private repositories restrict access to authorized users or teams.
65
What is a fork on GitHub?
A fork is a repository created within GitHub's repository network from another repository. It allows a user or organization to develop changes independently while retaining a relationship to the original project.
66
What is the difference between cloning and forking a repository?
Cloning creates a local working copy of a repository on your computer. Forking creates another repository on GitHub that is associated with the source repository.
67
What is the upstream remote in a fork-based workflow?
In a fork workflow, origin commonly points to your fork while upstream commonly points to the original repository. The name upstream is a convention, just like origin.
68
How do you keep a GitHub fork up to date with the original repository?
A common local workflow is to fetch the upstream remote, switch to the corresponding local branch, and integrate upstream changes using the project's preferred merge or rebase policy. The updated branch can then be pushed to your fork.
69
What is a pull request on GitHub?
A pull request is a GitHub collaboration feature for proposing that changes from one branch be reviewed and integrated into another branch. It provides a place for discussion, code review, automated checks, and merge decisions.
70
What information should a good pull request contain?
A good pull request should explain what changed, why the change is needed, and any important implementation or testing details. It may link related issues, describe screenshots or migration steps, and call out known risks.
71
What is a draft pull request?
A draft pull request communicates that the proposed changes are not yet ready for final review or merge. It can still be used to share progress, run automated checks, and gather early feedback.
72
What is code review on GitHub?
Code review is the process of examining proposed changes, commonly through a pull request, before integration. Reviewers can inspect diffs, add comments, request changes, approve changes, and discuss design or implementation decisions.
73
What are pull request approvals and requested changes?
GitHub reviewers can submit review outcomes such as approval or a request for changes, depending on repository permissions and configuration. An approval indicates that the reviewer accepts the proposed changes from their review perspective.
74
What is the difference between merge commit, squash merge, and rebase merge on GitHub?
A merge commit preserves the branch's commits and creates a merge commit connecting the histories. Squash merging combines the pull request's changes into a single commit on the target branch.
75
What should you check before merging a pull request?
Confirm that the proposed change is correct, focused, reviewed, and compatible with the target branch. Required automated checks should pass, conflicts should be resolved, and any requested changes should be addressed.