When most people hear the word GitHub, they immediately think of programmers.
Code. Software. Developers staring at several monitors filled with mysterious text.
And yes, GitHub is one of the most important tools used by software developers. But that is only part of the story.
At its heart, GitHub helps solve a universal problem: how do I keep track of what I created, what I changed, and how do I get an older version back when something goes wrong?
That is a problem programmers have. But it is also a problem writers have. Designers have it. Business owners have it. Students have it.
Anyone who has ever created files called book-final.docx, book-final-new.docx, book-final-new2.docx and book-final-REALLY-FINAL.docx already understands the problem Git was created to solve.
The basic idea
GitHub works with a technology called Git. The distinction is useful.
Git is the version-control system. GitHub is an online service where Git projects can be stored, shared and managed.
You can work completely locally on your own computer using Git without putting anything online. You can also connect that local project to GitHub, giving you an online copy as well.
Imagine that you are writing a book. You write Chapter 1 on Monday. On Tuesday, you change half of it. On Wednesday, you decide Tuesday's version was actually worse.
With ordinary files, you either need multiple copies or you may have permanently overwritten the version you preferred. With Git, you can save important stages of your work. These saved stages are called commits.
A commit is a meaningful snapshot
You might save one as Finished first draft of Chapter 1, then later Rewrote restaurant scene, and then Changed dialogue between Auguste and Marcel.
Months later you can still see those changes, compare them and return to an earlier version.
Think of it as a time machine for your files
That is probably the easiest way to explain Git. It gives your project a history.
For a writer, that can mean the history of a manuscript. For a website owner, it can mean knowing exactly when a page changed. For a business, it can mean keeping versions of procedures, documentation or templates.
Git works especially well with text because it can show precisely which lines were added, removed or changed.
Local and online are not the same thing
Suppose I have a website project on my laptop. That is my local repository.
I can create twenty Git commits without connecting to the internet. Nothing needs to leave my computer.
But I can also connect that repository to GitHub and push my changes. Now another copy exists online. If my laptop dies, the project is still on GitHub. If I buy another computer, I can clone it and continue working.
Before you push, ask one question: Should this material be public, private, or not online at all?
Public and private: this matters
When you create a GitHub repository, one of the most important decisions is whether it should be public or private.
A public repository can be viewed by anyone on the internet. A private repository is restricted to accounts that have been granted access.
If you are publishing open-source software or material you deliberately want others to see, public may be exactly right. If you are writing an unpublished book, developing a commercial website or keeping internal business material, private is usually the more sensible starting point.
How private is private?
This is where the word private deserves explanation.
A private GitHub repository is not publicly browsable. But your files are still stored on GitHub's infrastructure. GitHub describes private repository content as confidential, while its terms allow limited access in circumstances such as providing the service, security and support, legal obligations or with your consent.
So a private repository is best understood as access-controlled cloud storage with version history. It is not the same as a file that exists only on an encrypted computer disconnected from the internet.
For ordinary development, writing and business projects, private repositories are extremely useful. But if something is so sensitive that no outside service should ever possess a copy, do not put it in a normal cloud repository.
GitHub's current explanations are available in its repository documentation and Terms of Service.
Other people can make a private repository less private
You can invite collaborators to a private repository. Depending on their permissions, they may be able to read, copy or modify its contents.
And once someone has legitimately cloned a repository, removing their access later cannot erase the copy already sitting on their computer.
The rule is therefore straightforward: only give access to people who actually need it, and review that access occasionally.
Never put passwords in Git
This may be the most important practical security rule in the article.
Do not deliberately commit passwords, API keys, private encryption keys, database credentials or other secrets — even to a private repository.
Git remembers history. If you commit a secret and delete it five minutes later, the earlier commit can still contain it.
DATABASE_PASSWORD=MySecretPassword123
If a real credential has been committed, the safest approach is normally to rotate or revoke that credential rather than assuming deletion fixed the problem.
Use .gitignore
A .gitignore file tells Git which files it should not track.
A website project might have a local .env file containing configuration or credentials. You generally do not want that file in Git, so your .gitignore might contain:
.env
The same concept applies outside programming. A writer can exclude exports or temporary files. A designer can exclude caches and generated files.
Not every file in your project folder belongs in version control.
GitHub can help detect secrets
GitHub offers security features such as secret scanning and push protection that can detect certain credentials before or after they are committed. Availability depends on repository type, account and configuration.
These tools are useful safety nets, but they should supplement good habits rather than replace them.
Public once can mean public forever
If confidential material is accidentally made public, changing the repository back to private does not guarantee that no one copied it while it was public.
The same applies to exposed API keys and passwords. Removing the file does not make an exposed secret trustworthy again. Rotate it.
GitHub is not the same as a backup
GitHub gives you another copy of your project and a detailed development history. That is valuable, but I would not make it the only backup of important work.
Computer
↓
Local Git history
↓
Private GitHub repository
↓
Separate backup
A backup and version control solve related but different problems. A backup can give you yesterday's folder. Git can tell you exactly what changed yesterday.
A very useful tool for writers
Writers in particular could make much more use of Git.
book/
├── notes/
├── research/
├── characters/
├── chapters/
│ ├── 01-paris.md
│ ├── 02-new-york.md
│ ├── 03-pennsylvania.md
│ └── 04-ohio.md
└── outline.md
Each chapter can be written in Markdown or plain text, and every meaningful revision committed. There is no need to create Chapter4-final-v7.docx. Git remembers the history for you.
Experiment safely with branches
A branch lets you experiment without destroying the version that already works.
A writer could have branches called alternative-ending, shorter-introduction or publisher-edits. If an experiment works, keep it. If it does not, the original is still there.
GitHub shows what changed
If someone changes a paragraph, GitHub can show the old and new versions side by side. Added and removed text is visible.
That can be much more useful than receiving an email saying: “I changed a few things.”
Automatic saving needs a little explanation
Git does not automatically know which version is meaningful. Usually, you decide when to make a commit.
That is a feature, not a weakness. Your editor can save constantly while Git marks the moments in the project's history that actually matter.
AI makes version history even more useful
AI tools can now change many files — or several sections of a manuscript — in seconds. That makes version history more important, not less.
Before allowing an AI tool to perform large changes, I want to know that I can always go back.
There is also a security consideration. An AI tool with repository access may be able to read files in that repository. Understand what permissions you are granting, especially with commercial work, customer information or unpublished writing.
Protect the GitHub account itself
A private repository is only as secure as the account controlling it.
- Use a unique password.
- Enable two-factor authentication.
- Protect your recovery methods.
- Review authorised applications and tokens.
- Remove collaborators who no longer need access.
- Give people and applications the minimum permissions they require.
You don't have to become a programmer
You do not need to learn programming simply because you use Git.
There are graphical Git applications, integrations in editors such as Visual Studio Code, and AI assistants that can perform many Git operations for you.
Understanding the concept is more important than memorising commands.
The basic workflow
Create → save → commit → continue.
And, when an online copy is useful: push.
But before pushing, decide whether the work should be public, private, or offline.
Your work deserves a history
We create more digital material than ever: books, websites, business documents, research, designs and ideas.
Yet surprisingly often our version-management system is still filenames containing words such as “new”, “final” and “final2”.
There is a better way.
Git started in software development. It does not have to stay there.
If something is important enough to create, it may also be important enough to preserve its history. Just make sure you understand who can see that history.