Repository in Git: What It Is, Types, and How They Work

What Is a Repository in Git

Git Repository — is a data structure where the version control system stores metadata and objects describing the history of file changes in a project. When a developer initializes a repository with the command git init, Git creates a hidden folder .git in the project root.

Inside this folder are all the objects, references, and configuration files necessary for the system to operate. The repository is not tied to a specific location — a developer can create it locally and then link it to a remote server.

Git uses a distributed repository model: each team member has a full copy of the history on their computer. This means that most operations — commit, history viewing, branch creation — are performed locally without contacting the server.

According to Git documentation, the distributed architecture makes the system fault-tolerant: if the server goes down, any local repository can serve as a source for restoring the full project history.

Local and Remote Repository

Local Repository — is a copy of the project on the developer’s computer. It contains the entire history of commits, branches, and tags, and allows performing commit, branch, merge, and rebase operations without an internet connection.

Remote Repository — is hosted on a server and serves as a synchronization point for all team members. Developers push their changes using git push and fetch others’ changes using git pull.

The connection between local and remote repositories is configured through remote origin — the server URL stored in the Git configuration. One local repository can be linked to multiple remote repositories, which is useful when working with forks.

The main advantage of this model is that developers can work on code offline and synchronize changes only when ready to share the result.

Differences Between Local and Remote Repository

How Git Stores Data in a Repository

Git’s storage model is fundamentally different from other version control systems. Instead of storing a list of changes (deltas) between versions, Git stores complete snapshots of all project files at the time of each commit.

Each object in the repository is identified by a unique SHA-1 hash of 40 characters. If the file content hasn’t changed between commits, Git does not create a new object but reuses the existing one — this saves space.

Git uses four types of objects: blob (file content), tree (directory structure), commit (snapshot with metadata), and tag (named reference to a commit). All objects are stored in the .git/objects folder.

According to Git Internals, Git’s object model ensures data integrity: any change to file content results in a new hash, making it impossible to alter history unnoticed.

Structure of the .git Folder

The .git folder is the heart of the repository. Without it, Git cannot track changes, and an ordinary directory remains just a collection of files. Understanding this folder’s structure helps diagnose repository issues.

• objects/ — all repository objects: blobs, trees, commits, tags. Stored in compressed form.
• refs/ — references to commits: heads (branches), tags (labels), remotes (remote branches).
• HEAD — a file pointing to the current active branch or commit.
• config — repository settings: remote URL, user name, email, and other parameters.
• index — the staging area where Git stores information about files prepared for commit.
• logs/ — reference update logs (reflog) that store the history of HEAD and branch movements.

The HEAD file deserves special attention. In normal state, it contains a symbolic reference to a branch, for example ref: refs/heads/main. In a detached HEAD state, it points directly to a commit — this means new commits will not be attached to any branch.

Basic Repository Operations

Working with a Git repository involves a set of basic operations that developers perform daily. Each operation changes the repository state by adding new objects or moving references.

• git init — creates a new empty repository in the current directory. Git creates the .git folder with the initial structure.
• git clone — copies an existing remote repository to the local machine along with the entire commit history.
• git add — adds file changes to the staging area (index), preparing them for commit.
• git commit — creates a project snapshot based on the data from the index and saves it as a new commit object.
• git push — sends new commits from the local repository to the remote one, updating branches on the server.
• git pull — fetches new commits from the remote repository and merges them with the current local branch.

The push and pull operations are the only ones that require a connection to the remote server. All other operations are performed entirely locally, ensuring high speed even with a large history volume.

File Lifecycle in a Repository

Each file in the repository goes through four states: untracked, modified, staged, and committed. Git only tracks files that have been explicitly added via git add or are already in the commit history.

Understanding this model is key to working effectively with Git. A developer can selectively prepare only part of the modified files for commit, creating logically complete commits with clear descriptions.

Popular Platforms for Hosting Repositories

Remote repositories are typically hosted on specialized platforms that provide a web interface, access control system, and additional tools for collaborative development.

• GitHub — the largest platform with over 100 million repositories. Offers Actions, Pull Requests, Issues, and Wiki. Free for public projects.
• GitLab — a platform with integrated CI/CD, Container Registry, and a built-in DevOps pipeline. Available as SaaS and self-hosted versions.
• Bitbucket — an Atlassian solution with Jira and Trello integration. Popular in corporate environments due to flexible access settings.

The choice of platform depends on team size, privacy requirements, and necessary integrations. For mobile development, GitHub is often chosen due to broad community support and integration with CI/CD tools for iOS and Android.

Command Examples for Working with a Repository

Let’s consider a practical scenario: a developer clones an existing repository, creates a new branch, makes changes, and pushes them to the server. Each command demonstrates working with various repository components.

# Cloning a remote repository
git clone https://github.com/user/mobile-app.git

# Navigating to the project directory
cd mobile-app

# Creating a new feature branch and switching to it
git checkout -b feature/auth

# Checking the status of modified files
git status

# Adding all changes to the staging area
git add .

# Creating a commit with a description
git commit -m "Add authentication module"

# Pushing changes to the remote repository
git push origin feature/auth

The git status command is one of the most useful in daily work. It shows which files are modified, which are staged for commit, and which are not tracked by Git at all.

Viewing Commit History

To analyze repository history, the git log command is used with various formatting flags. It displays the chronology of commits, their authors, dates, and SHA-1 identifiers.

# Viewing history with branch graph visualization
git log --oneline --graph --all

# Viewing changes in a specific commit
git show a1b2c3d

# Comparing the current state with the last commit
git diff HEAD

# Viewing history of a specific file
git log --follow src/MainActivity.kt

The --graph flag displays an ASCII branch graph, which is especially useful in repositories with active work across multiple branches. For mobile projects with frequent releases, a visual graph helps quickly assess the development structure.