Git tracks changes through a three-area workflow (working directory, staging area, repository), with branching strategies like trunk-based development and Gitflow providing structure for team collaboration and release management.
Files move from working directory to staging area (git add) to repository (git commit), giving precise control over what each commit contains.
Merge preserves branching history with a merge commit; rebase creates linear history by replaying commits. Never rebase commits that have been pushed to shared branches.
Trunk-based development uses short-lived branches with feature flags; Gitflow uses long-lived branches for scheduled releases; GitHub Flow is a pragmatic middle ground.
git reflog tracks all HEAD movements, enabling recovery from almost any mistake — deleted branches and reset commits remain accessible for 30 days.
Git is the universal version control system for software development. Every developer is expected to be proficient with Git, and interviewers test both conceptual understanding (how Git stores data, what a merge vs rebase does) and practical skills (resolving conflicts, recovering from mistakes, choosing branching strategies).
Git manages files across three areas: the working directory (your actual files on disk), the staging area (also called the index — files marked for the next commit), and the repository (the committed history stored in .git/). The workflow is: edit files in the working directory, git add specific changes to the staging area, then git commit to save a snapshot to the repository. This three-step process gives you precise control over what goes into each commit — you can stage part of a file's changes while leaving others unstaged.
A commit is a snapshot of every tracked file at a point in time, identified by a SHA-1 hash. Each commit points to its parent commit(s), forming a directed acyclic graph. git log shows the commit history. git diff shows changes between commits, between branches, or between the working directory and staging area. git blame shows who last modified each line of a file.
Branches are lightweight pointers to commits. Creating a branch (git branch feature) simply creates a new pointer — it does not copy files. git checkout (or git switch) moves the HEAD pointer to a different branch. This makes branching nearly instantaneous in Git, encouraging frequent branching for features, experiments, and fixes.
git merge combines two branches by creating a merge commit with two parents, preserving the complete branching history. git rebase replays commits from one branch onto another, creating a linear history. Merge is safer (no history rewriting) and preserves context. Rebase produces a cleaner history but rewrites commit hashes — never rebase commits that have been pushed to a shared branch. This merge-vs-rebase choice is one of the most common interview discussions.
Trunk-based development has everyone committing to a single main branch (or very short-lived feature branches). It relies on feature flags, comprehensive CI, and frequent small merges. This is the strategy used by most high-performing teams and is required for continuous deployment. Gitflow uses long-lived develop and release branches with feature branches merging into develop. It provides more ceremony and is suited for projects with scheduled releases. GitHub Flow is a simplified middle ground: feature branches off main, pull requests for review, merge to main after approval.
git stash temporarily saves uncommitted changes. git reset --soft HEAD~1 undoes the last commit but keeps changes staged. git reset --mixed HEAD~1 undoes the last commit and unstages changes. git reflog shows the history of HEAD movements, letting you recover from almost any mistake — even deleted branches and reset commits are recoverable for 30 days via reflog.
Pull requests (GitHub) or merge requests (GitLab) are the standard code review mechanism. They show the diff between branches, allow inline comments, run CI checks, and require approvals before merging. Effective PR practices include: small, focused changes (under 400 lines), descriptive titles and descriptions, and linking to relevant issues.
git merge preserves history and creates a merge commit. git rebase rewrites history for a linear timeline. Use merge for shared branches (never rewrite shared history). Use rebase for local feature branches before merging (to clean up commits). Understanding when each is appropriate demonstrates Git maturity.
Fun Fact
Linus Torvalds created Git in just 10 days in April 2005 after the Linux kernel's previous version control system (BitKeeper) revoked its free license. He named it 'Git' — British slang for an unpleasant person — saying 'I name all my projects after myself.'