What is a commit in Git?

In Git, a commit is a snapshot of your project's files at a specific point in time, effectively saving your work and creating a record of changes, including who made the changes, when, and what they did.

1
Commits are created with the git commit command to capture the state of a project at that point in time.
2
Git Snapshots are always committed to the local repository, each developer’s local repository is a buffer between their contributions and the central repository.
3
Prior to the execution of git commit, the git add command is used to promote or 'stage' changes to the project that will be stored in a commit.

Difficulty: 2/10

Topics: commit creation, history navigation, rollback

Scenario Questions

0-2 years experience

1
If you need to add a new feature file and ensure it's tracked, walk me through the exact Git commands you'd use to create a commit.
2
What happens if you run git commit without staging any changes? How does Git respond?
3
Suppose you accidentally committed a typo in a comment. How would you amend that commit before pushing?

2-5 years experience

1
During a sprint you notice a bug was introduced in a recent commit. How would you identify which commit caused it using Git tools?
2
Your team uses feature branches and you need to integrate a commit from a teammate's branch without pulling the whole branch. What approach would you take?
3
Explain why a commit might be rejected by a CI pipeline and how you would resolve it.

5-8 years experience

1
In a large monorepo we have thousands of daily commits. How would you design a strategy to keep the commit history readable and support fast bisecting?
2
When rebasing a long-lived feature branch, you encounter merge conflicts in many commits. What steps do you take to preserve commit integrity and minimize disruption?
3
Discuss the trade‑offs between squashing commits before merging versus preserving each individual commit in a high‑traffic repository.

8+ years experience

1
Our organization is migrating from a centralized VCS to Git and wants to enforce a commit policy across dozens of teams. How would you design a system to enforce commit message standards, sign‑offs, and prevent large binary commits at scale?
2
Consider a scenario where multiple teams share a common library repository. How would you structure commit workflows and tooling to avoid commit‑level coupling and enable independent releases?
3
If you needed to retroactively rewrite commit history for compliance across many years, what process and tooling would you use, and how would you mitigate impact on downstream consumers?

Follow-up Questions

❓Can you describe a time you had to fix a bad commit after it was pushed?
❓What are the risks of amending a commit that others have already based work on?
❓When would you choose to squash commits versus keeping them separate?