Chapter 1 of 10 · Git and GitHub for Beginners — Complete Free Tutorial
Introduction to Version Control
Welcome to the Git and GitHub for Beginners tutorial series on Scriptly. Over ten short chapters you will go from an empty folder to pushing branches, opening pull requests and working safely alongside other people. This first chapter explains what version control actually is, why nearly every professional developer relies on it, and how Git differs from the tools and habits it replaced.
What is version control?
Version control is a system that records changes to your files over time so you can recall any earlier snapshot on demand. Instead of saving copies by hand, you ask Git to take a commit: a permanent, labelled picture of every tracked file at that exact moment. The practical benefits show up immediately:
- Undo — if a change breaks the project, restore the previous snapshot in seconds.
- Compare — see exactly which lines changed between two moments, and who changed them.
- Collaborate — several people can edit one project without overwriting each other's work.
- Experiment — copy the project onto a branch, try a bold idea, and delete it if it fails while your stable code stays untouched.
Why copy-based backups fail
If you have ever kept files named home-page-FINAL.html, home-page-FINAL-v2.html and home-page-FINAL-v2-fixed.html, you were doing version control by hand. That habit quietly falls apart as a project grows:
| Approach | What goes wrong | What version control does instead |
|---|---|---|
| Copying files by hand | Nobody remembers which copy is current, and copies drift apart | One history with one clearly labelled current state |
| Zip archives of the folder | You must remember to make them, and you cannot see what changed inside | Snapshots on demand that you can diff line by line |
| Cloud sync folders | Versions belong to individual files, not to the whole project at one moment | A single commit captures every file together |
| “I will just be careful” | One accidental overwrite is permanent | Old commits stay reachable until you deliberately prune them |
Commits: the atoms of history
A commit is Git's core unit: a complete snapshot of every tracked file plus metadata that answers the questions a team asks later. Snapshots chain together — each commit points back to the one before it — so history becomes a readable storyline rather than a pile of files.
| Metadata | Example | Why it matters |
|---|---|---|
| Identifier | a1b2c3d | A short hash you can type to refer to that exact snapshot |
| Author | Sara Mehta <sara@example.com> | Shows who made the change |
| Timestamp | Sat Oct 3 09:14 2026 +0530 | Shows when the change was recorded |
| Message | Add homepage and update menu prices | Explains why the change happened |
| Parent | 9f8e7d6 | The previous snapshot, which makes the chain |
Distributed: your laptop holds the full history
Older centralised systems kept one master server; if it was offline, nobody could commit. Git is distributed — every clone carries the complete history. You commit locally, instantly and without a connection, then share those commits by pushing to a remote such as GitHub. That design changes how teams work:
| Question | Centralised tools (e.g. SVN) | Distributed tools (Git) |
|---|---|---|
| Can I commit offline? | No — the server must be reachable | Yes — commits are local until you push |
| How fast is creating a branch? | Slow, often server-side | Instant — a branch is a tiny pointer |
| How many backups exist? | One server | Every clone, including yours |
Git is not GitHub
These two names get swapped constantly, so fix the distinction now. Git is the command-line tool installed on your computer that tracks snapshots. GitHub is a website that hosts Git repositories and adds teamwork features on top: issues, pull requests, code review and automation through GitHub Actions. GitLab and Bitbucket play a similar hosting role. You could use Git daily for years without ever opening a browser — GitHub simply makes sharing far easier.
git --versionExpected output:
git version 2.51.0git help -aExpected output:
Main porcelain commands
add Add file contents to the index
branch List, create, or delete branches
checkout Switch branches or restore working tree files
clone Clone a repository into a new directory
commit Record changes to the repository
diff Show changes between commits, commit and working tree
init Create an empty Git repository or reinitialize an existing one
log Show commit logs
merge Join two or more development histories together
push Update remote refs along with associated objects
status Show the working tree statusThe list is reassuring: almost everything you will learn in this series comes from those dozen commands. Master them and the rest of Git is detail.
Common mistakes
- Assuming Git is a backup — the
.gitfolder lives inside your project, so a lost laptop takes the history with it. Pushing to a remote is the real backup. - Thinking GitHub is Git — you can learn and use Git with no account at all; the hosting service is optional.
- Waiting until the project is “finished” to start tracking — history is only useful when it exists from day one.
- Committing generated files — folders like
node_modulesanddistbloat history, and secret files such as.envcan leak credentials. - Keeping manual copy folders “just in case” — two sources of truth mean nobody knows which folder is real.
Practice checklist
- Install Git (next chapter shows how) and run
git --versionuntil you see a version number. - Run
git statusinside any project folder and read the “not a git repository” error — you will fix it in the next chapter. - Pick two files you edited this week and write one sentence describing the older version you would want back.
- Open any public repository on GitHub, click its commit list, and identify the author, message and date on one commit.
- Explain the difference between Git and GitHub out loud in a single sentence.
What's next?
With the vocabulary in place, it is time to install the tool and create something real. Continue to Installing Git and Initializing a Repository, or browse the tutorials index to see what other tracks Scriptly offers.
Frequently Asked Questions
Git is a distributed version control system: it records snapshots of your project over time, lets you jump back to any point, branch off to try ideas safely, and merge other people's work. It is the industry standard — nearly every developer job assumes basic Git fluency — and it is the best insurance you can have against lost or broken code.
Git is the tool that runs on your machine and stores history locally; it works fully offline. GitHub is one of many websites (GitLab, Bitbucket) that hosts Git repositories in the cloud and adds collaboration features: pull requests, code review, issues and CI. You can use Git forever without GitHub — GitHub needs Git to be useful.
A repository (repo) is your project folder plus a hidden .git directory containing the entire history: every commit, branch and tag. It can be local (only on your computer) or remote (cloned on GitHub). Deleting .git loses the history but keeps your files; deleting the files while keeping .git leaves history with nothing to show.
git add moves changed files into the staging area — your draft of the next snapshot — so you can review exactly what will be recorded. git commit writes the staged snapshot permanently with a message describing why the change happened. Two steps by design: stage deliberately, commit intentionally.
A branch is a movable pointer to a commit — creating one costs almost nothing. Use a branch for every unit of work (feature, fix, experiment): it keeps unfinished code out of main, lets you review changes in a pull request, and makes abandoning a bad idea as simple as deleting the branch.
It depends on where the change lives. Unstaged edits: git restore file. Staged but uncommitted: git restore --staged file. Committed but not pushed: git reset --soft to keep changes staged. Already pushed: git revert commit — it writes a new commit that undoes the old one instead of rewriting shared history. The undoing chapter covers each case with commands.
A conflict happens when two branches changed the same lines and Git cannot choose automatically. Your file gets marked up with <<<<<<<, ======= and >>>>>>> sections; you edit it down to the correct result, remove the markers, then git add and git commit. Conflicts are normal, small and entirely fixable — they are not an error state.
A pull request (PR) is GitHub's proposal to merge one branch into another. It shows the diff, runs checks, and lets teammates comment line by line before the code lands. It is the centre of modern collaboration: work on a branch, open a PR, review, approve, merge.
Write the subject in imperative mood, under about 50 characters: "Add email validation to signup". Explain why, not what, in the body when it is not obvious. Many teams use Conventional Commits (feat:, fix:, docs:) so tools can generate changelogs — the workflows chapter shows the format in practice.
Secrets (API keys, .env files), dependencies (node_modules), build output (dist), and operating-system junk (.DS_Store, Thumbs.db). A .gitignore file excludes them from the start; the common mistakes chapter shows what to do if something already slipped into history.