Git

Git is version control — it tracks every change made to a site’s code over time. You may never see it directly, but it’s what makes changes safe, reversible, and traceable instead of a black box.

Not necessarily — Git is part of how development work is tracked and managed behind the scenes. It’s rarely something a client needs to interact with directly.

Every change is recorded, so if something needs to be rolled back or a bug needs to be traced to when it was introduced, there’s an actual history to work from — not guesswork.

Related but not identical — Git tracks code changes over time; backups protect your database and files against loss. A solid setup uses both, since they cover different risks.

No — it’s a standard, lightweight part of a professional workflow, not overhead. If anything, it speeds things up by making changes safer to make in the first place.

With version control in place, reverting to the last known-good state is straightforward rather than a scramble — one of the main practical reasons to use it.

Yes — the code itself is yours as part of the engagement; Git is just the tool used to track and manage changes to it responsibly.

Yes — even a WordPress site with custom theme code benefits from having that code under version control, separate from whatever the hosting environment or WordPress core itself is doing.

Yes — changes can be developed and tested in isolation before being applied to the live site, which is a meaningfully safer workflow than editing a production site directly.

Not at all — it’s genuinely useful on a project of any size, including a single-developer engagement, purely for the safety net and history it provides.