Whether you employ developers or work with an agency, your software's source code almost certainly lives in Git. Git is an open source version control system: it records every change to the code, who made it and why, and lets many people work on the same project without overwriting each other. You do not need to write code to benefit from understanding Git basics. Knowing the core ideas helps you ask the right questions, protect your company's ownership of its code and follow what your team is doing.
Why version control matters to the business
- History: every change is recorded, so you can see when and why something changed, and undo it if needed.
- Collaboration: several developers can work in parallel and combine their work safely.
- Accountability: each change is linked to an author and, ideally, to a task or ticket.
- Continuity: the full project and its history exist in a central place, not on one developer's laptop.
- Quality control: changes can be reviewed and tested before they reach production.
Git basics: the key concepts
Repository
A repository ("repo") is the project folder plus its complete history. Each developer has a full copy on their machine, and a shared copy usually lives on a hosting platform such as GitHub, GitLab or Bitbucket, or on a self-hosted server such as GitLab Community Edition or Gitea.
Commit
A commit is a saved snapshot of changes with a message describing them. Good commit messages explain why a change was made, for example "Fix rounding error in GST calculation for discounted items", not just "fixes".
Branch
A branch is an independent line of work. Developers create a branch for each feature or fix, work on it without affecting the main code, and merge it back when it is ready. The main branch (often called main) should always reflect working, releasable code.
Merge
Merging combines the changes from one branch into another. If two people changed the same lines differently, Git reports a conflict, which a developer resolves by deciding what the final version should be.
Pull request (or merge request)
On hosting platforms, a developer proposes merging a branch by opening a pull request. Colleagues review the changes, automated tests run, and discussion is recorded. Once approved, the branch is merged. This is the main quality gate in most teams.
Tag
A tag marks a specific commit, typically a release such as v2.3.0, so you can always identify exactly what code was deployed.
A typical workflow
A common, simple workflow for business teams looks like this:
git switch main
git pull # get the latest shared code
git switch -c feature/invoice-export # create a branch for the task
# ...edit files...
git add .
git commit -m "Add CSV export for invoices"
git push -u origin feature/invoice-export
# open a pull request, get review, merge into mainAfter merging, the code is deployed, ideally by an automated pipeline rather than by someone copying files to a server.
Choosing a branching approach
| Approach | How it works | Suits |
|---|---|---|
| Trunk-based / short-lived branches | Small branches merged into main frequently, often daily | Teams with good automated tests deploying often |
| Feature branches with pull requests | One branch per feature or fix, merged after review | Most small and medium teams |
| Release branches | Separate branches stabilise each release while new work continues | Products with scheduled releases or several supported versions |
Simpler is usually better. Complex branching models create overhead and merge conflicts; adopt one only if your release process genuinely needs it.
Rules every business should set
Own the repository
Create repositories under your company's organisation account on the hosting platform, and grant developers or agencies access. Never rely on a repository owned by an individual or a supplier. If the relationship ends, you remove their access; the code stays with you.
Protect the main branch
Most platforms let you require pull requests, at least one approving review and passing tests before anything merges into main. This prevents accidental or unreviewed changes reaching production.
Never commit secrets
Passwords, API keys and private certificates should not be stored in the repository, because anyone with access, now or in future, can read them in the history. Use environment variables or a secrets manager, and add sensitive files to .gitignore. If a secret is committed by mistake, treat it as exposed and change it.
Manage access properly
Require two-factor authentication on the hosting platform, give people only the access they need, and remove accounts promptly when people leave.
Link work to tasks
Reference ticket or task numbers in branch names or commit messages, so you can trace any change back to the business request behind it.
Back up the repository
Hosting platforms are reliable, but an independent backup of critical repositories, including issues and wiki data where possible, protects against account problems or accidental deletion.
What non-developers can do with Git
Project sponsors and managers can browse the hosting platform's web interface to see recent activity, read pull request discussions, check release tags and confirm that work described in reports actually exists in the code. You do not need the command line for any of that.
If you are commissioning software, make repository ownership and access a contract requirement from day one. Every web application development or mobile app development project should hand you a repository you control. If you would like a self-hosted Git platform rather than a public service, our open source solutions include installing and maintaining one.
Key takeaways
- Git records every change to your code, enabling collaboration, review and recovery.
- Core concepts: repository, commit, branch, merge, pull request and tag.
- Keep repositories in your company's account and protect the main branch.
- Never store secrets in Git, enforce two-factor authentication and back up critical repositories.