Glossary

Repository

A repository holds source code, history, and related project files. It is not the same as a project, Composer repository, or the Repository pattern in application architecture.

Short definition

Storage for a project’s versioned history and shared configuration.

A local Git repository contains Git metadata and history alongside a working copy of files. A remote repository allows a team to share history, control access, use pull requests, or trigger CI. Commits and branches form its traceable history. Public and private repositories differ in availability, not automatically in their level of security.

In software, the word repository is also used for the Repository pattern: an object-oriented pattern that abstracts loading and storing application data. This article describes a source code repository; the application pattern is neither a file folder nor Git hosting.

The problem it solves

A shared home for code, history, and collaboration rules

A repository is the shared source for development, review, builds, and tracing project changes.

project source code, tests, documentation, and configuration
commit history, branches, and release tags
pull requests or merge requests and access control
CI workflows, Docker configuration, and database migrations
a README, licence information, and technical context for other developers

Practical example

What belongs in a PHP application repository

An e-commerce application repository may contain source code, tests, composer.json, composer.lock, Docker configuration, CI workflows, migrations, and a README. Together, these files make it possible to build, inspect, and understand a specific version of the application.

Production secrets, local caches, uploaded user files, and the derivable vendor directory usually do not belong there. .gitignore can prevent untracked files from being added, but it does not purge an already leaked credential from the history.

shop/
├── .git/
├── src/
├── tests/
├── composer.json
├── composer.lock
├── docker-compose.yml
└── README.md

How it works

Local and remote history work together

Text diagram of a typical checkout: remote repository → clone → local .git and working tree → commit → push.

Remote source A remote repository hosts shared branches and access rules. It may be bare, meaning it has no working copy.
Clone A developer creates a local copy of both history and the working tree, where files are edited.
Local change A commit records selected changes in local Git history; they may still be invisible to the team.
Sharing and review Push sends a branch to the remote, where a hosting service may provide a pull request, checks, and branch protection.
Integration and maintenance After merging, the repository retains the history, documentation, and configuration needed for a subsequent build or release.

Important concepts

History, a working copy, and hosting are different layers.

A precise distinction matters for security, access, and automation.

Local and remote repository

Every clone has a local repository. A remote is a sharing destination, not a special kind of Git; origin is merely a conventional local remote name.

Working tree and .git

The working tree contains files a developer edits. Git metadata is usually stored in .git; worktrees may use a reference to shared metadata.

Branch, tag, and default branch

Branches support developing changes, a tag marks a specific historical point, and the default branch is a team convention, not a technical authority.

Documentation and access

A README, licence, CI, and branch-protection rules are important parts of a shared product. Access must reflect the roles of both people and automation.

.gitignore

Ignore rules apply to files that are not yet tracked. They do not remove data already present in a commit or remote clones.

Benefits and limitations

One store simplifies collaboration but needs management.

Benefits

shared history of code, documentation, and configuration
repeatable application builds from versioned files
review, CI, and access control in one workflow
traceability of changes and release versions

Common mistakes

storing a secret or personal data in a public repository
treating a private repository as secure without access management
assuming .gitignore removes data that has already been published
splitting a system into many repositories without clear ownership and lifecycles

When it makes sense

For code and configuration that must be reproducible and shared.

A repository is the natural foundation for almost any maintained software. It makes it possible to hand a project to another developer, connect tests, and rebuild a specific application version.

Choosing between a monorepo and multiple repositories is an architectural and organisational decision. It should consider ownership, shared changes, release independence, and coordination costs, not merely the number of services.

What to consider

A repository is also a security and communication boundary.

Files can remain in history for a long time, so agreed rules matter more than simply creating the repository.

do not commit secrets, local caches, or user uploads
version source code, tests, migrations, and reproducible configuration
maintain a README and basic instructions for local development and checks
protect the main branch with review and CI according to project risk
rotate a credential immediately if it is exposed instead of merely editing the file

Common questions

Repositories without confusion

What is the difference between a project and a repository?

A project is a broader whole. It may have one repository, several repositories, or be part of a monorepo with multiple applications.

What do local and remote repositories mean?

A local repository is the history in a developer’s clone. A remote repository is used to share branches and common history.

Is a GitHub repository the same as Git?

GitHub hosts a Git repository and adds collaboration services. Git is the version control system itself.

What does .gitignore handle, and what does it not?

It helps ignore files that are not yet tracked. It does not remove a file or secret that has already been committed and shared.

How I maintain development quality

I connect the repository with tests, checks, and readable history.

In PHP projects, I use versioned code, quality gates, and automation so development remains traceable and safely repeatable.

How I approach testing and quality Discuss your project without obligation