Chapter 22: Git GitHub Edit Code
What is Git + GitHub Edit Code?”
This usually means one (or both) of two very common things beginners ask about:
- How do I edit code in my local Git repository (on my laptop) and then commit + push those changes to GitHub?
- How do I directly edit code files right on GitHub.com in the browser (without using my laptop at all)?
Both are important, but they serve very different purposes.
I’m going to explain both in detail, step-by-step, like we’re sitting together on your laptop + browser, with real examples.
Part 1 – Editing code locally (on your laptop) → commit → push to GitHub
(This is the normal, most powerful, everyday way professional developers work)
Step-by-step example
Assume you already have a repo cloned from GitHub (or you followed our previous “Getting Started” lesson).
|
0 1 2 3 4 5 6 7 8 9 10 11 |
# 1. Make sure you're up to date git switch main git pull origin main # 2. Create a safe branch to work on git switch -c feat/add-search-bar |
Now open your project folder in your favorite editor:
- VS Code → code .
- Notepad++ / Sublime / Vim / whatever you like
Let’s pretend the project has this simple index.html:
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<!DOCTYPE html> <html> <head> <title>My Todo App</title> </head> <body> <h1>Todo List</h1> <ul> <li>Buy milk</li> </ul> </body> </html> |
You want to edit it → add a search input at the top.
Change it to:
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
<!DOCTYPE html> <html> <head> <title>My Todo App</title> <style> input { width: 300px; padding: 8px; margin: 10px 0; } </style> </head> <body> <h1>Todo List</h1> <!-- NEW CODE ADDED HERE --> <input type="text" placeholder="Search todos..." id="searchInput"> <ul> <li>Buy milk</li> <li>Call mom</li> </ul> <script> // Simple client-side search (just for demo) document.getElementById('searchInput').addEventListener('input', function(e) { const term = e.target.value.toLowerCase(); const items = document.querySelectorAll('li'); items.forEach(item => { item.style.display = item.textContent.toLowerCase().includes(term) ? '' : 'none'; }); }); </script> </body> </html> |
Save the file (Ctrl+S or File → Save).
Now Git knows something changed:
|
0 1 2 3 4 5 6 |
git status |
You see:
|
0 1 2 3 4 5 6 7 8 |
On branch feat/add-search-bar Changes not staged for commit: modified: index.html |
Stage & commit:
|
0 1 2 3 4 5 6 7 8 9 |
git add index.html # or git add . ← everything git commit -m "feat(ui): add client-side search bar with debounce-like filter" |
Push to GitHub:
|
0 1 2 3 4 5 6 |
git push -u origin feat/add-search-bar |
→ Go to GitHub.com → your repo → you see the new branch → Click “Compare & pull request” → create PR → team can review your edit
This is the standard flow — edit locally → commit → push → PR
Part 2 – Editing code directly on GitHub.com (in browser)
This is very useful when:
- You’re on a phone/tablet without your laptop
- You want to fix a typo quickly
- You’re contributing to someone else’s open-source project
- You don’t have the repo cloned locally yet
Step-by-step example (browser-only edit)
-
Go to your repo on github.com → https://github.com/Webliance/todo-app-2026
-
Click on any file → for example README.md or index.html
-
Click the pencil icon (✏️) in top-right of file view → “Edit this file”
-
Make your change right in the browser editor:
Example – add a new line to README.md:
text0123456- Add dark mode support (planned for v2) -
Scroll down → you see three fields:
- Commit message (very important – write a good one!) Example: docs: add dark mode roadmap to README
- Extended description (optional – explain more)
- Commit directly to the main branch OR Create a new branch and start a pull request
Best practice in 2026 → almost always choose: “Create a new branch for this commit and start a pull request” → GitHub auto-creates branch like patch-1 or webliance-patch-1
-
Click green Commit changes or Propose changes
→ If you chose new branch + PR → you land on Pull Request page → you can add description, assign reviewers, etc.
Result:
- Your edit is now safely on GitHub
- No local Git needed
- If it’s your repo → you can later merge the PR yourself
- If it’s someone else’s repo → they get a nice PR with your change
Quick Comparison Table (2026 perspective)
| Way to edit code | Where you edit | Requires local Git setup? | Best for | Commit message control | Can create branch/PR automatically? |
|---|---|---|---|---|---|
| Locally (laptop) | VS Code / any editor | Yes | Real development, large changes, debugging | Full control | Manual (but easy) |
| Directly on GitHub.com | Browser text editor | No | Quick fixes, typos, mobile, first contributions | Good (but small box) | Yes – one click |
Pro Tips & Best Practices (2026)
-
Always write meaningful commit messages — even on GitHub.com Bad: “Update README.md” Good: “docs(readme): add contribution guidelines section”
-
For serious work → always prefer local edit (you get linting, auto-format, Git diff preview, debugging…)
-
On GitHub.com → use “Suggest changes” when reviewing someone else’s PR (very common in teams)
-
If you edited on GitHub.com and want those changes locally later:
Bash01234567891011git fetch origingit switch maingit pull# or if PR branch:git fetch origin patch-1:patch-1git switch patch-1
Got the two ways clear now?
- Local edit = full power, daily development
- GitHub.com edit = quick, browser-only, great for small fixes & contributions
Next?
- Want to see how to resolve a conflict after editing on GitHub.com?
- How to review & merge your own browser PR locally?
- Or move to .gitignore / conventional commits?
Just tell me — we’ll continue the class. You’re doing really well! 🚀
