2 Geeks Web Design
A Practical Guide To Git And Version Control For Website Owners
A website is a working business asset, not a finished brochure that can be left untouched. Pages change, products are added, contact details need updating, and third-party services may alter the way forms, payments, analytics, or bookings work. Version control gives those changes a reliable history, making it easier to understand what happened and restore an earlier version when something goes wrong. Learn more about The Dome.
Git is the most widely used version control system for websites and software projects. You do not need to become a developer to benefit from it. A basic understanding helps you make better decisions about website maintenance, hosting, backups, security, and communication with a web design studio. This is particularly useful for Australian small businesses managing a site alongside local advertising, mobile visitors, and privacy obligations.
What Git Actually Does
Git records changes made to a collection of website files. Those files might include page templates, style sheets, images, JavaScript, configuration settings, and content written in a content management system. Each saved checkpoint is called a commit, and it includes a message explaining the work completed.
A repository is the project’s storage area for its files and history. It may exist on a developer’s computer, on a private service such as GitHub or GitLab, or in both places. The online copy is often called a remote repository. Keeping the project in a repository means a developer can compare versions, see who changed a file, and identify the point at which a problem was introduced.
Git does not automatically replace every backup system. It is designed for tracking text-based project files, rather than storing years of large video files or serving as a complete disaster recovery plan. A professional website should still have hosting backups, database backups where relevant, and a clear recovery process.
Why Version History Matters To Owners
Without version control, a website update may involve copying folders, renaming files with labels such as “final-new” and “final-new-2”, or relying on a hosting provider’s limited backup tools. That approach becomes difficult to manage when several people are involved. A proper history provides a much clearer record of what changed and why.
Version control also supports safer experiments. A developer can create a separate branch to test a redesigned navigation menu, a new booking feature, or an updated payment integration. The live website remains unchanged while the work is reviewed. If the test succeeds, it can be merged into the main version; if it fails, the branch can be discarded without damaging the public site.
This matters to Australian businesses operating across different schedules and locations. A café in Melbourne may need menu changes before a busy weekend, while a tradesperson in Perth may rely on a website form to generate leads overnight. If an update breaks mobile layouts or removes an enquiry button, a recent working version can be restored promptly rather than rebuilt from memory.
The Core Terms Worth Knowing
You will encounter a small set of Git terms when working with a developer. Knowing what they mean makes project discussions less technical and helps you recognise whether a sensible workflow is being used.
- Repository: The website files and their change history.
- Commit: A recorded checkpoint with a description of the work.
- Branch: A separate line of development used for testing or a specific task.
- Merge: The process of bringing approved changes into another branch.
A developer may also mention pulling and pushing. Pulling downloads recent changes from a remote repository to a local computer. Pushing uploads local commits to the remote repository. A clone is a complete local copy of a repository, including its history, while a pull request is a review step used before changes are merged into an important branch.
- Main branch: The approved or production-ready line of work.
- Conflict: A situation where two changes affect the same part of a file.
- Tag: A label marking a significant version, such as a launch.
- Deployment: Moving approved website files to the live hosting environment.
You do not need to run these commands yourself unless you want to learn development. The key point is that each term describes a control or checkpoint. Clear terminology helps a business owner ask whether work was tested, reviewed, backed up, and deployed safely.
A Simple Website Workflow
A practical workflow begins with a request. That might be a new service page, a change to opening hours, an accessibility improvement, or a technical update to the contact form. The developer creates a branch for the task, works on the relevant files, and records sensible commits rather than saving one enormous change at the end.
The work is then tested on a staging website or local development environment. Testing should cover desktop and mobile layouts, links, forms, images, page speed, and any connection to external systems. An Australian retailer should also check that product information, delivery details, prices, and tax wording remain accurate before the update reaches customers.
The following workflow shows how responsibility is commonly divided:
| Stage | Developer’s Work | Website Owner’s Role |
|---|---|---|
| Request | Clarify the task and identify affected files | Provide accurate content and business details |
| Development | Build the change on a separate branch | Answer questions and approve the intended outcome |
| Testing | Check functionality, display, security, and performance | Review important pages and customer journeys |
| Approval | Prepare the tested work for release | Give clear approval or request adjustments |
| Deployment | Publish the approved version and monitor it | Confirm the live result matches expectations |
| Recovery | Restore or fix the previous version if required | Report business impact and prioritise urgent issues |
For sites that collect names, phone numbers, email addresses, or booking details, the workflow should include privacy checks. Australian organisations may need to consider the Privacy Act 1988 and the Australian Privacy Principles, particularly when personal information is collected through forms, mailing lists, analytics, or online sales. Version control makes code changes traceable, but it does not make an unlawful data practice acceptable.
Hosting, Access And Security
A repository can contain sensitive material if it is poorly managed. Passwords, application programming interface keys, database credentials, private customer information, and payment settings should never be committed as ordinary website files. Developers use environment variables and protected configuration systems to keep these details outside the public code history.
Access should be limited according to each person’s role. A website owner may need administrative access to hosting, a domain registrar, analytics, and the content management system, while a contractor may only need access to the code repository. Multi-factor authentication is strongly recommended, especially because a compromised Git account can expose website files or allow unauthorised deployments.
It is also worth separating the repository from the live hosting account. A push to the main branch should not casually publish untested work. Some teams use an approval process or automated deployment pipeline, while others deploy manually after checking a release. Either approach can work if it is documented and someone knows how to reverse a faulty update.
Australian businesses should also think about where customer data and backups are stored. A local business can use an overseas hosting or repository provider, but it should understand the provider’s terms, security controls, data handling, and contractual responsibilities. The Australian Cyber Security Centre’s small-business guidance is a useful reference for broader account and backup hygiene.
Using Git Without Becoming A Developer
The easiest way for an owner to benefit from Git is to agree on a few practical rules with the person maintaining the website. Ask for a private repository, regular commits, a tested staging environment, and a backup process that covers both website files and databases. These arrangements make the project less dependent on one individual’s laptop or memory.
Request short release notes after meaningful updates. A note might say that a booking form was repaired, a new service page was published, or a security package was updated. If a future problem affects enquiries or sales, those notes help identify the likely change quickly. They are also useful when a business changes agencies or brings maintenance in-house.
A small business owner can use Git-related information in everyday decisions:
- Check that the live site has a known working version.
- Keep domain, hosting, repository, and administrator details documented.
- Ask whether a proposed change will affect forms, tracking, or integrations.
- Approve content and layout changes before they are published.
The process does not need to create unnecessary administration. For routine copy edits, an owner may work directly in a content management system while the developer handles theme and plugin code through Git. For larger rebuilds, the owner should expect a staging link, a review period, and a clearly identified release version.
A few habits provide dependable protection:
- Use separate logins instead of sharing one administrator password.
- Enable multi-factor authentication on key services.
- Keep at least one backup independent of the live hosting account.
- Review old users, integrations, and repository permissions regularly.
Recovering From Mistakes With Confidence
Every website team eventually encounters a faulty update. A plugin may conflict with a custom theme, a stylesheet may make a page unreadable on mobile, or a form may stop sending messages after a hosting change. Version control gives the developer a map of recent changes and several possible recovery points.
Recovery is more than pressing an undo button. The team needs to know whether the issue is in the code, database, hosting configuration, DNS, or an external service. Rolling back website files may not reverse a database change, such as deleted orders or edited customer records. For that reason, file versioning and database backups should be managed together.
Before a release, a developer may create a tag identifying the version being published. If the update causes a serious problem, the team can return to the previous tagged version while investigating. This is especially valuable for businesses that cannot afford a long outage, such as accommodation providers, medical practices, event companies, and online retailers.
A written recovery plan should state who can approve a rollback, where backups are stored, how the live site is restored, and how customers are informed if an incident affects orders or personal information. For a business in Sydney, Brisbane, Adelaide, or a regional town, the principles are the same: preserve evidence, restore service carefully, and avoid making rushed changes that obscure the original fault.