Version control and Git for non-developers: why it matters and the basic workflow

If you have ever saved a file as “proposal_final_v3_REALLY_FINAL.docx”, you already understand the problem version control solves. Software teams change thousands of lines of code across many files, often several people at once. They need to know what changed, who changed it, why, and how to undo it when something breaks.

Git is the tool most teams use for this, usually alongside a hosting service such as GitHub, GitLab or Bitbucket. You don’t need to use Git yourself to benefit from understanding it. Knowing the basic workflow helps you ask for the right things: that your company owns the code, that changes are reviewed, and that a bad release can be rolled back quickly.

What version control does

The free Pro Git book, published on the official Git website, defines version control as “a system that records changes to a file or set of files over time so that you can recall specific versions later”. Its section About Version Control lists what that gives you. You can revert files or a whole project to an earlier state, compare changes over time, and see “who introduced an issue and when”. If you “screw things up or lose files, you can easily recover”.

The book also explains why Git’s design matters. Older centralised systems kept the full history on one server, which was a single point of failure. Git is distributed: each copy of a project mirrors “the repository, including its full history”. In the book’s words, “every clone is really a full backup of all the data”. That doesn’t replace proper backups, but it means a lost laptop or a failed server rarely means lost code history.

The words you will hear

The basic workflow

Teams vary, but many follow something close to what GitHub calls GitHub flow. It has six steps:

1. Create a branch, so the work doesn’t touch the default branch.
2. Make changes and commit them to the branch.
3. Open a pull request “to ask collaborators for feedback on your changes”.
4. Address review comments by pushing more commits to the same branch.
5. Merge the pull request once it is approved.
6. Delete the branch to show the work is finished.

GitHub’s page about pull requests describes them as “proposals to merge code changes into a project”. The pull request is where most of the useful conversation happens. It shows exactly which lines changed, links to the task being worked on and records who approved it. Work that isn’t ready can be opened as a draft, which can’t be merged and doesn’t automatically ask code owners for a review.

The UK Government’s Service Manual guidance on maintaining version control adds two habits worth asking for. Commit messages should explain what changed and why, and link to supporting material such as the user story or bug report. And “every code change is reviewed by someone who did not write it”, while making sure review doesn’t block regular releases or urgent fixes.

Why it matters to a founder

Version control is also a business control. Four reasons stand out.

• Ownership. Whoever controls the repository account controls the code. If a freelancer or agency hosts it in their own account, you may struggle to get it back when the relationship ends.
• Accountability. The history shows who changed what. That helps when tracing a bug or reviewing a supplier’s work.
• Recovery. If a release breaks the site, the team can identify the commit that caused it and revert to the previous version.
• Continuity. A clear history and good commit messages make it far easier for a new developer to pick up the work.

A worked example

An example (illustration only). A small e-commerce company has one in-house developer and an agency that builds larger features.

The company creates an organisation account on a code hosting service, owned by a company email address, and invites the developer and the agency as members. The main branch is protected so nobody can change it directly. Every change goes through a pull request that needs one approval.

The agency builds a new checkout step on a branch called checkout-gift-message. They open a pull request linking to the task, the in-house developer reviews it, asks for one fix, and approves. It merges and goes live. Two days later, customers report an error on mobile. The developer looks at the history, finds the merge, and reverts it in minutes while the agency works on a fix in a new branch.

When the agency contract ends, the company removes their access. The code and its full history stay with the company.

Common mistakes

• Code living in a personal or supplier account. Set up a company-owned organisation from day one.
• Committing secrets. Passwords and API keys in code stay in the history. GitHub’s guide to removing sensitive data says the first step is to “revoke and/or rotate that secret”, because copies “may still be accessible elsewhere”, including other people’s clones and forks.
• Huge, rare commits. Small commits with clear messages are easier to review and easier to undo.
• No review. Changes that go straight to the main branch skip the cheapest quality check you have.
• Long-lived branches. A branch that drifts for weeks becomes hard to merge. Keep branches short and merge often.
• Treating version control as a backup of everything. It tracks code and text files. Databases, uploaded files and customer data need their own backups.

When version control is worth it, and when it isn’t

For any custom code, version control is basic hygiene. Insist on it even for small projects and single freelancers; setting up a repository takes minutes.

It is also useful for configuration files, infrastructure scripts and technical documentation written as plain text. Some content teams keep website copy or help articles in a repository for the same review and history benefits.

It is less useful for large binary files such as videos and design files, or for content managed inside a hosted platform like Shopify or a WordPress dashboard, where the platform keeps its own revisions. In those cases, focus on the platform’s own history and export features instead.