Git is a version control system that helps software developers track changes to files, preserve earlier versions of their work, and collaborate without losing control of a project. It records the history of a codebase, allows developers to work on separate features simultaneously, and provides ways to combine their changes into a shared project.
Although Git is most commonly associated with software development, it can manage many kinds of text-based files, including documentation, configuration files, and technical writing. Its central purpose is to make changes traceable and recoverable. Rather than relying on a collection of manually saved copies, developers use Git to maintain an organized history of how a project evolves.
Understanding Git begins with a broader concept: version control.
What version control means
Version control is a system for recording and managing changes to a set of files over time. It allows users to determine what changed, when a change was recorded, and how the current version differs from an earlier one. Depending on the system and its configuration, it can also help identify who made a change and why.
Without version control, developers often have to manage changes manually. Someone might save files under names such as website-final, website-final-updated, and website-final-revised. This approach becomes difficult to maintain as a project grows. It may be unclear which copy is authoritative, which changes were made between versions, or how to recover a working implementation after introducing a defect.
Version control addresses these problems by maintaining a structured history of a project’s files. Developers can record a meaningful set of changes, compare versions, restore earlier content, and experiment without necessarily affecting the main line of development.
Version control is especially valuable because software is rarely completed in one uninterrupted sequence. Developers add features, correct defects, improve performance, update dependencies, and revise existing code. These changes can interact in unexpected ways. A recorded history provides context for understanding how the software reached its current state.
There are two broad categories of version control systems. Centralized systems maintain a primary repository on a central server, while distributed systems give each participant a local repository containing the project’s history. Git belongs to the distributed category.
How Git stores and tracks changes
Git organizes a project’s history around snapshots, commits, and relationships between versions. A repository is the data structure that holds the project’s tracked content and its version history. It also contains information Git uses to connect individual versions into a coherent sequence of development.
A Git repository can exist on a developer’s computer or on a remote server. The local repository allows many operations to take place without a network connection, including examining history, recording commits, creating branches, and comparing changes.
When Git records a commit, it creates a permanent historical record of a selected set of changes. A commit includes information such as its author, a timestamp, a descriptive message, and a reference to the project’s recorded state. It also connects to earlier commit records, establishing the history of the project.
Git’s internal storage is more sophisticated than a simple series of complete file copies. It stores file content and directory information in objects that can be reused when different versions share the same data. Git identifies these objects using cryptographic hash values, which help it refer to stored content and detect changes to that content.
Because unchanged content can be shared across versions, Git can maintain a detailed history without necessarily duplicating every file in full for every commit. Its storage efficiency depends on the content and repository structure, but the underlying design makes tracking extensive development histories practical.
A commit is not simply a backup of the entire computer. Git primarily tracks files that have been added to the repository and does not automatically record every file, application, system setting, or external dependency on a developer’s machine. Files must be tracked intentionally, and project configuration often determines which files should be excluded.
This distinction matters when using Git for recovery. A developer can restore recorded project content, but Git cannot automatically reconstruct unrecorded work or guarantee that an application will run identically without the necessary environment, dependencies, and configuration.
How commits create a project history
A commit is one of the fundamental building blocks of Git. It records a particular state of the project’s tracked files and connects that state to the repository’s existing history.
Developers usually create commits around a logical unit of work, such as correcting a calculation, adding a validation rule, or implementing part of a user interface. A well-designed commit is small enough to understand and review but complete enough to represent a meaningful change.
Consider a developer fixing a form that accepts invalid email addresses. The developer modifies the validation logic, tests the behavior, and records the change in a commit with a message explaining the correction. If a later update introduces a regression, the developer can compare the new code with the earlier commit to investigate what changed.
Git does not require every commit to represent a finished feature. Developers can create commits throughout the development process, provided the recorded changes make sense for the project and its collaborators. The resulting history can document both the evolution of the software and the reasoning behind important decisions.
Each commit has an identifier derived from its contents and metadata. In ordinary use, developers often refer to commits through shorter identifiers or named references rather than memorizing their full identifiers.
The history is generally a graph rather than merely a single list. Most projects have a primary development line, but branches and merges can create multiple paths that later reconnect. This structure allows Git to represent parallel work while preserving the relationships between different versions.
Commits are immutable in the normal Git workflow: creating a new commit adds another historical record rather than modifying an existing one. However, Git also provides operations that can rewrite local history, such as amending a commit or rebasing a branch. These operations create different commit records and can change identifiers. This is one reason rewriting history requires care when other people already depend on the affected commits.
The working directory, staging area, and repository
Git separates editing files from recording their changes. This separation gives developers control over exactly what enters each commit.
The working directory is the collection of project files that a developer can open and modify. When a developer edits source code, those edits initially exist in the working directory. Git can detect differences between the working files and the recorded version, but the edits do not automatically become part of the repository’s history.
The staging area, also called the index, provides an intermediate step. It holds the proposed content for the next commit. Developers can stage selected changes, review them, and decide which modifications should be recorded together.
The repository stores the committed history. Once a commit is created, the staged content becomes part of a new recorded version, linked to the existing history.
These three areas serve different purposes. The working directory is where changes are made, the staging area defines what will enter the next commit, and the repository preserves committed versions.
A typical workflow involves editing a file, examining the differences, staging the intended changes, reviewing the staged content, and creating a commit. Git allows developers to stage only part of a file’s changes, which can be useful when one editing session contains several unrelated modifications.
This separation is particularly helpful in collaborative projects. A developer might change a function and also make an unrelated formatting adjustment. By staging only the relevant lines, the developer can create a focused commit that is easier for colleagues to understand and review.
Git also distinguishes between tracked and untracked files. A tracked file is one Git already knows about, whether through a recorded version or the staging process. An untracked file exists in the working directory but has not been added to version control. This allows developers to create temporary files or local configuration files without automatically including them in the project’s history.
How branches allow parallel development
A branch is a named reference to a commit that provides a convenient way to develop a separate line of work. Branches let developers make changes without immediately incorporating them into the main development line.
Suppose a team maintains a website and needs to add a search feature while continuing to fix existing defects. A developer can create a branch for the search feature and make several commits there. Another developer can work on a separate branch to correct a defect. Both can progress independently, even though their work began from the same project history.
In Git, a branch is lightweight. It is essentially a movable reference to a commit rather than a complete independent copy of the entire repository. Creating a branch is therefore usually inexpensive.
As commits are added to a branch, its reference advances to the newest commit. The branch’s history retains its connection to the commits from which the work began. Developers can switch between branches to work on different tasks, compare their changes, and combine the results when appropriate.
Teams often maintain a branch named main as the principal development line or the source of releases. The exact workflow varies: some teams integrate changes frequently, while others use longer-lived release branches or separate branches for maintenance. The branch name itself has no special technical meaning to Git; its significance comes from how the team uses it.
Branches make experimentation safer, but they do not automatically make all changes safe. A developer can still introduce a defect on a branch, and a branch may become difficult to integrate if the main development line changes substantially while the work continues. Branching isolates the history of changes; it does not eliminate the need for testing or coordination.
How Git combines changes through merging
When work on a branch is ready to be incorporated into another branch, developers can use Git’s merge operation. Merging combines development histories so that the resulting branch includes the relevant changes from both lines of work.
If one branch contains a new search feature and another contains an independent correction to the site’s navigation, Git may be able to merge the changes automatically. The operation depends on the relationship between the branches and the files they modify.
When one branch has advanced directly from the other without competing changes, Git can sometimes perform a fast-forward merge. Instead of creating a new merge commit, Git simply advances the destination branch reference to a later commit.
When both branches have developed independently, Git commonly performs a three-way merge. It examines the common ancestor of the branches and compares the changes made along each line. This lets Git determine which modifications can be combined and whether any parts of the result require human judgment.
A merge commit records the combination of histories when the merge creates a new commit. It typically has more than one parent, preserving the fact that the resulting version brings together distinct lines of development.
Merging is not the same as copying one branch over another. Git attempts to integrate changes while preserving work from both sides. When the changes are compatible, it can produce a combined result automatically.
The distinction becomes important when developers edit the same part of a file. Git may not have enough information to determine the intended result. In that situation, it reports a merge conflict and asks the developer to resolve it.
What merge conflicts are and why they occur
A merge conflict occurs when Git cannot confidently combine changes according to its merge rules. This often happens when different branches modify overlapping portions of a file, but conflicts can also arise from other incompatible changes, including certain file deletions, renames, or structural modifications.
Imagine two developers editing the same function. One changes the function to reject invalid input, while the other changes its internal calculation. If their edits overlap, Git may be unable to produce a correct result automatically.
Git identifies the conflicting areas and provides information that helps the developer compare the competing versions. The developer then determines how the changes should be combined, edits the file into a valid result, and completes the merge.
A conflict does not necessarily mean that either developer made a mistake. It indicates that the intended combined behavior cannot be inferred reliably from the recorded changes alone. Even changes that merge automatically can produce logical errors if the developers have made incompatible assumptions about how the software should behave.
For example, one branch might change a function to return a value in seconds while another branch assumes that the same function returns milliseconds. Git may merge the code without reporting a conflict because the text changes do not overlap. The resulting program can still behave incorrectly.
This illustrates an important limitation: Git understands file content and change relationships, not the full meaning of a program. It can identify many structural conflicts, but developers remain responsible for checking the correctness of the combined software.
How remote repositories support collaboration
Git is a distributed version control system, meaning that each full clone of a repository contains its own copy of the repository’s history. Developers can examine commits, create branches, and record changes locally without requiring constant access to a central server.
A remote repository is a version of the repository hosted somewhere else, such as on a shared server or a code-hosting service. It provides a common location where collaborators can exchange changes. GitHub, GitLab, and Bitbucket are examples of services that host Git repositories and add collaboration features.
Git uses several operations to coordinate local and remote histories. Cloning creates a local repository from an existing repository. Fetching downloads new objects and updates remote-tracking references so developers can inspect changes available from the remote. Pulling generally fetches those changes and then integrates them into the current branch, commonly through a merge or, depending on configuration, a rebase. Pushing sends local commits and related objects to a remote repository when the update is permitted.
A remote-tracking branch is a local reference that records the state of a branch as last observed on a remote. It helps developers understand what the remote contains, but it is not necessarily updated continuously. Fetching refreshes this information.
These operations are distinct from one another. Fetching does not normally merge downloaded changes into the current branch, and committing changes locally does not automatically publish them to a remote repository. Pushing is the step that shares local commits with the remote.
Because Git is distributed, a developer can commit work while offline and push it later. However, collaboration still requires coordination. If another developer pushes changes to the same remote branch first, a later push may be rejected because it would not be a permitted update. The developer must integrate the new remote history before trying again.
Remote repositories can also support access controls, code reviews, automated testing, issue tracking, and release management. These features are commonly provided by hosting platforms rather than by Git’s core version control mechanism itself.
How Git supports code review and software quality
Version control improves software development not only by preserving history but also by making changes easier to inspect. A difference, often called a diff, shows how file content changed between two versions. Developers can use diffs to review their own work, understand another person’s changes, and identify unexpected modifications.
Many teams combine Git branches with code review. A developer proposes a set of changes, and colleagues inspect the relevant commits or the difference between the proposed branch and its destination. Reviewers may identify defects, unclear logic, missing tests, security concerns, or inconsistencies with the project’s design.
Code-hosting services often package this process into pull requests or merge requests. These are collaboration mechanisms built around proposed changes, not fundamental Git objects. They allow reviewers to discuss specific lines, request revisions, and check whether required automated tests have passed before integration.
Automated testing can be connected to repository events so that software is built and tested when changes are proposed or merged. This helps teams detect some errors before releasing new versions. Git itself does not run these tests or guarantee that the code is correct; it provides the version history and change events around which other tools can operate.
The combination of recorded changes, code review, and testing makes defects easier to investigate. When a problem appears, developers can compare versions and sometimes use tools such as git bisect to identify the commit that introduced the behavior. The process narrows the search by testing successive points in the project’s history.
Version control cannot replace sound engineering practices, but it supports them by making changes explicit, reviewable, and traceable.
How Git differs from a backup system
Git can help recover lost or unwanted changes, but it is not a complete backup strategy. Its primary purpose is to manage the history of tracked project content, not to protect every kind of data against every possible failure.
Committed content is often recoverable even after a file is changed or deleted in a later commit. Developers can inspect older versions, restore individual files, or create new commits that reverse earlier changes. Git’s history therefore provides a useful form of protection against many ordinary editing mistakes.
However, changes that have never been committed are not necessarily preserved in the repository. Some may be recoverable through Git’s temporary internal records, but that should not be treated as a reliable recovery method. A developer who deletes uncommitted work may lose it permanently.
Git repositories can also be lost through disk failure, accidental deletion, or other damage. A remote copy offers some protection, but it is not automatically a complete backup if the same mistake or destructive operation affects every copy. Important projects should use appropriate backup and recovery procedures.
Git is also not designed to store every kind of file efficiently. Large binary files, such as video, audio, and compiled assets, may be difficult to manage in an ordinary repository because changes often cannot be represented as compact textual differences. Specialized approaches, including Git Large File Storage, can help manage some large-file workflows.
Secrets require particular care. A password, private key, or access token committed to a repository may remain in its history even after the file is deleted in a later commit. Removing the visible file does not necessarily remove the sensitive information from earlier commits or other copies. Exposed credentials should be revoked or rotated, and removing the material from repository history may require additional steps.
A version history is most useful when combined with deliberate practices for backups, access control, sensitive data, and file management.
How Git compares with other version control systems
Git is not the only version control system. Subversion, commonly known as SVN, is a prominent example of a centralized system. In a centralized workflow, a server maintains the primary version history, and users typically interact with that central repository to obtain or submit changes.
Git’s distributed design gives each full clone its own repository history. This supports offline commits, flexible branching, and a variety of collaboration patterns. It also allows developers to experiment with local changes before sharing them.
Centralized systems can provide simpler administrative models for some organizations, particularly when teams want a single authoritative repository and tightly controlled access to shared files. Distributed systems introduce different coordination and history-management considerations, especially when branches diverge or teams need to rewrite or reorganize commits.
Neither architecture automatically guarantees better software. The appropriate choice depends on the project’s needs, collaboration model, infrastructure, and established practices. Git has become widely used because its distributed model, efficient history management, branching capabilities, and broad ecosystem fit many modern software development workflows.
It is also important to distinguish Git from services that host Git repositories. Git is the version control software. A hosting platform provides infrastructure and additional features for collaboration, such as web interfaces, review workflows, permissions, and automated build systems. A team can use Git without a public hosting service, and it can host a repository on its own infrastructure.
When Git is most useful
Git is especially useful when a project changes repeatedly, involves multiple contributors, or requires a reliable record of how decisions and implementations evolved. It allows a developer to investigate earlier behavior, separate experimental work from the main development line, and combine contributions with a clear history.
Small projects can benefit from Git as well. Even a single developer can use commits to track progress, compare alternatives, and recover earlier versions of tracked files. A project does not need to be large or collaborative to justify version control.
Git becomes more effective when commits have clear messages, changes are divided into understandable units, branches serve a defined purpose, and developers review changes before integration. Frequent testing and careful handling of secrets further improve the reliability of the workflow.
The tool does require some learning. Developers need to understand the distinction between local and remote work, how the staging area affects commits, and how branches and merges represent parallel development. These concepts can initially seem complicated, but they correspond to practical problems that arise whenever software changes over time.
Git’s most important contribution is not simply the ability to undo mistakes. It gives software development a structured history. Each recorded change becomes part of an evolving body of work that developers can inspect, compare, share, and build upon. That history makes complex projects easier to maintain because the current version is connected to the decisions and changes that produced it.