Publishing a site with GitHub and Netlify: the benefits over old-school FTP

For years publishing a site meant the same thing: opening an FTP program, dragging files onto a server and hoping you had not overwritten the wrong one. It still works, and many sites live that way. But since I started working with GitHub and Netlify, the way I put changes online has changed for me, and for the clients who see the results. In this article I tell you the concrete benefits of this flow, without assuming you know what Git is.

How it works, briefly

The site's code lives in a repository on GitHub, which keeps track of every change: who made it, when and why. Netlify is connected to that repository: when there is something new, it builds the site by itself and publishes it on a network of servers spread around the world. I write the code, send it to GitHub, and Netlify does the rest. No files dragged by hand, no steps that can be forgotten.

The benefits that really matter

An online preview for every change

This is the benefit clients appreciate most. Every time I work on a change, Netlify generates a test address, separate from the real site, where you see the working result, on your phone too. You can check it, send it to a colleague, point out what to change. Only when everything is approved does the change go live. With the old method you worked in a separately built test environment, often neglected, or fixed things directly on the public site with visitors looking on.

You can always go back

If a publication contains a mistake, putting the previous version back online takes one click: Netlify keeps past versions. And on GitHub every change to the code is recorded and can be undone. The fear of "touching something and breaking everything" shrinks a lot, because there is always a way back. It is the difference between working with a safety net and without.

The site changes all at once, never halfway

With FTP, while files are uploading the site can sit for a few moments in a mixed state: partly old, partly new. With Netlify the new version is prepared in full and replaces the old one only when ready. Visitors see one version or the other, never a piece of each.

A history of everything

Every change has a date, an author and a description. If in six months you wonder why a page changed, the answer is there. For an agency with several people on the same project, this history avoids overlaps and arguments about who touched what.

Speed and security

A site prepared in advance and served from a network of servers close to the visitor is usually very fast, and has fewer exposed parts to attack: no database to breach and no plugins to update in a hurry. This does not make the site immune to everything, but it removes a good part of the typical problems of dynamic sites, which I also describe in the article on moving from WordPress to Nuxt.

Forms, redirects and HTTPS without a server to manage

The HTTPS certificate turns on and renews itself. Contact forms can be collected with Netlify Forms, without writing and maintaining a program on the server. Redirects, such as those needed after a site migration, are set in a file of the project, so they travel with the code and do not depend on a panel someone might change by mistake.

More people, fewer hiccups

The same tools let several people work on the same site without stepping on each other's toes, and review each other's work before it goes online. For an agency handing me part of a project, it means I can slot into its flow without changing its habits.

How I work

My method is simple. For each topic I open a separate branch, which is like a working copy of the site. When it is ready I propose it on GitHub, and Netlify gives me the preview to show you. Only after your approval is the branch merged into the main one, and the site updates by itself. I never touch the main branch directly: everything goes through the preview. That way every change has a clear history and can be undone.

When it is not the right solution

In fairness, there are cases where this flow is not the best choice:

• Sites that change constantly and are edited by many non-technical people, unless a CMS with a comfortable panel is connected.
• Applications with lots of real-time data, which need an always-on server and database: there a different architecture is needed, where Netlify can still host the visible part.
• A site that already runs very well on traditional hosting and has no problems with speed, security or maintenance. Changing for the sake of changing brings nothing.

If you want to understand which infrastructure fits your project, there is a broader comparison in the guide to shared hosting, VPS and cloud.

What changes for you, in practice

• More peace of mind: you see every change before it is public.
• Fewer mistakes: publishing is automatic and repeatable, not a manual ritual.
• Quick remedies: if something goes wrong, you return to the previous version in an instant.
• Often lower costs: for many sites the free plan is enough, and there is no server to administer.

Why entrust it to me

I have been programming since 1999, with more than 300 projects delivered and about 30 agencies as an external developer. This very site is built with Nuxt and published with GitHub and Netlify, so I am talking about a method I use every day and not an idea read somewhere. I set up the publishing flow, the previews and the redirects, and leave you or your agency a clear system to use.

If you want to know whether this way of publishing suits your site, write to me: a chat of about 20 minutes, no strings attached, then a written, free proposal. The service is in Hosting and infrastructure.