GitHub and GitLab: a shelf for code and its history
GitHub and GitLab are examples of services that hold code repositories. A repository is an organized project folder with version history — a record of saved changes. Git is the tool that tracks that history. A saved change is often called a commit; it can help someone see what changed or return to an earlier version. When a builder supports a connection, a repository can hold an off-platform copy of the code, meaning a copy outside the builder itself. That helps with code access and handoff, but only for the files and changes actually included. A repository does not automatically contain a running database, uploaded files stored elsewhere, payment records, or private service settings. You do not need GitHub or GitLab just to have a website.
A code copy is not automatically a full backup
A backup is a separate usable copy you can recover from if something is lost. A connected repository can help protect code, but changes and accidental deletions may also sync to it. Understand its history and recovery options; do not assume syncing means every part of your business is backed up. Keep private keys, passwords, and secrets — credentials that grant service access — out of repositories, even private ones. A public repository can be read by anyone. Store credentials securely in a password manager or the service's protected settings. If a secret was exposed, deleting it from the latest file is not enough because history may retain it: replace or revoke it and get help cleaning up. Never put payment card details into code, a repository, or your own backup files.
GitHub Pages: simple static pages, with important limits
A static site serves prepared page files, such as HTML, styles, and images, without its own server-side application doing work for each visit. GitHub Pages can publish this kind of site from a repository. It does not run a normal database-driven application or provide a complete checkout and order system. Its published use limits say it is not intended or allowed as free hosting for running an online business, ecommerce site, or commercial software service, and it should not handle sensitive transactions. Do not choose it as the home for your store or payment handling. For an eligible simple informational or learning project, review the current limits and terms first. A separate outside form or service remains a separate service, not a built-in Pages database.
Example: a Shopify store and a Lovable-built website
Imagine a vintage-doll seller using Shopify. Her theme, products, stock, and orders are managed through the store, with a supported payment provider configured separately in its settings. She does not need GitHub to run a normal theme-based store. She keeps supported product and other data exports, theme copies, original photos, and her domain records; a theme download is not a complete backup of the whole store. Now imagine a home organizer using Lovable for services and a contact page. She can publish through Lovable without arranging another host. If she wants an off-platform code copy, Lovable supports GitHub sync. If she later deploys that code to a suitable outside host, she must follow its build instructions and test it there. If she adds saved booking requests, the database and any uploaded files need their own protection and migration plan; a GitHub copy does not automatically move them. These are teaching examples, not promises that every feature transfers.
Make a separate backup plan for what matters
List the code, database records, uploaded files, original photos, domain and DNS settings, store data, and any other essential business records. DNS settings are the directions sending visitors and email to the right services. For each item, write where it lives, who controls access, whether its provider supports exports or backups, and how you would restore it. A database export and a file-storage backup are different jobs; check both. Some hosted platforms only export selected data, and copying files may not preserve every feature. Keep supported copies outside the original platform when permitted, protect them with restricted access and encryption where appropriate, and choose how often to update them. Do not download unnecessary customer data or keep it indefinitely. Keep a secure account and recovery record separately, without publishing secrets. Try a recovery with sample data in a safe test location. An unreadable file or a copy you cannot restore is not a dependable recovery plan.
A Lovable code copy and deployment are separate steps
Lovable offers a GitHub connection for project code and its history. Confirm current connection options and access before relying on them. Check that the latest project files actually reached the repository and that its visibility is appropriate. Publishing through Lovable and deploying elsewhere are different choices. An outside host must support the generated project and its build settings. Database records, uploaded files, service configuration and secure credentials need separate setup or transfer. Test the outside deployment with sample information; an exported folder is not proof that every app feature moved.
A real-world example
A braider's service site stops showing uploaded style photos after a change. A code repository may recover the page layout, but not photos kept in a separate storage service. Her separate original-photo copy and record of where the files belong help her restore them. If the appointment list also disappeared, she would need the booking service's supported recovery or a database backup, not just the page code. A careful recovery plan asks 'what would I need to open again?' rather than stopping at 'I have my code.' This is an illustrative situation, not an account of a P.E.A.C.E. learner.
Steps to take
- Decide whether code access matters for your path; a normal Shopify or builder site may not need a repository.
- If using GitHub or GitLab, check ownership, visibility and the latest saved code.
- Keep passwords, private keys and card details out of files and version history.
- List separate supported copies for code, database, uploads, domain settings and essential business records.
- Record how to restore each copy, how often to update it, and who has secure access.
- Practice recovery with sample information and get help for data migration or exposed secrets.
My github, code & backups check
This checklist is optional and not saved. Copy it to keep a personal note. Do not enter sensitive information.
Go deeper in related modules
Not sure what a word means? Check Business Words Made Simple.
Official provider guides
Independent resources, not P.E.A.C.E. partners or recommendations. Check current terms before buying.
- GitHub: repository copies and backups (opens in a new tab)
Understand repository backups and what other data needs separate protection.
- GitLab: repositories (opens in a new tab)
Code storage and version history, not an automatic backup of every connected service.
- GitHub Pages: usage limits (opens in a new tab)
Review static-site limits and restrictions on ecommerce, business hosting, and sensitive transactions.
- Lovable: GitHub connection (opens in a new tab)
Keep an off-platform code copy; databases, storage, and credentials need separate plans.
- Lovable: hosting and ownership (opens in a new tab)
Options and responsibilities when publishing or moving a project.