What Is Git? A Beginner’s Guide to Version Control

Every clone of a Git repository carries the complete history of the project. That works because Git records each commit as a snapshot of the whole tree instead of a list of edits, which makes it a distributed version control system built around snapshots.

Linus Torvalds and the Linux kernel community wrote it in 2005 after BitKeeper, the proprietary system they relied on, lost its free-of-charge status. Teams now use it for source code mostly, though documentation and configuration files get tracked the same way.

Storage stays compact even at scale. As of 2025, the Linux kernel source occupies 1.7 GB, while its full history of 1.4 million commits fits in 5.5 GB (git-scm.com, 2025).

What Is Git?

Git keeps a snapshot of a project’s files at every commit. Since each developer holds the full history locally, committing, comparing, and restoring versions all work offline.

Source code is what most people track with it. Documentation and configuration files follow the same mechanism.

Recording who changed which file, and when, is the core of version control. Every Git commit carries an author and a timestamp, plus a message.

Among professional teams, Git is the default source control management tool.

Before 2002 the Linux kernel ran on patches and archived files. That year it moved to BitKeeper, a proprietary distributed system. The relationship broke down in 2005 and BitKeeper’s free-of-charge status was revoked, so Torvalds and the kernel community wrote their own tool.

Pro Git lists the design goals as speed and a simple design, along with support for non-linear development across thousands of parallel branches. The tool also had to be fully distributed and able to handle big projects like the Linux kernel efficiently.

Git is free to use and change. The project does restrict the name “Git” and its logos under a trademark policy, to avoid confusion.

Some reference numbers, for anyone who just needs them.

• Created in 2005 by Linus Torvalds and the Linux kernel community (Pro Git)
• Released under the GNU General Public License version 2.0 (git-scm.com)
• Latest source release is 2.56.0, dated September 28, 2026 (git-scm.com, checked October 1, 2026)
• 96% of professional developers use Git (2022 Stack Overflow Developer Survey, cited by git-scm.com)

How Does Git Work?

Most operations run locally without a network connection. Git stores every commit as a snapshot of the whole project tree and keeps the full history inside each clone.

Distributed Model

Each clone is a complete repository. Committing reads from the local database, and so does comparing versions or browsing history, according to Pro Git.

CVS, Subversion, and Perforce are delta-based, so they store a list of changes per file. Git records the state of all tracked files at each commit instead. For a file that did not change, it stores a link to the identical copy it already has.

Offline, Subversion and CVS let you edit files but not commit. Perforce restricts most work.

Storage stays compact. As of 2025, the Linux kernel source is 1.7 GB, and Git holds its full history of 1.4 million commits in 5.5 GB (git-scm.com).

That puts the complete history at roughly 3.2 times the size of a single checkout.

Git Objects and Hashes

Git works as a content-addressable filesystem, which is a key-value store where the key is a hash of the content. Objects in the database get named by that hash, never by file name.

• A blob holds file contents and nothing else, not even the file name.
• A tree stands in for a directory and lists each entry’s mode, type, hash, and file name.
• A commit points to the top-level tree of a snapshot, plus its parent commits, the author and committer, and the message.
• A tag is a named reference to an object, optionally signed.

Each object gets a 40-character hexadecimal name, and for a commit that name is the commit hash. Git calculates it from the object’s type, size, and content, then stores the object under .git/objects, using the first 2 characters as the directory name and the remaining 38 as the file name (Pro Git).

Checksumming protects integrity. Changing the contents of a file or directory without Git noticing is impossible, and corruption in transit is detectable.

SHA-1 remains the default hash for new repositories. Git v2.13.0 and later use a hardened SHA-1 that resists the 2017 SHAttered attack, and the project picked SHA-256 as the successor in 2018, per the Git hash-function-transition documentation.

SHA-256 names run 64 hexadecimal digits, and older Git versions cannot read a SHA-256 repository. The BreakingChanges document plans to make SHA-256 the default for new repositories in Git 3.0, which has no release date yet, and it states there is no plan to deprecate SHA-1.

Working Tree, Staging Area, and Git Directory

A file counts as modified, staged, or committed depending on which area holds its latest version. Git keeps files in the working tree, the staging area (also called the index), and the Git directory.

Staging in Git is selective. You pick the exact changes that belong in the next commit and leave the rest in the working tree.

The working tree is one checked-out version of the project, pulled from the compressed database. The staging area is a file, usually kept inside the Git directory, that records what goes into the next commit.

The Git directory is the core of every Git repository. It holds the metadata and the object database, and it is the part copied when you clone.

Risk sits in the first two areas. Pro Git warns that uncommitted changes can be lost, while a committed snapshot is hard to lose, especially once pushed to another repository.

How to Install Git and Make Your First Commit

Installing takes one package command or a downloadable installer. After that, the first commit goes quickly.

Installing Git on Windows, macOS, and Linux

Installer walkthroughs for each platform are covered in this guide to installing Git. Run git --version afterwards to confirm the version.

Git for Windows is a project separate from Git itself, and it includes Git Bash, a command line shell for Windows users. The Chocolatey package is community maintained.

Binary installers trail the newest release a little. A source build gets the latest version but needs autotools, curl, zlib, openssl, expat, and libiconv (Pro Git).

First-Time Configuration

• Your name and email go in with git config --global user.name "Your Name" and git config --global user.email you@example.com. Git bakes both values into every commit you create.
• Run git config --global init.defaultBranch main to name the default branch (it works from Git 2.28 onward). Without it, git init creates a branch named master, and the BreakingChanges document schedules main as the default for Git 3.0.
• To pick the editor for commit messages, set git config --global core.editor. If unset, Git uses the system editor, and on Windows a misconfigured editor can end a Git-initiated edit early.
• The –system flag writes to the system-wide file, –global to ~/.gitconfig, and –local to .git/config, which is the default. Each level overrides the one before it, and git config --list --show-origin shows where every value comes from.

Making the First Commit

1. Run git --version to confirm the install.
2. Set your name and email with the two git config --global commands above.
3. Set the default branch name with git config --global init.defaultBranch main.
4. Run git init in the project folder. It creates the .git directory.
5. Stage a file with git add README.md.
6. Commit it with git commit -m "Add README".
7. Run git log to see the commit with its hash, author, date, and message.

Leave out -m and Git opens the configured editor for the message. Nothing enters history until git commit runs.

Every step above also exists as a button in graphical clients and editor integrations. Pro Git documents Git in Visual Studio Code, so the command line is optional for daily work.

How Do Branching and Merging Work in Git?

A merge joins two lines of work through either a fast-forward or a merge commit, and the branches doing that work are just movable pointers to commits.

Under the hood, a Git branch is a file holding the hash of the commit it points to. Creating one writes 41 bytes, the hash plus a newline, so it is instant on projects of any size (Pro Git).

HEAD points to the local branch you are on, which is not how HEAD works in Subversion or CVS. Switching branches moves HEAD and rewrites the working tree to match, and Git refuses if uncommitted changes would be overwritten. From Git 2.23 onward, git switch -c name creates and switches in one step, while git checkout -b name does the same on older versions.

The BreakingChanges document keeps git checkout alongside git switch and git restore, so older tutorials still work.

A fast-forward happens when the branch being merged sits directly ahead of the current one, so Git only moves the pointer. When histories have diverged, Git runs a three-way merge from both branch tips and their common ancestor, then records a merge commit with more than one parent.

Merge vs Rebase

Merge keeps parallel work exactly as it happened and adds a merge commit when histories diverged. That makes it safe on branches other people share.

Rebase replays your commits one by one on top of another branch. The history ends up linear. What gets abandoned is the original commits, with new ones written in their place.

The final snapshot is identical either way. Only the history differs.

Pro Git reduces the risk to one rule: never rebase commits that exist outside your repository and that others may have based work on. If someone force-pushes rebased commits, collaborators end up with duplicate commits that share an author, date, and message.

Git calculates a patch-id for each commit, so git pull --rebase can often recognize rewritten duplicates and skip them. The practical split is to rebase local commits before pushing and merge everything after.

Resolving Merge Conflicts

A conflict appears when the same part of the same file changed differently on both branches. Git pauses the merge and creates no merge commit until you resolve it.

1. Run the merge and read the CONFLICT message.
2. Run git status to list the unmerged paths.
3. Open each file and edit the block between <<<<<<< HEAD, =======, and >>>>>>>. The top half is your current branch.
4. Keep one side or combine both, then delete the marker lines.
5. Run git add on the file to mark it resolved.
6. Run git commit to finish the merge commit.

Screenshots for each step are in this guide to resolving merge conflicts in Git.

The graphical route is git mergetool, which opens a visual merge tool and stages the file once you confirm the result.

How Does Git Connect to GitHub and Other Remotes?

GitHub is one of several hosting platforms, while Git is the version control tool underneath it. Commits move between your clone and a remote through push, pull, and fetch.

A remote is any repository that lives elsewhere, including a folder on your own machine. git clone registers its source as origin automatically, and git remote add name url registers more.

git fetch downloads what you don’t have yet and leaves your current work alone. git pull does that and then merges the tracked remote branch into your current branch, which is why it can surprise people. Pushing uploads your commits and needs write access.

A push is rejected if someone else pushed first. Fetch their work, integrate it, then push again.

Since Git 2.27, git pull warns until the pull.rebase variable is set. Setting it to false keeps the merge behavior, and true rebases instead.

The difference between Git and GitHub is a difference of layers. Git stores and syncs history, while the platform adds the review workflow around it.

A pull request is a proposal to merge changes, with a conversation thread, a commit list, automated checks, and a files-changed diff (GitHub Docs). Draft pull requests cannot be merged until they are marked ready for review.

Opening one is covered step by step in this guide to creating a pull request in GitHub. GitHub merges a pull request by merge commit, squash, or rebase, depending on repository settings.

Stack Overflow’s 2025 Developer Survey put GitHub at 81.1% and GitLab at 35.6% of all respondents for code documentation and collaboration tools.

git-scm.com lists 10 hosting options in total. Switching hosts takes a second remote and a push, because the Git layer is identical on every one of them.

How Does Git Compare With Subversion and Mercurial?

Subversion is centralized by design, Git and Mercurial are distributed, and the release pace differs a lot from one system to the next.

Apache Subversion is an Apache Software Foundation project founded in 2000 by CollabNet. It describes its goal as centralized version control known for reliable data storage and a simple model.

The 1.14.5 release fixed a security issue, CVE-2024-46901, and the project urges users to upgrade. As of October 1, 2026, no stable release has followed it in nearly 22 months.

Mercurial calls itself a free, distributed source control management tool with an intuitive interface. Extensions handle customization, and the basic commands are hg clone, hg commit, and hg push.

Git makes sense when hosting options, GUIs, and editor integrations matter most, and git-scm.com describes that ecosystem as huge. Subversion fits when one canonical server and a simple model outweigh local history, or when a working setup already exists. Mercurial is the pick if you want a distributed model with a gentler command set, by its own description.

The model difference is a default, not a hard limit. Atlassian’s Git tutorial notes that Git can still run with one official, canonical repository that every change must reach.

Pro Git devotes chapters to using Git as a client for other systems and to migrating to Git. A Subversion repository that works today does not need to move until the team needs branch-heavy workflows or hosted review.

When Is Git a Poor Fit?

Large binary files and oversized repositories are where Git struggles, and it was never designed as a backup tool.

GitHub warns at 50 MiB per file and blocks anything above 100 MiB, according to its documentation. Git LFS is the documented escape hatch. It keeps a pointer file in the repository and stores the real file elsewhere.

The Git LFS cap is 2 GB on GitHub Free and Pro, 4 GB on Team, and 5 GB on Enterprise Cloud. Git LFS cannot be used with GitHub Pages sites or template repositories.

GitHub recommends keeping a repository under 1 GB and strongly recommends under 5 GB, and it may email you to take corrective action if a repository strains its infrastructure. Committing external dependencies inflates a repository too, so GitHub points to package managers such as Bundler, npm, and Maven. It also states that Git is not built for large SQL files or for backups.

Git’s own kernel-history example exceeds GitHub’s 5 GB guideline. The two sources measure different things: the Git project describes what the tool can store, while GitHub describes what keeps a hosted repository healthy.

A .gitignore file keeps listed paths untracked, so dependency folders and build output never enter history in the first place.

Removing a large file after it is committed means rewriting history. GitHub recommends git filter-repo, and an interactive rebase works only if the commits sit on one branch with no merges since.

On shared branches, reverting a commit in Git adds a new commit that undoes the old one, so nobody’s history changes underneath them.

Recovery is also where beginners stall. A large-scale study in the ACM Digital Library found that git revert, git reflog, git stash, git clean, and git reset are the 5 most-asked command topics on Stack Overflow, and all but git clean concern recovery.

Text-heavy source trees are the case Git was built for. Repositories full of large binaries need Git LFS or storage outside Git.

Git FAQ

What does the name Git stand for?

Nothing official. Linus Torvalds chose the name for the first version, and the project README offers “global information tracker” as one reading for good moods. He also described the tool in self-deprecating terms.

Is Git free for commercial use?

Yes. Git is open source under the GNU General Public License version 2, and a few parts carry other GPLv2-compatible licenses. The trademark policy restricts only the name and logos.

Who maintains Git today?

A single maintainer leads the project, and development runs through the Git mailing list at git@vger.kernel.org. The GitHub repository is a publish-only mirror, so contributors send patches to the list instead.

The maintainer posts regular “What’s cooking” reports on the status of each development topic.

Is Git only for source code?

No. Git stores any content as blob objects, so documentation, configuration files, and web pages all work. Text files suit it best, while large binaries need Git LFS on GitHub.

How do I undo a commit?

It depends on whether the commit left your machine. For the latest unpushed commit, git commit --amend rewrites it in place, and for shared commits git revert adds a new commit that cancels the old one.

Do I need the command line to use Git?

No. The core Git project is a command-line tool, but desktop GUIs and editor integrations are built on top of it, and git-scm.com keeps a directory of GUI clients.

Sourcetree is one example of a graphical client with branch visualization.

Habits That Keep Your Git Work Safe

Git protects committed work well and uncommitted work not at all, so small commits and a second copy on a remote come first.

Commit after every working change, and push to a remote at the end of each session. Rebase only commits that have never been pushed.

Commits come first because an uncommitted edit is the only loss Git permits. Pushing comes second because a single disk holds one copy of the history.

Ignore rules and Git LFS tracking belong before the first commit. A large file that enters history survives later deletions, and removing it takes a history rewrite with git filter-repo instead of a normal commit.

The trade-off is a noisier history, with many small commits that a local rebase can tidy before anyone else sees them. A walkthrough of how to use Git in daily work covers that routine command by command.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• VS Code Extensions That Are Actually Worth Installing - October 13, 2026
• Google Play App Signing Explained - October 11, 2026
• 5 Best NinjaOne Alternatives for Focused Endpoint Management - October 10, 2026