Git Version Control

This deck walks you through the fundamentals of Git, the most widely used version control system in software development. You'll explore core concepts like repositories, the working directory, the staging area, and commits, as well as essential commands such as git init, git add, git commit, git status, and git log. The cards also cover branching and merging, including how to create branches, switch between them with git checkout, and understand what happens during a fast-forward merge.

It's a great fit if you're new to Git or a developer looking to solidify the basics before moving on to more advanced workflows. Whether you're a student, a self-taught programmer, or someone preparing for a technical interview, these flashcards will help you build a clear mental model of how Git tracks changes over time.

To get the most out of the deck, try using the spaced repetition feature consistently and review in short, regular sessions rather than cramming. As you study each command, it's worth opening a terminal and practicing it on a small test repository so the concepts stick through real use, not just memorization. Pairing the flashcards with hands-on experimentation will turn abstract terms like "staging area" and "commit" into familiar, everyday tools.

Git is a distributed version control system designed to track changes in source code throughout the software development lifecycle. Unlike older centralized systems, every developer working with Git holds a complete copy of the repository, including its full history. Git stores data as snapshots of the project at specific moments in time rather than as lists of file changes, which makes operations like branching, merging, and reverting both fast and efficient.

To understand Git, it is essential to grasp its three main areas. The working directory is the ordinary filesystem where files are edited and viewed; it contains the files checked out from the repository at a particular state. The staging area, sometimes called the index, acts as an intermediate buffer where changes are prepared before they become part of the project history. Finally, the repository itself, stored in a hidden .git directory, holds the committed snapshots, branches, tags, and other metadata that make up the project's permanent record.

A commit is the fundamental unit of history in Git. Each commit captures a complete snapshot of every tracked file at the moment it was created, identified by a unique SHA-1 hash that guarantees its identity. Commits also store metadata such as the author, the date, and a human-readable message describing the change. Because commits are content-addressed and immutable, they form a reliable chain of evidence for every modification made to the project.

Starting a new project or joining an existing one both rely on a small set of foundational Git commands. The command git init initializes a brand-new repository in the current directory by creating the hidden .git folder that holds all version-control data. To obtain a copy of an existing remote repository, developers use git clone <url>, which downloads every branch, tag, and historical commit into a new local working directory.

Once a repository exists, changes move through Git's three areas in a deliberate workflow. The command git add <file> stages modifications from the working directory into the index; git add . stages every change in the current directory at once. After staging, git commit -m "message" records those changes as a permanent snapshot in the local repository. The accompanying commit message should concisely describe the purpose of the change, helping teammates understand the project's evolution.

Two commands help developers stay oriented throughout this workflow. Running git status displays the current state of the working directory and the staging area, listing which files are modified, untracked, or ready to be committed. To review what has already been committed, git log prints the commit history, showing hashes, authors, dates, and messages. Options such as --oneline or --graph produce compact or visually structured views, which are especially useful in projects with many branches.

Branches are Git's mechanism for parallel development, allowing multiple lines of work to coexist without interfering. The command git branch <branch-name> creates a new branch that points to the current commit, while git checkout -b <branch-name> both creates a branch and immediately switches to it. To move between existing branches, git checkout <branch> updates the working directory to reflect the selected branch's state. Listing branches is done with git branch for local branches, git branch -r for remote ones, and git branch -a for everything; the active branch is always marked with an asterisk.

Once work in a branch is complete, it must be integrated back into another branch, typically the main line of development. The command git merge <branch> incorporates the named branch's changes into the current one. When the target branch has not diverged, Git performs a fast-forward merge by simply moving the branch pointer forward, producing no additional commit. The --no-ff option forces a merge commit even in this situation, preserving evidence that a branching workflow took place. To remove a branch that is no longer needed, git branch -d <branch> safely deletes it if its changes have already been merged; -D forces deletion of unmerged branches.

An alternative to merging is git rebase <branch>, which replays the current branch's commits on top of another branch to create a linear history. Because rebasing rewrites commit hashes, it should be avoided on branches that others have already pulled or cloned. Compared with merge, which preserves the exact branching topology using a merge commit, rebase produces a cleaner timeline but alters commit identifiers. When developers need to set aside incomplete work temporarily, git stash saves uncommitted changes and reverts the working directory to match the last commit; the work can later be restored with git stash pop. Stashes can be reviewed with git stash list and applied selectively using indexed entries like stash@{0}, while git stash drop <stash> permanently removes an entry.

A remote repository is a version of a Git project hosted on a server such as GitHub, GitLab, or Bitbucket, enabling developers to share work across teams. Before interacting with one, the local repository must be linked to it using git remote add <name> <url>, where origin is the conventional name for the primary remote. To inspect configured remotes, git remote -v lists them along with their URLs, while git remote show <name> provides additional detail about tracked branches and the remote's state.

Sending work to and retrieving work from a remote are the two core collaborative actions. The command git push <remote> <branch> uploads local commits to the remote, with the first push of a new branch typically using git push -u origin <branch> to establish tracking. In the opposite direction, git pull fetches changes from a remote and immediately merges them into the current branch, behaving as a combination of git fetch followed by git merge. Because git fetch only downloads remote changes without modifying the working directory, it is safer when one wants to review incoming work before integrating it.

Several commands help maintain a tidy and accurate view of remote state. A tracking branch is a local branch configured to follow a remote counterpart, allowing git pull and git push to work without specifying arguments; such tracking can be configured with git branch --set-upstream-to. To refresh tracking branches across every configured remote at once, git fetch --all downloads their latest changes without touching the working directory. When a remote's name needs updating, git remote rename <old> <new> renames it while preserving its URL. Finally, git remote prune <remote> removes local tracking branches whose counterparts have been deleted on the remote, keeping the local repository clean and consistent.

Mistakes are inevitable in software development, and Git provides several commands to correct them safely. The most powerful and dangerous is git reset <commit>, which moves the branch pointer to a previous commit. Depending on the flags used, reset behaves differently: --soft keeps changes staged, --mixed (the default) unstages them but preserves them in the working directory, and --hard discards them entirely. Because reset rewrites history by relocating the branch pointer, it is dangerous when the affected commits have already been shared.

A safer alternative for shared history is git revert <commit>, which creates a brand-new commit that undoes the changes introduced by the specified one. Unlike reset, revert preserves the existing commit chain, making it appropriate for branches that collaborators have already pulled. The choice between the two comes down to whether history should be rewritten privately or extended publicly.

When developers want to borrow a specific change rather than an entire branch, git cherry-pick <commit> applies the named commit onto the current branch, creating a new commit with the same content but a different hash. To recover work thought to be lost, the reflog, accessed via git reflog, records every reference update such as checkouts and resets, making it possible to find and restore commits that have been abandoned; entries remain valid for roughly thirty to ninety days by default. Recovery is typically performed by combining the reflog with git cherry-pick or git reset. For pinpointing the commit that introduced a bug, git bisect performs a binary search through history, letting developers mark commits as good or bad until the offending one is identified. To revise the most recent commit, git commit --amend replaces it with the currently staged changes and/or a new message, though it should not be used after the commit has been pushed to a shared branch.

Tags are Git's mechanism for marking specific commits as significant, typically for software releases. An annotated tag, created with git tag -a <name> <commit>, stores metadata such as a tagger name, date, and message, and behaves like a full Git object. A lightweight tag, created with git tag <name> <commit>, is simply a named pointer to a commit with no extra information. Annotated tags must be pushed explicitly with git push --tags, while lightweight tags usually follow their underlying commits when those are pushed.

For projects that depend on external code, Git submodules allow one repository to embed another as a subdirectory, tracking it at a specific commit rather than mirroring its history. A submodule is added with git submodule add <url> <path>, which clones the external repository and records its location in the .gitmodules file; the resulting configuration must then be committed. After cloning a repository that contains submodules, contributors run git submodule update --init to fetch and check out the referenced commits.

Several additional features help developers manage complex workflows. The command git worktree add <path> <branch> creates an additional working directory tied to the same repository, allowing parallel work on multiple branches without constantly switching checkouts. Git hooks are scripts stored in .git/hooks/ that run automatically on events such as commit or push, often used for validation tasks like pre-commit linting. An interactive rebase, started with git rebase -i <commit>, opens an editor that lets developers reorder, edit, or squash commits using commands such as pick and squash. Finally, git archive --format=zip HEAD produces a zip or tar archive of the project without the .git directory, which is useful for distributing clean releases.

Git offers a variety of tools for personalizing workflows and keeping repositories tidy. Git aliases, configured via git config --global alias.<shortcut> <command>, allow frequently used commands to be shortened; for example, git config --global alias.st status makes git st equivalent to running git status. This customization can dramatically reduce typing for repetitive operations.

Files that should never be tracked by Git are listed in a .gitignore file, which supports patterns such as *.log to ignore all log files or node_modules/ to exclude an entire directory. The .gitignore file itself is tracked and shared so that the whole team follows consistent exclusion rules. To remove untracked files that have accumulated in the working directory, the command git clean -f deletes them, -d extends this to directories, and -n performs a dry run to preview what would be removed. Because git clean permanently deletes data, it should be used with caution.

A bare repository, created with git init --bare, contains only the contents normally found inside .git and has no working directory. Bare repositories cannot be used to edit files directly; instead, they typically serve as central collaboration points on servers where developers push and pull changes. Together, these customization and maintenance features allow teams to shape Git to fit their specific workflows while keeping their repositories clean and well organized.