GitHub Source Control and Website Deployment
Your code, your repository, your history, from the first commit.
Every LGTCS website lives in a private GitHub repository owned by you, with full history, reviewable changes and automatic deployment.
Fixed-price packages from $300. No retainer, no licence fees.
Short answer
GitHub stores the code for your website and keeps a record of every change ever made to it. LGTCS creates a private repository under your organisation's account, not ours, and works inside it. Every change is a reviewable entry with a date, an author and a reason. Merging a change deploys the site automatically. Because the repository is yours, you can hand it to any developer at any time, and nothing about your website has to be recovered from us first.
docs.github.com- Repository owned by your organisation
- PrivateRepository owned by your organisation
- Recorded, attributed and reversible
- Every changeRecorded, attributed and reversible
- Merging publishes the site
- AutomaticMerging publishes the site
What GitHub actually is
GitHub is where the code lives. Every website LGTCS builds goes into a private repository created under your organisation's account from the first day, with us added as collaborators. That ordering matters more than it sounds. It is the difference between owning your website and renting access to it.
The repository keeps a complete history. Every change is a commit: what changed, who changed it, when, and why. If something breaks, we can see exactly which change caused it and reverse that one change rather than guessing. A site that has been running for three years still has an honest record of how it got that way.
It is also the deployment mechanism. The hosting platform watches the repository, and merging an approved change into the main branch builds and publishes the site. There is no separate upload step, no file dragged onto a server by hand, and no chance of the live site quietly drifting away from the code that is supposed to describe it.
A repository you own versus code held by your agency
This is the single question that decides how much leverage you have over your own website. Ask any prospective developer where the code will live and whose name is on the account. The answer tells you what happens the day you want to leave.
| Aspect | Private repository in your name | Code held by the agency, or uploaded by hand |
|---|---|---|
| Who owns the account | Your organisation | The agency |
| Getting your code back | Already yours, nothing to request | Depends on their goodwill and their notice period |
| History of changes | Complete and attributed | Often none at all |
| Undoing a bad change | Revert one commit | Restore a backup, if one exists |
| Changing developer | Add them, remove us | A migration project |
| Knowing what is live | The main branch, always | Whatever was last uploaded, probably |
To be fair to the alternative: if you never intend to change developer and never need to audit a change, hand-uploaded files will serve a small site adequately for years. The cost is invisible right up until the moment you need it, which is exactly why we do not build that way.
How LGTCS uses GitHub on client projects
Specific decisions we make on real builds, not a feature list copied from the documentation.
The repository is created under your organisation
Not under an LGTCS account with a promise to transfer it later. Yours from the first commit, with us added as collaborators. Transfers get forgotten, delayed or contested, so we remove the possibility by never needing one.
Branches keep work away from the live site
A redesign, a new section or an experiment happens on its own branch. The live site is untouched until that work is reviewed and merged, so there is no window where visitors see something half-finished.
Pull requests make changes reviewable
Each change arrives as a pull request with a description and a preview URL. You can look at the actual page before it goes live and approve it there. Sign-off happens on the thing itself rather than on a description of it.
Merging publishes, automatically
The hosting platform is connected to the repository. An approved merge into the main branch triggers a build and a deploy. Nobody uploads anything, so nobody can upload the wrong thing.
Rolling back is one action
If a change causes a problem, reverting that commit and merging restores the previous state within a minute or two. Recovery does not depend on finding a backup or on anybody being awake.
Secrets stay out of the code
API keys and credentials are stored as encrypted secrets in the hosting platform, never committed to the repository. A key that reaches a repository has to be treated as compromised, so we keep them out from the start.
Thinking about a GitHub build?
Send us the pages you need and your deadline. We will tell you which package covers it and what it costs, usually the same day.
How a GitHub project runs, step by step
The same sequence on every project, whether it is a single landing page or a full platform.
- 1
Create the repository under your account
A private repository owned by your organisation. If you do not have a GitHub organisation yet, we help you set one up. It is free for private repositories.
- 2
Add LGTCS as collaborators
We are given the access we need to do the work and nothing beyond it. That access is yours to revoke at any moment, without the site being affected.
- 3
Connect it to hosting
The repository is linked to Cloudflare Pages or Vercel with the build command and output directory configured, so deployment is automatic from that point onward.
- 4
Work in branches, review in pull requests
Every piece of work gets a branch and a preview URL. You see changes on a real page before they reach visitors.
- 5
Document the project in the repository
A README explaining how to run the site locally, how it deploys, and what each environment variable is for. Written for a developer who has never met us.
- 6
Hand over admin ownership
At the end, you hold the owner role. We stay as collaborators only if you want continued support, and we are removed cleanly if you do not.
What you receive
Everything below is handed over at the end of the project. Nothing is held back as leverage to keep you on a retainer.
- Private GitHub repository owned by your organisation
- Complete commit history from the first day of the project
- Branch and pull-request workflow with preview URLs
- Automatic deployment to production on merge
- One-action rollback to any previous state
- Secrets stored in the hosting platform, never in the repository
- README covering local setup, deployment and environment variables
- Branch protection on the main branch where you want it
- Owner-level access held by your organisation
- Clean removal of LGTCS access on request, with no effect on the site
Projects we build with GitHub
The kinds of work this part of the stack is genuinely the right answer for.
Organisations that have been locked out before
If a previous developer held your website hostage, or simply stopped replying, owning the repository is the structural fix rather than a promise that it will not happen again.
Teams with more than one person touching the site
Branches and pull requests let two people work at once without overwriting each other, which hand-uploaded files cannot do safely.
Boards and funders that ask about continuity
A documented repository in the organisation's own name is a straightforward answer to the question of what happens if a key supplier disappears.
Anyone planning to change developer eventually
Handover becomes an access change rather than a project. The next developer reads the history and continues.
The business reason we chose it
Technology decisions only matter if they change something you can measure.
You are never locked in
The code is already in your account. Changing developer means adding one collaborator and removing another.
Mistakes are cheap
Anything that goes wrong can be reversed to a known-good state in minutes, because every state the site has ever been in is still recorded.
The live site always matches the code
Because deployment comes from the repository, there is no drift between what is published and what is written down.
In our packages
Included on every package, from Launch upward. Branch protection and multi-reviewer workflows are configured where your team needs them.
See all four packages side by sideGitHub questions we get asked
The things clients actually ask before signing, answered plainly.
Do I actually own the code LGTCS writes?
Yes, completely. The repository is created under your organisation's GitHub account at the start of the project, not transferred at the end, and you hold the owner role. LGTCS are collaborators you can remove at any time without the website being affected. There is no licence, no escrow arrangement and nothing to buy out.
Does a private GitHub repository cost anything?
Private repositories are free on GitHub's free plan, which covers what a website project needs. Paid plans add features around larger teams and advanced controls, and most organisations we build for never need them. If your situation would benefit from a paid plan, LGTCS will say so and explain why rather than letting you find out later.
What if I have no technical staff to manage it?
That is the normal case and it is fine. You do not need to use GitHub day to day. It sits underneath, holding the code and publishing the site. Its value to you is ownership and recoverability, both of which are there whether or not anyone on your team ever opens it. When you do need it, any developer will know exactly what to do with it.
Can I see what changed on my website and when?
Yes. Every change is recorded with a date, an author and a description, and you can read that history at any time. If a page changed three months ago and nobody can remember why, the answer is written down rather than reconstructed from memory.
What happens if LGTCS stops trading?
Your website keeps running and your code stays where it is, because neither depends on us. The repository is in your account, the hosting is in your account, and the domain is in your account. Another developer can pick it up by being added as a collaborator. We build this way specifically so that our disappearance would be an inconvenience rather than a crisis.
Can you work with a repository I already have?
Yes. If your site is already in GitHub, LGTCS can be added as collaborators and work in your existing repository, keeping the history you already have. Send LGTCS repository access and we will read through it first and tell you what state it is in, what we would change, and what that would cost, before any work starts.
Is my code visible to the public on GitHub?
No. The repository is private, which means only accounts you explicitly grant access to can see it. Public repositories are a deliberate choice for open-source projects and are not how client websites are stored.
The rest of the stack
Every tool we use has to work with the others. These are the closest neighbours.
Ready to build on GitHub?
Tell us what the website needs to do. We will tell you which package covers it, what it costs, and when it goes live.