When your developer changes a contact form or updates your website’s theme, you need more than a message saying “All done”. It helps to know what changed, why it changed and which version is now live. Git records code changes and makes that work easier to follow, even if you never write code yourself.
You do not need to learn every command. The important things are knowing where the code lives, how changes are organised and what checks to request before publication.
The code repository: where your project lives
Git is a version control system. It tracks changes to files added to a project and lets developers compare saved states. The project and its history form a code repository, often shortened to repo.
Your developer may keep a local copy, while the team shares a remote repository on a collaboration platform. That repository is not the same as the hosting space where your website runs: updating it does not automatically mean changing the live website.
For example, a WordPress repository might contain your custom theme and bespoke plugins rather than every file in the installation. Ask your developer to explain what belongs in the repository and what is managed elsewhere.
- Keep the repository under an account or organisation controlled by your business.
- Use your own account for access rather than sharing your developer’s password.
- Enable two-factor authentication where the platform supports it.
- Agree who can invite collaborators and who can deploy changes.
A private repository restricts access to authorised people, but that does not make it an appropriate place to store passwords.
Commits explain what changed and why
In Git version control, a commit is a saved point in the project’s history. It has an identifier, a declared author, a date and a message. Together with the differences between files, these details help you follow a change. The declared author alone is not verified proof of someone’s identity.
A message such as “Fix email address validation in the quote request form” is more useful than “Updates”. Ask for each commit to group related work, so a small correction is not bundled together with a complete homepage redesign.
A version prepared for release can receive a tag, such as “v1.2.0”. A tag identifies a point in the history; it does not automatically certify that testing has taken place. Your developer should explain the numbering approach and use it consistently.
Your useful question is: “Which commit identifier or tag matches the version currently live?”. That makes it easier to connect a report such as “The form stopped sending messages after yesterday’s update” to a specific change rather than an approximate date.
Branches separate development from deployment
A branch allows changes to be developed separately from the project’s main line of work. For example, your developer could build a new services page on a branch called “services-page”, while the main branch, often called “main”, holds approved code.
A branch is not a separate website. To view the result in a browser, its code needs to be deployed to a test environment. That environment needs appropriate protection, particularly if it contains data copied from the live website.
- Describe the requirement and acceptance criteria: “The form displays a confirmation and sends the enquiry to the agreed address”.
- Your developer works on a dedicated branch.
- They open a pull request or merge request with an explanation and details of the checks performed.
- You review the result in the test environment and provide approval or feedback.
- The change is merged and deployed using the agreed process.
Working with your developer becomes clearer when you approve a result you can check, rather than just a list of files. Also agree who handles conflicts between changes: these need review, not automatic acceptance.
Keep confidential files out of the history
Passwords, private keys, access tokens, database credentials and exports containing customer information should not enter the repository. This applies to private repositories too. Local copies and collaborator access can widen the exposure.
A file called “.gitignore” can exclude certain untracked files from normal addition to Git. For example, your developer can exclude the “.env” file, database exports, archives and logs containing sensitive information. A template such as “.env.example” can document required settings using dummy values only.
Importantly, adding an ignore rule does not automatically remove a file that Git already tracks, or its earlier versions. If a password was included in a commit, deleting it from the latest version is not enough.
- Revoke or replace exposed credentials immediately.
- Ask for an assessment of access and possible consequences.
- Agree with your developer whether the history needs cleaning and existing copies need coordinating.
- Check publicly accessible server files too, including Git’s internal directory, called “.git”.
Visitors must not be able to download the Git directory. Ideally, deployment delivers only the files needed to run the website.
Code history and website backups serve different purposes
Git preserves tracked files, not the website’s complete state. For an online shop, recent orders usually live in the database. On a WordPress website, uploaded images and many settings may not be present in the code repository.
A recovery strategy needs to cover the database, uploaded files, required configuration and other project components. Agree explicitly on backup frequency, retention, storage location and responsibility. Test restoration in a separate environment rather than simply checking that archives exist.
For example, returning to the code used before an update does not automatically reverse a database structure change. Conversely, restoring an older database could remove orders received since that backup was taken. Ask for a plan before work that changes stored data.
If you are planning the project’s infrastructure, consider GazduireOnline.ro’s web hosting or WordPress hosting, depending on your platform. Discuss testing, deployment and recovery requirements separately so you can choose a suitable setup.
What to agree at your next developer meeting
Turn these ideas into a short procedure your business can access. For the next change, such as replacing a quote request form, ask to see the complete path from the initial requirement to the checks after deployment.
- Where is the repository, and who controls access?
- Which files are tracked, and where are the other components kept?
- How do you identify the live version, and who approves it?
- Where do you test, and what checks follow deployment?
- How will recovery work if the change also affects the database?
- Which access rights and instructions will you receive when the working relationship ends?
A simple request is enough: “Please link each deployment to a commit or tag and record the checks performed”. You do not need to supervise every line of code. You need access, clear explanations and a repeatable process that treats change history and website recovery as separate responsibilities.
