At 9:14 a.m., the homepage was healthy. At 9:27, a small headline change had been merged, and the navigation disappeared on mobile. Nobody needed a lecture about “saving versions.” The team needed to answer four practical questions: what changed, who reviewed it, how did it reach the live site, and how can we undo it without pretending the change never happened?
Version control is the system that records those answers. Git stores project history as commits, lets you isolate work on branches, and gives a team a reviewable path from an idea to a deployed change. GitHub adds collaboration features such as pull requests, checks, and discussions. The value is not a magical undo button. The value is a trustworthy trail.
Entry one: the last known good snapshot
The project starts with a working `main` branch. A commit is a recorded snapshot with a message and a place in the project’s history. Git’s official book explains that a branch is a lightweight movable pointer to a commit, rather than a second copy of the entire project in its branching guide.
git switch main
git pull
git log --oneline --decorate -5The commands do not tell you whether the site is visually correct. They tell you which history you are looking at. A useful commit message describes the change a future reader will need to recognize:
8a1c4f2 Improve mobile navigation spacing
b04c210 Add accessible menu button
2de91a7 Initial responsive layoutThink of each commit as a checkpoint, not a backup file named `homepage-final-final-2`. A checkpoint should be small enough to inspect and meaningful enough to explain.
| Artifact | Question it answers | What it does not guarantee |
|---|---|---|
| Commit | What snapshot was recorded, and when? | That the code passed every test. |
| Branch | Which line of work is moving independently? | That the change is safe to merge. |
| Pull request | What change is proposed and how was it reviewed? | That deployment succeeded. |
| Check | Did an automated command pass? | That the requirement was understood correctly. |
| Rollback commit | Which earlier change should be reversed? | That the original bug cannot return later. |
Entry two: the branch creates a safe room
The developer does not edit `main` directly. She creates a topic branch for the navigation change:
git switch -c improve-mobile-navigation
# edit files, run tests, inspect the page
git status
git add src/navigation.js styles/menu.css
git commit -m "Improve mobile navigation spacing"The branch is not a separate project universe. It is a movable reference to a different line of commits. Git encourages branching because creating and switching branches is lightweight. The practical benefit is isolation: unfinished work can evolve without changing the branch that other people use as the integration point.
Isolation also creates a responsibility. A branch can be wrong for a long time without affecting `main`, but the longer it lives, the more likely it is to diverge from the current project. A beginner should not treat a branch as permission to stop syncing. Pull the latest base branch when the team’s workflow calls for it, resolve conflicts deliberately, and keep the change understandable.
Our guide to why beginners need Git covers the vocabulary of repositories and commits. This article focuses on the path those objects take when a change is meant for a live website.
Entry three: the pull request turns work into a conversation
After pushing the branch, the developer opens a pull request. GitHub describes a pull request as a proposal to merge code changes, with conversation, commits, checks, files changed, and automated findings gathered around the proposed change in its documentation.
git push -u origin improve-mobile-navigationThe useful pull request description is not “please review.” It explains the user-visible change, the test performed, and the remaining uncertainty:
Change: The mobile menu now remains visible when the viewport narrows below 640px.
Checked: Keyboard navigation, narrow viewport, and desktop menu behavior.
Still uncertain: The animation has not been tested on a low-power phone.
GitHub’s pull request workflow lets the author select a base branch and a compare branch, then request review before merging in the official guide. This is why a pull request is more than a nicer commit list. It creates a shared place for a reviewer to ask whether the code matches the intended behavior.
What the reviewer looks for
- Does the diff contain only the navigation change, or did an editor reformat unrelated files?
- Does the code preserve keyboard access and visible focus?
- Do the automated checks cover the narrow viewport, or only syntax?
- Does the branch contain secrets, generated files, or local configuration?
- Can the author explain how to reverse the change if the live result is wrong?
A review is not a ceremony that makes an incorrect requirement correct. It is a second opportunity to surface assumptions before the change reaches users.
Entry four: merge is a decision, not a synonym for publish
The reviewer approves the change and the pull request is merged. The project now contains the navigation change on `main`, but the public website may still show the previous build. Many teams connect a merge to a deployment pipeline; others deploy manually or through a hosting provider. Version control records the source change, while the deployment system moves a selected revision to an environment.
| Stage | Typical question | Evidence to keep |
|---|---|---|
| Local | Does the developer’s copy behave as expected? | Commands, screenshots, focused tests. |
| Branch | Is the change isolated and committed? | Branch name and commit history. |
| Review | Did another person inspect the proposed behavior? | Pull request conversation and diff. |
| Build | Can the project be assembled from the revision? | Build log and artifact identifier. |
| Production | Does the live site work for real users? | Deployment record and smoke test. |
That separation prevents a common beginner mistake: assuming that “the code is on GitHub” means “the code is live.” The repository is a source of truth for history. Hosting, build configuration, and deployment rules determine what users receive.
Entry five: the smoke test catches the embarrassing part
After deployment, the developer opens the public page on a narrow viewport, opens the menu with a keyboard, follows a link, and refreshes. A smoke test is deliberately small. It does not prove the entire site is correct; it checks that the most important path still works.
# A simple local check before the browser test
npm test
npm run buildIf the build passes but the live menu is missing, the failure may live in deployment configuration, cached assets, an environment difference, or a browser-specific behavior. Version control helps locate the change, but it does not replace observing the deployed system.
Entry six: the rollback does not erase the evidence
At 9:27, the mobile menu fails. The safest response is not necessarily `git reset –hard` on the shared branch. Rewriting public history can make other people’s references confusing and can remove the explanation of what happened. A revert creates a new commit that applies the opposite change, preserving the sequence:
git switch main
git pull
git log --oneline --decorate -5
git revert 8a1c4f2
git push origin mainThe exact command depends on the repository state and whether the problematic change was a merge commit. The conceptual distinction is more important for a beginner: reset moves a reference in local history, while revert records a new change that undoes an earlier one. Ask the team before choosing a destructive history operation.
The rollback should have its own message:
Revert "Improve mobile navigation spacing"
The mobile menu is hidden after deployment at narrow widths.
Restore the previous behavior while the layout fix is investigated.This message is valuable when someone searches the history weeks later. It explains that the earlier change was not rejected because branches are bad; it was reversed because a production observation contradicted the expected result.
What the diary teaches about version control
Git is often introduced as a list of commands, but the commands make more sense when attached to a decision:
| Decision | Git action | Reason |
|---|---|---|
| Start isolated work. | git switch -c branch-name | Keep unfinished changes away from the integration branch. |
| Record a coherent checkpoint. | git add and git commit | Create a named snapshot that can be inspected. |
| Share a proposal. | git push and pull request | Invite review around a specific diff. |
| Integrate accepted work. | Merge the pull request | Make the change part of the base branch. |
| Reverse a public mistake. | git revert | Undo behavior while preserving an auditable event. |
Our article on GitHub Copilot discusses reviewing generated code; version control gives that review a place to live. Our guide to hosting and domains explains the next boundary between a repository and a public website.
Questions beginners ask after the first incident
Does a branch copy all the project files?
Conceptually, a branch is a reference to a line of commits. Git can show the files associated with the checked-out commit, but creating a branch is not the same as manually duplicating a project directory.
Is a pull request the same as a commit?
No. A commit records a snapshot in Git. A pull request is a collaboration and review surface that proposes combining changes from one branch into another.
Should I use reset or revert to undo a bad deployment?
For shared or published history, a revert is usually easier to explain because it records a new change that reverses the earlier one. Repository policy and the exact history still matter, so ask before rewriting a shared branch.
Does Git automatically deploy my site?
No. Git records source history. A hosting provider or deployment pipeline must be configured to build and publish a selected revision.
Keep the trail readable
The real beginner milestone is not memorizing `git revert`. It is being able to reconstruct a change without guessing: this branch introduced it, this pull request explained it, these checks passed, this deployment exposed the failure, and this new commit restored the previous behavior.
That trail makes software easier to change because the next decision starts with evidence. Version control does not prevent mistakes. It makes mistakes visible, discussable, and recoverable.
Follow the change from repository to public website →
Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.