# Your first change in the browser, and how to revert it > Make a small change entirely in the GitHub web UI: find the file, edit it in the GitHub web editor, commit to a new branch because main is protected, open a pull request, pass checks and review, merge and deploy. Then undo a merged change with GitHub's Revert button, learn when to revert and when to fix forward, and what a PM should and shouldn't edit. - Course: [Git and GitHub for Product People](https://productovi.com/courses/git-for-product.md) - Module: GitHub for product work - Lesson 15/15, ~41 min - Source: https://productovi.com/courses/git-for-product/first-change-in-the-browser ## The typo, again **Alex Tutor:** Wednesday of week four, and your product team at CatChow has a familiar problem. Support has forwarded the same customer note three times: the delivery page says couriers call "30 minutes before arival". **Sofia:** In module one someone had to explain to me what a commit even was. Today I'd like to fix this with my own hands. **Daniel:** Please do. It's text on a page, and page texts belong to you and Emma. I'll review it like any other pull request, and if it goes wrong, GitHub's Revert button takes it back. **Alex Tutor:** Before the clicks, the boundary. A PM can safely edit copy and docs: page texts in `.md` files, the FAQ, the README, issue templates. And it all still goes through a pull request. ![A product manager tidies a shop's display window while, behind a back door marked with a gear icon, engineers work on machinery.](https://productovi.com/courses/git-for-product/inline/first-change-in-the-browser-illustration-2.webp) **Daniel:** Code and config stay with engineers: `.tsx` files, `config/prices.json`, anything in `.github/workflows/`. One missing comma in a config file can stop the whole site from building. ![A PM edits page texts, the FAQ, the README and issue templates through a pull request; code and config stay with engineers.](https://productovi.com/courses/git-for-product/diagrams/m5-l3-pm-edit-boundary.png) **Sofia:** Even though a price in `config/prices.json` is just a number? **Daniel:** Even then. The code reads that number at checkout. Ask for the change, and I make it with tests and Oscar's review, like the threshold in #133. > **Exercise:** Which of these changes can Sofia, CatChow's product manager, make without an engineer, in the browser and through a pull request? Select all that apply. ## Find the file, open the GitHub web editor **Alex Tutor:** Start on the repository page, `Code` tab. Open the `pages` folder, then `delivery.md`. Or press `t` and type "delivery" to search by file name. **Sofia:** Found it. Line 15: "Couriers call 30 minutes before arival." And the branch selector above the file says `main`. **Alex Tutor:** At the top right of the file there's a pencil icon, `Edit this file` as of 2026. It opens GitHub's web editor, right in the browser. **Daniel:** Nothing is saved while you type, and nothing can break. Until you commit, the editor is only a draft in your browser tab. **Alex Tutor:** Fix the word, then open the `Preview` tab to see the text as it will look on the page, not as raw Markdown. > **The edit in `pages/delivery.md`** > > ```diff > Couriers deliver within one day in Kyiv. > -Couriers call 30 minutes before arival. > +Couriers call 30 minutes before arrival. > ``` > One word changed, so Git shows the whole line twice: the old version removed, the new one added. > **Exercise:** Pressing the pencil icon on a file in `main` creates a new branch straight away, and every keystroke is saved to it. ## Commit changes… **Alex Tutor:** Now the green `Commit changes…` button. A dialog opens with a commit message, an optional extended description, and a choice of where the commit goes. **Sofia:** The message box already says "Update delivery.md". **Daniel:** GitHub's default. True, and useless in a history of two thousand commits. Say what changed: "Fix typo in courier note". **Alex Tutor:** Then the choice. "Commit directly to the `main` branch" isn't open to you: branch protection lets changes into `main` only through pull requests. So pick "Create a new branch for this commit and start a pull request". **Daniel:** GitHub suggests a name like `catchow-sofia-patch-1`. It works, but rename it to our habit: `content/delivery-typo`. **Sofia:** Then `Propose changes`. The commit lands on the new branch, and `main` hasn't changed at all. > **Exercise:** Why does Sofia's commit go to a new branch instead of straight into `main`? **Alex Tutor:** Now the whole dialog at once. Which combination would Daniel be glad to see? > **Exercise:** The `Commit changes…` dialog is open for the typo fix in CatChow's repository. Which combination is right? ## A pull request of your own **Alex Tutor:** `Propose changes` leads to "Open a pull request": base `main`, compare `content/delivery-typo`. The title comes from the commit message; the description is yours to write. **Sofia:** What: fixes "arival" on the delivery page. Why: support forwarded it three times. How to test: open the preview and read the courier note. Reviewer: Daniel. **Alex Tutor:** Then `Create pull request`. It's #168, and the checks start at once: `build`, `test`, and `preview` with its own link. **Daniel:** By the way, you can't approve your own pull request. GitHub doesn't let authors approve, so our "one approving review" always means someone else looked. **Alex Tutor:** While the checks run, Emma spots the pull request and asks for one more line under the courier note: "Earn loyalty points on every order and spend them at checkout." **Sofia:** Same file, same branch. I open `delivery.md` on `content/delivery-typo`, add her line and commit straight to that branch: "Mention loyalty points on delivery page". **Daniel:** New title, "Fix courier typo and mention loyalty points". Checks green, the preview reads well. Approved. **Alex Tutor:** You press `Squash and merge`: one commit on `main`, the branch deleted, and the deploy finishes four minutes later. ```text Pull request #168, Wednesday 11:20 - [Merged] Fix courier typo and mention loyalty points #168: Squash-merged into main by Sofia · branch content/delivery-typo deleted - [Approved] Daniel: Approved - [All checks have passed] build - [All checks have passed] test - [All checks have passed] preview - [All checks have passed] deploy (production): Finished four minutes after the merge ``` > **Exercise:** Put the steps of a change made in the browser in order, from opening the file to the live page. ## Ten minutes later **Sofia:** Support again. A customer read the new line and asks where to find her points. She can't find them: loyalty points are still switched off for customers. **Alex Tutor:** Emma's programme page sits behind the `loyalty-points` flag; Daniel built that check into #157. A sentence in `pages/delivery.md` has no flag around it. Merged and deployed means shown. **Daniel:** Same mistake as my menu link before `v1.4.1`: the feature was hidden, one way into it wasn't. And I missed it in review too. **Sofia:** So we're announcing loyalty points six days before the launch. How do I take it back? > **Exercise:** Emma's line about loyalty points went into the typo fix #168 and was merged and deployed with it. Why do customers see that line on the delivery page, even though the flag `loyalty-points` is off? ## How to revert a pull request on GitHub **Alex Tutor:** Open #168. At the bottom of `Conversation`, next to the note that it was merged, there's a `Revert` button, as of 2026. **Alex Tutor:** A **revert** deletes nothing: it's a new commit that does the exact opposite of a merged one. GitHub makes a new branch, `revert-168-content/delivery-typo`, with one commit that undoes #168, and prepares a pull request for it. ![A trail of paw prints goes forward along a path, then a second trail walks back to an earlier spot; every print from both trails is still visible.](https://productovi.com/courses/git-for-product/inline/first-change-in-the-browser-illustration-3.webp) *A revert deletes nothing: it's a new commit that undoes an old one.* **Daniel:** That's #169, and it follows the same rules as any pull request: checks and one approval. Undoing a change is still a change. I'm on it. **Sofia:** Approved, checks green, squash-merged, deployed. The loyalty line is gone. And so is my typo fix: "arival" is back. **Alex Tutor:** Because #168 became one squash commit holding both changes, and a revert undoes the whole commit. History keeps everything: your commit, the revert, and who did what. ```text Commit graph, oldest first: The change and its revert on main 1. commit c3f7a05 on main "Show points balance in the account (#166)", tagged v1.5.0 2. commit 8d2b6e9 on main "Write loyalty programme page (#157)" 3. branch content/delivery-typo starts from commit 8d2b6e9 4. commit 5e9a1b4 on content/delivery-typo "Fix typo in courier note" 5. commit 1a7c4f2 on content/delivery-typo "Mention loyalty points on delivery page" 6. commit f3c8d21: content/delivery-typo squash-merged into main "Fix courier typo and mention loyalty points (#168)" 7. branch revert-168-content/delivery-typo starts from commit f3c8d21 8. commit a6b0e53 on revert-168-content/delivery-typo "Revert "Fix courier typo and mention loyalty points"" 9. commit d7e2f48: revert-168-content/delivery-typo squash-merged into main "Revert "Fix courier typo and mention loyalty points" (#169)" (highlighted) ``` *Nothing disappears: the revert is a new commit that undoes f3c8d21. Both stay in the history, and #168 still shows Merged.* > **Exercise:** Every commit on this `main` has been deployed. Which changes are live on the site now? ## Revert or fix forward? **Sofia:** Couldn't I just have deleted the loyalty line in a new pull request? **Alex Tutor:** You could: that's **fixing forward**, a new change that corrects the problem. It would have kept your typo fix. Both are fine; the question is which gets the site right fastest and most safely. **Daniel:** Revert when the live site is wrong and you want the last known good version back now, especially when the right fix isn't obvious yet. Fix forward when the fix is tiny and clear, or when a revert would take good changes with it. ![Revert brings back the last good version now when the right fix isn't obvious; fix forward when the fix is tiny and clear or a revert would undo good changes.](https://productovi.com/courses/git-for-product/diagrams/m5-l3-revert-or-fix-forward.png) ![Where a road splits, one way loops back to a familiar safe house and the other continues to a crew patching a pothole.](https://productovi.com/courses/git-for-product/inline/first-change-in-the-browser-illustration-4.webp) **Alex Tutor:** And the button doesn't always work. If later changes touched the same lines, GitHub can't build the revert on its own, and an engineer does it by hand. **Daniel:** Also, reverting code doesn't undo what already happened. If a bug gave customers wrong points, a revert stops new ones, but fixing their balances needs a plan, not a button. **Sofia:** Here the line was a promise we can't keep yet, and the typo is harmless for another hour. Reverting first was fine. > **Exercise:** Match each situation after a merge with the better way to undo it. ## One change, one pull request **Sofia:** Then #170: branch `content/courier-typo`, one commit "Fix typo in courier note", the same title. Only the typo. **Daniel:** Approved. And the loyalty line gets its own pull request, ready to merge on 10 November, the morning the flag goes on for everyone. **Alex Tutor:** Rewind to Wednesday morning, when Emma asked for her line. Which choice would have made today easier? > **Exercise:** Rewind to Wednesday morning: your typo fix #168 is in review when Emma asks for a loyalty line on the same page. Which choice would have made the change **easy to undo**? **Alex Tutor:** One more thing: Emma should hear why her line disappeared. She asked for it in good faith, and she'll want it back in six days. **Sofia:** Two or three sentences in the team chat, then. > **Exercise:** Write Emma a 2–3 sentence chat message: why her loyalty line was removed from the delivery page, what is live now, and when and how the line comes back. The launch (flag on for all customers) is on 10 November. ## Your own change, start to finish **Alex Tutor:** If you'd like to rehearse, make a personal practice repository, or take GitHub Skills' free "Introduction to GitHub" course. Nothing you click there can reach a real site. **Sofia:** Tonight, then. Breaking things where nobody sees them sounds relaxing. **Daniel:** Everyone learns by breaking something. The trick is to break it in a pull request, where it's easy to undo. **Alex Tutor:** Then the last task of the course: plan a change the way you would on Monday, from the first click to the undo plan. > **Exercise:** Plan the change for issue #175 from start to finish. ## Launch day **Alex Tutor:** Tuesday, 10 November, 9:00. The flag `loyalty-points` goes on for all customers, and a minute later Emma's line is back on the delivery page, in its own pull request. You close #147 as completed. **Sofia:** In module one I was afraid one wrong click could break the whole shop. Now I know what a click can and can't do, and how to take it back. **Daniel:** And now you have your own revert story. Welcome to the team's history. **Alex Tutor:** That's the course: history and diffs, branches and merges, pull requests and reviews, states, workflows and releases, issues and boards, and a change of your own. The repository is no longer a black box. It's the team's shared memory, and you can write in it. **Alex Tutor:** For the moments the terminal shows up anyway, keep the [Git cheat sheet](/tools/git-cheat-sheet#undo) at hand: commands by task, the risky ones marked, each with its GitHub click-path. - Previous lesson: [GitHub Projects: project boards from issue to release](https://productovi.com/courses/git-for-product/project-boards.md) --- Productovi Learning. Free, no sign-up needed to read.