In this article
Before you start
This page belongs to the DevOps and cloud learning path. Git is used from a terminal.
Why interviewers ask this
Version control sits under every build, test and deployment step, so an interviewer for a DevOps, cloud or software role expects you to explain it without notes. The question is cheap to ask and quick to grade. It separates people who type git push from habit from people who know what the command moves.
A weak answer says "Git saves versions of code and lets you work with others." A strong answer says what a commit contains, why a branch costs almost nothing, and what a merge produces. A Staff-level answer adds the trade-offs: when to merge and when to rebase, why large binary files hurt, and why a distributed design still has one agreed shared copy in most teams. Pro Git, the free book maintained on git-scm.com, is the reference these ideas come from.
Version control systems from first principles
- Merge
- A merge is an operation that joins two lines of history; when both lines have new commits Git records a merge commit with two parents, and when only one has moved Git fast-forwards the branch pointer.
- Repository
- A repository is the stored history of a project: every commit, every branch pointer and the files they record, kept in a hidden folder next to the working files.
In plain words
Imagine writing a long report. After each good session you photograph the whole desk and write a date on the back. You can lay any photograph out again. That is a version control system.
The analogy breaks in one place. Photographs do not combine, but a VCS can merge two sets of edits into one.
In one precise sentence, a version control system stores each saved state of a project with a link to its predecessor, so any state can be recovered and separate lines of work can later be joined.
What are the types of version control systems?
The three types of version control systems are local, centralized and distributed. Teams use any of them for the same reasons: a history of changes, recovery of earlier states and a way to collaborate. Pro Git describes each type. A local system keeps its history on one machine; its example is the Revision Control System (RCS).
A centralized system keeps history on one server that clients ask for files; its examples are the Concurrent Versions System (CVS), Subversion and Perforce. A distributed system gives every user a full copy of the history; its examples are Git, Mercurial and Darcs. The central server of a centralized system is a single point of failure, while in a distributed system every clone is a full backup.
Step 1: A commit saves a snapshot of every file
A commit is a snapshot. Many older tools stored a list of changes per file, called deltas. Pro Git explains that Git thinks of its data as a series of snapshots of a miniature file system, and that a file that did not change is stored as a link to the earlier identical file, not copied again. That is Git's logical model. On disk, Git compresses its objects, and when it packs them (git gc and pushes do this) it stores similar objects as deltas, as Pro Git on packfiles explains, so real repositories are far smaller than the snapshot figures in the worked example.
Work moves through three states: modified (you edited a file), staged (you marked the change for the next commit) and committed (the snapshot is saved). Each commit gets a name from a checksum, a fingerprint computed from its content. Pro Git says the checksum is a 40-character hexadecimal string computed with a Secure Hash Algorithm (SHA) function called SHA-1, so a name changes whenever the content does. Change one character anywhere and the name changes, so damage is detectable.
Input: your edited files. Output: one new snapshot, linked to its parent. You now know why history is hard to alter by accident: each commit's name depends on everything before it.
Step 2: A branch is a pointer to a commit
A branch is a pointer, not a folder of copies. Pro Git's branching chapter describes a branch as a lightweight movable pointer to a commit, and a special pointer called HEAD that records which branch you are on.
Creating a branch therefore writes one tiny pointer. In the worked example below, branching copies zero files.1 When you commit while on a branch, Git creates the new commit and moves only that branch's pointer to it. The other branches stay where they were.
That is why teams branch for every feature or fix: the cost is near zero and the work stays separate until it is ready. Input: a commit to start from and a name. Output: a second pointer to the same commit.
Step 3: A merge joins two histories
A merge combines two lines of work. Suppose main moved on while a feature branch also gained commits. Git finds the last commit both share, compares each side's changes against it and, if the edits touch different lines, joins them in a merge commit. That commit has two parents, so the history records that the lines met. If the branch you merge into has not moved at all, Git simply moves the pointer forward; this is called a fast-forward, and no merge commit is created (Pro Git).
If both sides changed the same lines, Git cannot choose. It marks the file as a conflict and waits for a person to pick the result, then to commit. The Subversion book calls this approach copy-modify-merge: each user works on a private copy and the changes are merged. It contrasts it with a lock-based model, where a user locks a file before editing so only one person can edit it at a time. For the wider toolchain, see Git DevOps interview questions and the main git commands.
Input: two branch tips. Output: one merge commit, or a conflict for a human to settle.
Step 4: A remote shares the history
A remote is another copy of the repository, usually on a server, that you push commits to and pull commits from. Because Git is distributed, your clone already holds the complete history, so most operations work without a network connection. Only sharing needs the network.
In a centralized system, by contrast, the history lives on one server, and the server is a single point of failure. A distributed design removes that dependency, though teams often still name one remote as the shared reference, because people need an agreed place to publish. "Distributed" does not mean "no shared server."
You now have the whole model: snapshots, pointers, joins and copies.
Step-by-step description
- A commit saves a snapshot.
- A branch points at a commit.
- A merge joins two histories.
- A remote shares the history.
- A commit saves a snapshot of the working copy.
- A branch is a pointer to a commit.
- A merge commit joins two lines of history.
- A remote is another copy of the repository.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
A toy project makes the storage claim countable. It has five files of 40, 30, 50, 5 and 25 kilobytes, so 150 kilobytes in total (illustrative sizes).1 Three commits follow: the first saves everything, the second edits one file (it grows by 2 kilobytes) and the third edits another (also 2 kilobytes).1
Saving a full copy of every file at every commit takes 456 kilobytes (150, then 152, then 154).1 A Git-style snapshot that links unchanged files stores seven file versions and takes 244 kilobytes. A pure delta store keeps the first snapshot plus the two small changes: 154 kilobytes.1 These figures show the logical model before packing. In that model snapshots are larger than deltas, and the cost buys speed and simplicity: any commit is a complete tree that needs no replay of earlier changes. Real repositories are smaller than the snapshot column, because packing stores similar objects as deltas.
The commit graph is also counted. Three commits sit on main. A branch is cut from the second commit and copies zero files. The branch gets two commits, then merges back. The merge commit has two parents, and the graph holds six commits, all reachable from main.1 A toy content fingerprint (not SHA-1) gives identical text the same id and different text a different id.1
| Quantity | Value (illustrative project) |
|---|---|
| Project size at the first commit | 150 kilobytes |
| Full copy of every file at every commit | 456 kilobytes |
| Snapshots with unchanged files shared | 244 kilobytes |
| Deltas only | 154 kilobytes |
| File versions stored in the snapshot model | 7 |
| Files copied when the branch is created | 0 |
| Commits after the merge | 6 |
| Parents of the merge commit | 2 |
Text description of the diagram
- Full copies of every file at every commit take 456 kilobytes.
- Snapshots that share unchanged files take 244 kilobytes.
- A pure delta store takes 154 kilobytes.
Trade-offs and edge cases
Git's snapshot model keeps every commit a complete tree, and the model has edges. A large binary file such as a video or a compiled library has no useful line-by-line difference, so delta packing helps little and the history grows with each edit. Teams often keep such files outside the repository for that reason.
A second trade-off is how to bring branches together. Merging keeps the true history and adds a merge commit. Rebasing replays your commits on top of another branch, which gives a straight line but creates new commits with new names. Because the names change, rebasing commits others already pulled forces them to repair their copies. A safe habit is to rebase only commits that exist on your machine.
A third is centralized against distributed design, shown below.
Text description of the diagram
- Local systems keep history on one machine.
- Centralized systems keep history on one server.
- Distributed systems keep a full history in every clone.
Two edge cases to name: a conflict needs a human decision, and a tool cannot tell which of two edits to the same line is correct. Git also records the history of the content you give it, so a secret committed once stays in older commits even after you delete the file; removing it means rewriting history. Hashing has a 2025-26 footnote too: Git can create repositories that use SHA-256 as the object hash, introduced in Git 2.29 (2020), as the planned successor to SHA-1 naming. Connect this to build automation such as Jenkins, which starts from a commit.
How to answer it in an interview
What is version control, and how does Git work?
A version control system records every change to a project as a commit, a saved snapshot with an author, a message and a link to its parent, so I can see history and return to any earlier state. Git is distributed: every clone holds the full history, so most work needs no network. A branch is only a movable pointer to a commit, so creating one copies no files, and a merge joins two histories, as a merge commit with two parents when both sides moved. The trade-off is that edits to the same lines still need a person to resolve.
The spoken structure: define the commit, say what distributed means, explain that a branch is a pointer, then name the merge and its conflict limit.
Common mistakes
- "Each commit stores a diff from its parent." (wrong) Git's model is a snapshot per commit, with unchanged files linked. (right) "Each commit records a full snapshot; storage is compressed and packed with deltas underneath."
- "A branch copies all the files." (wrong) A branch is a pointer to a commit. (right) "Creating a branch writes one pointer; commits move it."
- "Git and GitHub are the same thing." (wrong) Git is the version control software; a hosting service stores a remote copy. (right) "Git is the tool; a hosting service holds a shared remote."
- "Distributed means there is no central server." (wrong) Teams usually still agree on one shared remote. (right) "Every clone has full history, and the team still names one remote as the reference."
Follow-up questions
What is the difference between Git and GitHub?
Git is the version control software that runs on your machine and stores the history. GitHub is a hosting service that keeps a remote copy of a Git repository and adds collaboration features around it.
What is the difference between centralized and distributed version control?
A centralized system keeps the history on one server and clients ask it for files; a distributed system gives every clone the full history. The distributed design works without a network for most operations and has no single point of failure.
What is the difference between merge and rebase?
A merge joins two histories, usually with a merge commit that has two parents, and keeps the record of what happened. A rebase replays commits on a new base, giving a straight history but new commit names, so it is kept for unshared commits.
What is a merge conflict and how do you resolve it?
A conflict appears when both sides changed the same lines and Git cannot choose. You open the marked file, pick or combine the changes, stage the file and commit.
How does Git know that a file has changed?
git status first compares the file metadata cached in the index (size and modification time) with the working file, and hashes the content only where they differ. Because Git names content by a checksum, a different checksum means different content. Each commit's name also depends on its parent's, so damage anywhere in the history breaks the chain of checksums and is detectable.
Why does a build server need version control?
A build server needs a fixed, named input: it checks out a specific commit, builds it and reports the result for that commit. The Kubernetes interview questions assume the same pipeline, with images built from committed code.
- A version control system stores each saved state of a project with a link to its predecessor.
- A Git commit records a full snapshot with shared unchanged files; storage is compressed and packed with deltas underneath.
- A branch is a movable pointer, so branching copies no files.
- A merge makes a merge commit (two parents) when both sides moved and a fast-forward otherwise; edits to the same lines need a human.
- Distributed means every clone holds full history, not that no shared remote exists.
Sources
- Pro Git: Getting Started, About Version Control — git-scm.com (Chacon and Straub), accessed 2026-10-26, 26 Oct 2026
- Pro Git: Getting Started, What is Git? — git-scm.com (Chacon and Straub), accessed 2026-10-26, 26 Oct 2026
- Pro Git: Git Branching, Branches in a Nutshell — git-scm.com (Chacon and Straub), accessed 2026-10-26, 26 Oct 2026
- Version Control with Subversion: Version Control Basics — Red Bean (Subversion book), accessed 2026-10-26, 26 Oct 2026
- Pro Git: Git Branching, Basic Branching and Merging — git-scm.com (Chacon and Straub), accessed 2026-10-26, 26 Oct 2026
- Pro Git: Git Internals, Packfiles — git-scm.com (Chacon and Straub), accessed 2026-10-26, 26 Oct 2026
- Pro Git: Git Tools, Rewriting History — git-scm.com (Chacon and Straub), accessed 2026-10-26, 26 Oct 2026
- Git documentation: hash-function-transition — git-scm.com documentation, accessed 2026-10-26, 26 Oct 2026
