Cloud & DevOps
Git
The version control behind every line of code we ship.
Git is the open-source version control system that records every change to a project's code, who made it and why. It lets us branch off to build a feature safely, review the change, then merge it back without losing work or breaking what's live. HDC uses Git on every build, so nothing we ship is ever a one-way, unrecoverable edit.
Where it shines
- Records a complete, timestamped history of every change, nothing is ever truly lost
- Branching lets us build and test features in isolation from the live site
- Roll back to any previous working state in seconds if something goes wrong
- Multiple people can work on the same project without overwriting each other
- Each commit explains what changed and why, so the project documents itself
- The de facto standard, it underpins GitHub, CI/CD and modern deployment
Trade-offs to weigh
- A genuine learning curve, branching and merge conflicts confuse newcomers
- Powerful, low-level commands can cause damage if used carelessly
- Not designed for large binary files like video or raw design assets
What Git is
Git is an open-source version control system, created in 2005, that records the complete history of a software project. Every time we save a meaningful change, a “commit”, Git stores what changed, when, and a short note on why. The result is a full, timestamped timeline of how a project came to be, with the ability to revisit or restore any point in it.
Two ideas make Git powerful. The first is branching: you can split off a copy of the project to work on a new feature in isolation, leaving the main, known-good version untouched, then merge your work back in once it’s ready. The second is distribution: every copy of a Git repository contains the entire history, so the project isn’t dependent on a single machine. Together these turn editing code from a risky, one-way activity into something safe, traceable and reversible.
How HDC uses Git
Git sits under every single thing we build, it’s not optional on our projects. In practice:
- We start each piece of work on its own branch, so a new feature or redesign is built and tested without ever disturbing the live site.
- We make small, well-described commits, so the history reads as a clear record of what changed and why, invaluable when revisiting a project months later.
- We host our repositories on GitHub, where changes are reviewed before they’re accepted, and where pushes trigger automated builds and deploys.
- We rely on Git’s ability to roll back, if a change ever caused a problem, returning to the last working state is a matter of seconds, not a rebuild.
Why we apply it
For clients, Git is the reason changes to their site are never a gamble. Because every version is preserved and any state is recoverable, we can experiment, improve and fix with confidence, there’s always a way back. A bad deploy isn’t a crisis; it’s a rollback.
It also keeps a project healthy over time. The history explains how the site evolved, which makes future work faster and cheaper, and branching means several people can improve the site at once without tripping over each other. Quietly, Git protects both the work and the investment behind it.
How Git fits our stack
Git is the connective tissue of our workflow. The Astro codebases we build are versioned in Git; Prettier keeps the formatting consistent so commits stay clean and diffs readable; the Dockerfiles that define our build environments are tracked in Git alongside the code. From there, GitHub hosts those repositories and adds review on top, and a push to the main branch triggers Cloudflare to build and deploy. Every other tool in our DevOps stack assumes Git underneath, it’s the layer everything else is built on.
When Git isn’t the right tool
Git is right for code in essentially every case, so the honest caveat is about what Git is not for. It’s poor at handling large binary files, raw video, big design source files, high-resolution image libraries, where it bloats and slows down; those belong in proper asset storage, not a Git repository. And Git is a tool for managing code, not a content management system: when a client needs to edit page text or publish blog posts themselves, we give them a CMS, not a Git workflow. For everything that is code, though, Git is non-negotiable.
Worked example
Trying a redesign without risking the live site
Picture a client who wants to test a bolder homepage hero but can't afford for the live site to wobble while we experiment. With Git, we create a separate branch and build the new hero there, completely isolated from the version your customers see. We can preview it, refine it and, if it doesn't land, simply discard the branch, the live site was never touched. When it's right, the change merges in with a full record of exactly what was altered. If anything ever misbehaved afterwards, we could roll back to the previous working state in seconds. That safety net is why no change we make is ever a gamble. (Illustrative, every build is scoped to your goals.)
Better together
How Git fits with the rest of our stack
Git: your questions answered
What is Git used for?
Git is version control: it tracks every change made to a project's files over time, keeping a full history of what changed, when and by whom. That lets developers work on new features safely, collaborate without overwriting each other, and undo mistakes by returning to any earlier point, which is why it underpins almost all modern software development.
What's the difference between Git and GitHub?
Git is the version control tool itself, it runs on a computer and records the history of a project. GitHub is an online platform that hosts Git repositories and adds collaboration on top: code review, issue tracking and automated deployment. Put simply, Git does the version control; GitHub is where we store it and work on it as a team.
Does using Git mean my project is backed up?
In effect, yes, and more than that. Because Git keeps the full history and we host it on GitHub, the code exists in multiple places and every past version is recoverable, not just the latest. So beyond a simple backup, we can return your project to any previous working state, which an ordinary file backup can't do.
Why does HDC use Git?
Because it makes every change we ship safe and reversible. Git lets us branch off to build and test work in isolation, review it before it goes live, and roll back instantly if needed, so no edit is ever a one-way risk to your site. It also keeps a clear record of what changed and why, which keeps your project maintainable for the long term.
Can multiple developers work on my site at once with Git?
Yes, that's one of Git's core strengths. Each person can work on their own branch and Git merges the changes together intelligently, flagging the rare cases where two edits overlap so they can be resolved deliberately. Nobody's work silently overwrites anybody else's.
Is Git only for big software teams?
Not at all. The same safety and history that help large teams are just as valuable on a single small business site. We use Git on every build, regardless of size, because the ability to undo, branch and track changes protects your project whether one person or several are working on it.
Want Git working for your business?
Tell us what you're trying to achieve, we'll show you, honestly, whether it's the right tool and how we'd apply it.
Enquire now