Code repository

How a source code repository works

A source code repository holds more than the current code. It holds every saved change, called a commit, along with who made it, when, and a short message explaining why. That history is what separates a repository from a shared folder.

A typical change on a team moves through the repository like this:

1. A developer creates a branch, a separate line of work, for a feature such as "add Arabic language support."
2. They commit changes to that branch as they go, without affecting anyone else's work.
3. When the work is ready, they open a pull request (GitLab calls it a merge request). Teammates review the changes line by line and leave comments.
4. Automated checks run against the branch: tests, linting and a trial build.
5. Once approved, the branch is merged into the main branch and becomes part of the product.

If a merged change later causes a problem, the team can see exactly what changed and revert it.

What a code repository typically contains

• Application source code
• Configuration files and build scripts
• Automated tests
• Database migration scripts
• Documentation, such as a README explaining how to run the project
• Infrastructure definitions, if the team uses infrastructure as code

What it should not contain: passwords, API keys or other secrets. These belong in a secrets manager or environment variables. A secret committed to a repository stays in its history even after it is deleted from the current files, so it has to be rotated.

Hosted vs self-hosted code repositories

Most teams host their code repositories on a platform such as GitHub, GitLab or Bitbucket. These add access control, code review, issue tracking and automation on top of Git. Some organizations self-host GitLab or a similar tool for data-control reasons. Either way, the underlying repository is usually Git, so it can be moved between platforms with its full history.

Repositories can be private, visible only to invited people, or public, as with open-source projects. Business software is almost always private.

Why the repository matters to a business owner

If you are paying for custom software, the repository is the most important thing you receive. The running app can be rebuilt from the repository; the repository cannot be rebuilt from the running app.

Common problems when this is overlooked:

• The code lives only on a freelancer's laptop or in an account you do not control.
• There is no meaningful history, so nobody can tell when or why something changed.
• The repository exists, but the project only builds on one person's machine because the setup steps were never written down.

What to ask your development team

• Is the repository in an organization account that we own, with our own admin access?
• Does every change go through a pull request and review?
• Are secrets kept out of the repository?
• Can a new developer clone it and run the project using only the README?
• Is the main branch protected so nobody can push to it directly?

If you are commissioning custom software and want clear ownership of your code from the first day, our custom software development team can set that up with you.